From eckelcu@cisco.com Fri Apr 1 06:07:28 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C79363A683E for ; Fri, 1 Apr 2011 06:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.577 X-Spam-Level: X-Spam-Status: No, score=-10.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FW1+KTJlLXhV for ; Fri, 1 Apr 2011 06:07:27 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 7C7B13A6838 for ; Fri, 1 Apr 2011 06:07:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=6414; q=dns/txt; s=iport; t=1301663348; x=1302872948; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=Lxvhp+t0kwChHftJNW/uhAWHz0yXQJwe2fFZQ2wwV9s=; b=WEmqFWb2S0S10BLvZa8tcXSlLMBztkJNlW+8Skxjv2NUr9LfO1rFQXNZ sH3jd2IcYim5yhA9j3RJrs7W91QLeANoyjmFEVFMNT45nyY0fNa8MMAbo 3RUuBMZRtKS9oAGGjCLmiemThD5FVjZKZLiUqje1O0Rjd78UfL4T3GnxK s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAAELOlU2rRDoI/2dsb2JhbACYGo09d6U3nDyFawSFRIs2 X-IronPort-AV: E=Sophos;i="4.63,282,1299456000"; d="scan'208";a="674405429" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-6.cisco.com with ESMTP; 01 Apr 2011 13:09:07 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p31D96ZD017109; Fri, 1 Apr 2011 13:09:06 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Apr 2011 06:09:06 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 1 Apr 2011 06:09:03 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] comments on draft-ram-siprec-metadata-04 Thread-Index: Acvr6KoPYFMcjPlASk+pOtN532GUhgBO/qTgAD5pH0AAJpm4YABBRncAAAC5KqAAKvS90A== References: From: "Charles Eckel (eckelcu)" To: "Elwell, John" , "Parthasarathi R (partr)" , X-OriginalArrivalTime: 01 Apr 2011 13:09:06.0626 (UTC) FILETIME=[FB2C0A20:01CBF06D] Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 13:07:28 -0000 How about: OLD: Metadata is the data that describes the communication session. NEW: Metadata is the data that describes the recording session, including the communication sessions it is recording. Cheers, Charles > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Thursday, March 31, 2011 6:30 PM > To: Charles Eckel (eckelcu); Parthasarathi R (partr); siprec@ietf.org > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 >=20 > Charles, >=20 > OK, I see how you got there, but really it describes the CSs (and CS groups) that are being carried in > the RS. Any ideas how better to word it? >=20 > John >=20 > > -----Original Message----- > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > Sent: 31 March 2011 17:11 > > To: Elwell, John; Parthasarathi R (partr); siprec@ietf.org > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > > > Hi John, > > > > Please see inline. > > > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > Sent: Wednesday, March 30, 2011 11:01 AM > > > To: Charles Eckel (eckelcu); Parthasarathi R (partr); > > siprec@ietf.org > > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > > > > > > > > > > > > -----Original Message----- > > > > From: siprec-bounces@ietf.org > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Charles Eckel > > (eckelcu) > > > > Sent: 29 March 2011 15:38 > > > > To: Parthasarathi R (partr); siprec@ietf.org > > > > Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 > > > > > > > > Hi Partha, > > > > > > > > Thanks for your response. This addresses all of my concerns. > > > > Please see > > > > one additional clarification inline. > > > > > > > > > -----Original Message----- > > > > > From: Parthasarathi R (partr) > > > > > Sent: Tuesday, March 29, 2011 10:31 AM > > > > > To: Charles Eckel (eckelcu); siprec@ietf.org > > > > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > > > > > > > > > Charles, > > > > > > > > > > Thanks for review the document. Please read inline. > > > > > > > > > > Thanks > > > > > Partha > > > > > > > > > > -----Original Message----- > > > > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On > > > > Behalf Of Charles Eckel (eckelcu) > > > > > Sent: Sunday, March 27, 2011 12:35 AM > > > > > To: siprec@ietf.org > > > > > Subject: [siprec] comments on draft-ram-siprec-metadata-04 > > > > > > > > > > I gave the draft and read and have the following comments. > > > > > > > > > > Section 3. Think the metadata describes the recording > > > > session, not the > > > > communication session. Replace > > > > > "metamodel" with "metadata model", and "MAY be conveyed in > > Recording > > > > Session" with "MAY be conveyed > > > > > within the Recording Session", and "time a change occurred by be > > > > assumed" with "time a change occurred > > > > > may be assumed". > > > [JRE] I am not sure exactly what text Charles was commenting on, but > > in my opinion metadata describes > > > a CS (and how media streams in the RS relate to that CS), > > rather than > > describing the RS. > > > > > > John (as individual) > > > > The metadata model is anchored by an element for the RS. This > > recording > > session contains 0 or more CS group each with 1 or more CS. > > This is what > > led to my comment that the metadata model describes an RS > > rather than a > > CS. > > > > Cheers, > > Charles > > > > > > > > > > > > > > > > > > Section 4, suggest rewording as, "The section describes each > > element > > > > of the metadata model, and the > > > > > attributes of each element. This section also describes how the > > > > different elements are associated." > > > > > > > > > > Section 4.1, RecordingRequestorID is not really an ID, it > > > > is more of a > > > > type. I think > > > > > RecordingRequestor is more appropriate. > > > > > > > > > > > > > > > Agreed. We will update in the next revision > > > > > > > > > > That said, I think you also need a unique ID for the Recording > > > > Session, right? > > > > > Please clarify whether you are interested in AOR of RS > > or > > > > just ID. In the model, Recording > > > > > (1..*) is related to CSG (0..*) and there is no need of separate > > > > attribute for unique id. In the > > > > > metadata format, URN UUID in CSG (group) & recording exist > > > > which helps > > > > to visualize the association > > > > > > > > > > > > > I am assuming there is a need to distinguish one RS from > > > > another RS, and > > > > that is the reason I was recommending adding a unique ID. > > > > This ID would > > > > not be the RS AOR as that may not be unique. > > > > > > > > Cheers, > > > > Charles > > > > > > > > > Section 4.2.1, replace "SRC (or MAY be SRS)" with "SRC or SRS". > > > > > Agreed. We will update in the next revision > > > > > > > > > > Section 4.3.2, why does a CS need two participants or more? > > > > What about > > > > studio mode recording? > > > > > > > > > > Section 4.4.1, what is participant type and what is its use, or > > why > > > > needed? > > > > > This attribute has to be removed as per the > > last interim > > > > meeting. We will update in the next > > > > > revision. > > > > > > > > > > Section 4.5, I think Media Stream requires a unique ID attribute > > as > > > > well. > > > > > As mentioned above in the model draft, the association > > > > between CS and participant is shown. > > > > > In terms of format draft, it is represented by URN UUID > > > > > > > Is the "Media Stream Reference" the SDP label attribute? > > > > > Your understanding is correct > > > > > > > > > > > > > > > Thanks, > > > > > Charles > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > siprec mailing list > > > > > siprec@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > _______________________________________________ > > > > siprec mailing list > > > > siprec@ietf.org > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > From rajnish.jain@ipc.com Fri Apr 1 06:09:40 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EB813A6862 for ; Fri, 1 Apr 2011 06:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IY0E4euivBBO for ; Fri, 1 Apr 2011 06:09:39 -0700 (PDT) Received: from p01c12o144.mxlogic.net (p01c12o144.mxlogic.net [208.65.145.67]) by core3.amsl.com (Postfix) with ESMTP id 474203A6838 for ; Fri, 1 Apr 2011 06:09:39 -0700 (PDT) Received: from unknown [65.244.37.52] (EHLO p01c12o144.mxlogic.net) by p01c12o144.mxlogic.net(mxl_mta-6.9.0-2) with ESMTP id 7fec59d4.5f36c940.2808.00-578.6390.p01c12o144.mxlogic.net (envelope-from ); Fri, 01 Apr 2011 07:11:19 -0600 (MDT) X-MXL-Hash: 4d95cef74d274c4d-d56476e4d15a974924ddd36deb9c1193b07ce672 Received: from unknown [65.244.37.52] by p01c12o144.mxlogic.net(mxl_mta-6.9.0-2) over TLS secured channel with SMTP id 3fec59d4.0.2749.00-352.6343.p01c12o144.mxlogic.net (envelope-from ); Fri, 01 Apr 2011 07:11:16 -0600 (MDT) X-MXL-Hash: 4d95cef406373ef8-cfad32adaca34c5ccef501dfc1817e0c3aa488b5 Received: from STSNYCMS1.corp.root.ipc.com ([169.254.1.10]) by STSNYHTCAS2.corp.root.ipc.com ([10.201.40.93]) with mapi; Fri, 1 Apr 2011 09:11:11 -0400 From: "Jain, Rajnish" To: Hadriel Kaplan , "siprec@ietf.org" Date: Fri, 1 Apr 2011 09:11:08 -0400 Thread-Topic: extensionData in XML Thread-Index: AcvwBbcMs0/nMvprR/2jlIqM3jVdpAAZ0/LA 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 x-tm-as-product-ver: SMEX-8.0.0.1307-6.500.1024-18046.004 x-tm-as-result: No--47.442300-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [65.244.37.52] X-AnalysisOut: [v=1.0 c=1 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=D4USGbs0y0] X-AnalysisOut: [J827gn68Ljfg==:17 a=48vgC7mUAAAA:8 a=cg4j_VLt3_JRueDtpegA:] X-AnalysisOut: [9 a=exVNEzAyW_fcpOdaiQ4A:7 a=CjuIK1q_8ugA:10 a=pPgXnZJf8G4] X-AnalysisOut: [A:10 a=lZB815dzVvQA:10 a=-8MTL8PS7Ghf1Tmv:21 a=LSmHYKWi60F] X-AnalysisOut: [aRYjt:21] Subject: Re: [siprec] extensionData in XML X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 13:09:40 -0000 There may be such motivation from how the CSTA standards are specified. The= y have an element called privateData for each message. It is a placeholder = for any non-standardized extensions. This could be legacy and may not mean = much for the modern text based protocols. That said, I think you're right (this generally applies to any text based p= rotocols and is the fundamental basis for forward/backward compatibility in= such protocols). Raj ----------------------------------------------------- Please consider the environment before printing this email. > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Hadriel Kaplan > Sent: Thursday, March 31, 2011 8:43 PM > To: siprec@ietf.org > Subject: [siprec] extensionData in XML > > Howdy, > With regards to the extensionData concept and XML, I have a few basic > questions. I am by no means an XML expert so it could just be my lack > of knowledge which makes me confused. If so, just tell me to RTFM. > > draft-ram-siprec-metadata-04 says in section 4.6: > A recording metadata object contains additional data not specified > as > part of siprec. This is intended to accommodate future standards > track extensions, as well as vendor and user specific extensions. > The mechanism MUST provide a means of unambiguously distinguishing > such extension data. > > What confuses me is I didn't think XML had to do such machinations to > accommodate this need. I thought we could just specify in our RFCs > that unknown XML elements and attributes MUST be ignored, so that > future RFCs could add them without having to leave specific "blob" XML > elements to carry such data. Or at least that's what we've done so far > in SIP RFCs with XML bodies, afaik. I also thought XML had a namespace > model that could be used to disambiguate proprietary elements from > standard ones. If both of those theories are correct, why do we need > to define an extensionData element? > > -hadriel > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec DISCLAIMER: This e-mail may contain information that is confidential, privi= leged or otherwise protected from disclosure. If you are not an intended re= cipient of this e-mail, do not duplicate or redistribute it by any means. P= lease delete it and any attachments and notify the sender that you have rec= eived it in error. Unintended recipients are prohibited from taking action = on the basis of information in this e-mail.E-mail messages may contain comp= uter viruses or other defects, may not be accurately replicated on other sy= stems, or may be intercepted, deleted or interfered with without the knowle= dge of the sender or the intended recipient. If you are not comfortable wit= h the risks associated with e-mail messages, you may decide not to use e-ma= il to communicate with IPC. IPC reserves the right, to the extent and under= circumstances permitted by applicable law, to retain, monitor and intercep= t e-mail messages to and from its systems. From partr@cisco.com Fri Apr 1 07:36:23 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7672C3A6851 for ; Fri, 1 Apr 2011 07:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.757 X-Spam-Level: X-Spam-Status: No, score=-9.757 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id esiB0oUV+rdt for ; Fri, 1 Apr 2011 07:36:22 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 0EF833A6835 for ; Fri, 1 Apr 2011 07:36:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=4425; q=dns/txt; s=iport; t=1301668682; x=1302878282; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=Kf0bHhgj6LSuGmiHHnuzcNb0QB2IcTjYw1/qxaJKBnw=; b=Fo2bqtEreR5shUb0TiKwrtBJQO+/gVY9qEkATNQM9LLnxvruDp3CORhJ I5B1tT3Z/3tgLeUXHMPbAMfzpDTIwXpiusADLp6QqQ/vU1Ik35bFSyyRl H2utxA1XYEcvgN6Ck5gpARJyBBIgvu0LpxDkd0IkICRAZK9VbE1suFFrT s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsUAALDilU2Q/khNgWdsb2JhbACYGo09FAEBCwsmJYh5nHqcPYVrBIVCizg X-IronPort-AV: E=Sophos;i="4.63,282,1299456000"; d="scan'208";a="24131811" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 01 Apr 2011 14:38:01 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p31Ec0LH015421; Fri, 1 Apr 2011 14:38:01 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Apr 2011 20:08:00 +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: Fri, 1 Apr 2011 20:07:58 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] extensionData in XML Thread-Index: AcvwBbcMs0/nMvprR/2jlIqM3jVdpAAZ0/LAAAI9q7A= References: From: "Parthasarathi R (partr)" To: "Jain, Rajnish" , "Hadriel Kaplan" , X-OriginalArrivalTime: 01 Apr 2011 14:38:00.0844 (UTC) FILETIME=[669D1CC0:01CBF07A] Subject: Re: [siprec] extensionData in XML X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 14:36:23 -0000 Hadriel/Raj, Extensiondata XML is provided as per Metadata model extensiondata block. During the initial discussion of metadata model draft, we realized that lot of attributes specified for recording are call center specific or specific domain related and it is outside the scope of IETF SIPREC but it is required for those specific solution to work. Extensiondata XML element helps to meet those requirement. Extensiondata is provided with URN UUID to pass or not pass independently in partial data. But it is open item whether extensiondata has to be within specific metadatablock or not. Please read inline for more comments. Thanks Partha -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Jain, Rajnish Sent: Friday, April 01, 2011 6:41 PM To: Hadriel Kaplan; siprec@ietf.org Subject: Re: [siprec] extensionData in XML There may be such motivation from how the CSTA standards are specified. They have an element called privateData for each message. It is a placeholder for any non-standardized extensions. This could be legacy and may not mean much for the modern text based protocols. I really didn't get the reason why is it not require for modern text based protocols. This is more like generic param in SIP or xs:any in XML. RFC 6120 is a new RFC which has the similar usage. That said, I think you're right (this generally applies to any text based protocols and is the fundamental basis for forward/backward compatibility in such protocols). Raj ----------------------------------------------------- Please consider the environment before printing this email. > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > Behalf Of Hadriel Kaplan > Sent: Thursday, March 31, 2011 8:43 PM > To: siprec@ietf.org > Subject: [siprec] extensionData in XML > > Howdy, > With regards to the extensionData concept and XML, I have a few basic=20 > questions. I am by no means an XML expert so it could just be my lack > of knowledge which makes me confused. If so, just tell me to RTFM. > > draft-ram-siprec-metadata-04 says in section 4.6: > A recording metadata object contains additional data not specified=20 > as > part of siprec. This is intended to accommodate future standards > track extensions, as well as vendor and user specific extensions. > The mechanism MUST provide a means of unambiguously distinguishing > such extension data. > > What confuses me is I didn't think XML had to do such machinations to=20 > accommodate this need. I thought we could just specify in our RFCs=20 > that unknown XML elements and attributes MUST be ignored, so that=20 > future RFCs could add them without having to leave specific "blob" XML > elements to carry such data. Or at least that's what we've done so=20 > far in SIP RFCs with XML bodies, afaik. =20 > namespace model that could be used to disambiguate proprietary=20 > elements from standard ones. If both of those theories are correct,=20 > why do we need to define an extensionData element? > > -hadriel > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec DISCLAIMER: This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unintended recipients are prohibited from taking action on the basis of information in this e-mail.E-mail messages may contain computer viruses or other defects, may not be accurately replicated on other systems, or may be intercepted, deleted or interfered with without the knowledge of the sender or the intended recipient. If you are not comfortable with the risks associated with e-mail messages, you may decide not to use e-mail to communicate with IPC. IPC reserves the right, to the extent and under circumstances permitted by applicable law, to retain, monitor and intercept e-mail messages to and from its systems. _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From rmohanr@cisco.com Sat Apr 2 02:41:09 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3103D3A6A6A for ; Sat, 2 Apr 2011 02:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.421 X-Spam-Level: X-Spam-Status: No, score=-10.421 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUuKIDrAu07O for ; Sat, 2 Apr 2011 02:41:07 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 23EEE3A69EE for ; Sat, 2 Apr 2011 02:41:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=7438; q=dns/txt; s=iport; t=1301737368; x=1302946968; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=c5n2bOWVfBoSZcfwF3y2IubM5CRT3WDNkvJMVwIjIw4=; b=BfZNXwWCq/9hswb2DXHmLMKQAULR2px52krukWdR5ibPy6sL2L+BOZZn KvgozCvzdIBLUq1gr+Eev8m7kk1FjQKAaPA3Q6oUn4BwSew2LyDIKMmK9 fE6fWikNwHyiVlnwSkSczwyRaZVRh4yBiyAbHWd6USFoARcbmufrMMaWq Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AugAAA/vlk2Q/khMgWdsb2JhbACYJo09FAEBFiYliHmcTZt2hWsEhUWLPw X-IronPort-AV: E=Sophos;i="4.63,287,1299456000"; d="scan'208";a="24199088" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 02 Apr 2011 09:42:47 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p329gk48008061; Sat, 2 Apr 2011 09:42:46 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); Sat, 2 Apr 2011 15:12:46 +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: Sat, 2 Apr 2011 15:10:47 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD05DD8BC3@XMB-BGL-417.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] comments on draft-ram-siprec-metadata-04 Thread-Index: Acvr6KoPYFMcjPlASk+pOtN532GUhgBO/qTgAD5pH0AAJpm4YABBRncAAAC5KqAAKvS90AArRQBw References: From: "Ram Mohan R (rmohanr)" To: "Charles Eckel (eckelcu)" , "Elwell, John" , "Parthasarathi R (partr)" , X-OriginalArrivalTime: 02 Apr 2011 09:42:46.0087 (UTC) FILETIME=[52357570:01CBF11A] Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 02 Apr 2011 09:41:09 -0000 Hi Charles, Inline > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Charles Eckel (eckelcu) > Sent: Friday, April 01, 2011 6:39 PM > To: Elwell, John; Parthasarathi R (partr); siprec@ietf.org > Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 >=20 > How about: >=20 > OLD: > Metadata is the data that describes the communication session. >=20 > NEW: > Metadata is the data that describes the recording session, including > the > communication sessions it is recording. This text seems to create more confusion. Please note Metadata does not describe anything about RS. It describes only about CS. Ram >=20 > Cheers, > Charles >=20 > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Thursday, March 31, 2011 6:30 PM > > To: Charles Eckel (eckelcu); Parthasarathi R (partr); siprec@ietf.org > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > > > Charles, > > > > OK, I see how you got there, but really it describes the CSs (and CS > groups) that are being carried in > > the RS. Any ideas how better to word it? > > > > John > > > > > -----Original Message----- > > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > Sent: 31 March 2011 17:11 > > > To: Elwell, John; Parthasarathi R (partr); siprec@ietf.org > > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > > > > > Hi John, > > > > > > Please see inline. > > > > > > > -----Original Message----- > > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > Sent: Wednesday, March 30, 2011 11:01 AM > > > > To: Charles Eckel (eckelcu); Parthasarathi R (partr); > > > siprec@ietf.org > > > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: siprec-bounces@ietf.org > > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Charles Eckel > > > (eckelcu) > > > > > Sent: 29 March 2011 15:38 > > > > > To: Parthasarathi R (partr); siprec@ietf.org > > > > > Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 > > > > > > > > > > Hi Partha, > > > > > > > > > > Thanks for your response. This addresses all of my concerns. > > > > > Please see > > > > > one additional clarification inline. > > > > > > > > > > > -----Original Message----- > > > > > > From: Parthasarathi R (partr) > > > > > > Sent: Tuesday, March 29, 2011 10:31 AM > > > > > > To: Charles Eckel (eckelcu); siprec@ietf.org > > > > > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata- > 04 > > > > > > > > > > > > Charles, > > > > > > > > > > > > Thanks for review the document. Please read inline. > > > > > > > > > > > > Thanks > > > > > > Partha > > > > > > > > > > > > -----Original Message----- > > > > > > From: siprec-bounces@ietf.org > > > [mailto:siprec-bounces@ietf.org] On > > > > > Behalf Of Charles Eckel (eckelcu) > > > > > > Sent: Sunday, March 27, 2011 12:35 AM > > > > > > To: siprec@ietf.org > > > > > > Subject: [siprec] comments on draft-ram-siprec-metadata-04 > > > > > > > > > > > > I gave the draft and read and have the following comments. > > > > > > > > > > > > Section 3. Think the metadata describes the recording > > > > > session, not the > > > > > communication session. Replace > > > > > > "metamodel" with "metadata model", and "MAY be conveyed in > > > Recording > > > > > Session" with "MAY be conveyed > > > > > > within the Recording Session", and "time a change occurred by > be > > > > > assumed" with "time a change occurred > > > > > > may be assumed". > > > > [JRE] I am not sure exactly what text Charles was commenting on, > but > > > in my opinion metadata describes > > > > a CS (and how media streams in the RS relate to that CS), > > > rather than > > > describing the RS. > > > > > > > > John (as individual) > > > > > > The metadata model is anchored by an element for the RS. This > > > recording > > > session contains 0 or more CS group each with 1 or more CS. > > > This is what > > > led to my comment that the metadata model describes an RS > > > rather than a > > > CS. > > > > > > Cheers, > > > Charles > > > > > > > > > > > > > > > > > > > > > > > Section 4, suggest rewording as, "The section describes each > > > element > > > > > of the metadata model, and the > > > > > > attributes of each element. This section also describes how > the > > > > > different elements are associated." > > > > > > > > > > > > Section 4.1, RecordingRequestorID is not really an ID, it > > > > > is more of a > > > > > type. I think > > > > > > RecordingRequestor is more appropriate. > > > > > > > > > > > > > > > > > > Agreed. We will update in the next revision > > > > > > > > > > > > That said, I think you also need a unique ID for the > Recording > > > > > Session, right? > > > > > > Please clarify whether you are interested in AOR of > RS > > > or > > > > > just ID. In the model, Recording > > > > > > (1..*) is related to CSG (0..*) and there is no need of > separate > > > > > attribute for unique id. In the > > > > > > metadata format, URN UUID in CSG (group) & recording exist > > > > > which helps > > > > > to visualize the association > > > > > > > > > > > > > > > > I am assuming there is a need to distinguish one RS from > > > > > another RS, and > > > > > that is the reason I was recommending adding a unique ID. > > > > > This ID would > > > > > not be the RS AOR as that may not be unique. > > > > > > > > > > Cheers, > > > > > Charles > > > > > > > > > > > Section 4.2.1, replace "SRC (or MAY be SRS)" with "SRC or > SRS". > > > > > > Agreed. We will update in the next revision > > > > > > > > > > > > Section 4.3.2, why does a CS need two participants or more? > > > > > What about > > > > > studio mode recording? > > > > > > > > > > > > Section 4.4.1, what is participant type and what is its use, > or > > > why > > > > > needed? > > > > > > This attribute has to be removed as per the > > > last interim > > > > > meeting. We will update in the next > > > > > > revision. > > > > > > > > > > > > Section 4.5, I think Media Stream requires a unique ID > attribute > > > as > > > > > well. > > > > > > As mentioned above in the model draft, the > association > > > > > between CS and participant is shown. > > > > > > In terms of format draft, it is represented by URN UUID > > > > > > > > > Is the "Media Stream Reference" the SDP label attribute? > > > > > > Your understanding is correct > > > > > > > > > > > > > > > > > > Thanks, > > > > > > Charles > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > siprec mailing list > > > > > > siprec@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > _______________________________________________ > > > > > siprec mailing list > > > > > siprec@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From HKaplan@acmepacket.com Sat Apr 2 05:47:29 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04D923A67E3 for ; Sat, 2 Apr 2011 05:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.623 X-Spam-Level: X-Spam-Status: No, score=-1.623 tagged_above=-999 required=5 tests=[AWL=0.376, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iSO0zyjUCaFB for ; Sat, 2 Apr 2011 05:47:28 -0700 (PDT) Received: from ETMail2.acmepacket.com (etmail2.acmepacket.com [216.41.24.9]) by core3.amsl.com (Postfix) with ESMTP id C32F03A67E2 for ; Sat, 2 Apr 2011 05:47:27 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by ETMail2.acmepacket.com (216.41.24.9) with Microsoft SMTP Server (TLS) id 8.1.240.5; Sat, 2 Apr 2011 08:49:08 -0400 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Sat, 2 Apr 2011 08:49:08 -0400 From: Hadriel Kaplan To: "Parthasarathi R (partr)" Date: Sat, 2 Apr 2011 08:49:06 -0400 Thread-Topic: [siprec] extensionData in XML Thread-Index: AcvxNFr/P3TGgoIBQ/abk6KeJk2EGw== 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 X-Brightmail-Tracker: AAAAAQAAAUA= Cc: "siprec@ietf.org" , "Jain, Rajnish" Subject: Re: [siprec] extensionData in XML X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 02 Apr 2011 12:47:29 -0000 Hi Partha, I think you're missing my point (or I'm missing yours) - you can do all of = that without specifying an "extensionData" XML element. Unknown XML elemen= ts are simply ignored by the other side, so Cisco can add a "ciscoPrivateDa= ta" XML element wherever it wants and send it to an Acme; and that private = element will be ignored by Acme while everything else will continue to work= . Which I think is the behavior you want, right? -hadriel On Apr 1, 2011, at 10:37 AM, Parthasarathi R (partr) wrote: > Hadriel/Raj, >=20 > Extensiondata XML is provided as per Metadata model extensiondata block. > During the initial discussion of metadata model draft, we realized that > lot of attributes specified for recording are call center specific or > specific domain related and it is outside the scope of IETF SIPREC but > it is required for those specific solution to work. Extensiondata XML > element helps to meet those requirement. >=20 > Extensiondata is provided with URN UUID to pass or not pass > independently in partial data. But it is open item whether extensiondata > has to be within specific metadatablock or not. >=20 > Please read inline for more comments. >=20 > Thanks > Partha >=20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf > Of Jain, Rajnish > Sent: Friday, April 01, 2011 6:41 PM > To: Hadriel Kaplan; siprec@ietf.org > Subject: Re: [siprec] extensionData in XML >=20 > There may be such motivation from how the CSTA standards are specified. > They have an element called privateData for each message. It is a > placeholder for any non-standardized extensions. This could be legacy > and may not mean much for the modern text based protocols. >=20 > I really didn't get the reason why is it not require for modern > text based protocols. This is more like generic param in SIP or xs:any > in XML. RFC 6120 is a new RFC which has the similar usage. > >=20 > That said, I think you're right (this generally applies to any text > based protocols and is the fundamental basis for forward/backward > compatibility in such protocols). >=20 > Raj >=20 >=20 > ----------------------------------------------------- > Please consider the environment before printing this email. >=20 >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 >> Behalf Of Hadriel Kaplan >> Sent: Thursday, March 31, 2011 8:43 PM >> To: siprec@ietf.org >> Subject: [siprec] extensionData in XML >>=20 >> Howdy, >> With regards to the extensionData concept and XML, I have a few basic=20 >> questions. I am by no means an XML expert so it could just be my lack >=20 >> of knowledge which makes me confused. If so, just tell me to RTFM. >>=20 >> draft-ram-siprec-metadata-04 says in section 4.6: >> A recording metadata object contains additional data not specified=20 >> as >> part of siprec. This is intended to accommodate future standards >> track extensions, as well as vendor and user specific extensions. >> The mechanism MUST provide a means of unambiguously distinguishing >> such extension data. >>=20 >> What confuses me is I didn't think XML had to do such machinations to=20 >> accommodate this need. I thought we could just specify in our RFCs=20 >> that unknown XML elements and attributes MUST be ignored, so that=20 >> future RFCs could add them without having to leave specific "blob" XML >=20 >> elements to carry such data. Or at least that's what we've done so=20 >> far in SIP RFCs with XML bodies, afaik. =20 >> namespace model that could be used to disambiguate proprietary=20 >> elements from standard ones. If both of those theories are correct,=20 >> why do we need to define an extensionData element? >>=20 >> -hadriel >>=20 >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >=20 > DISCLAIMER: This e-mail may contain information that is confidential, > privileged or otherwise protected from disclosure. If you are not an > intended recipient of this e-mail, do not duplicate or redistribute it > by any means. Please delete it and any attachments and notify the sender > that you have received it in error. Unintended recipients are prohibited > from taking action on the basis of information in this e-mail.E-mail > messages may contain computer viruses or other defects, may not be > accurately replicated on other systems, or may be intercepted, deleted > or interfered with without the knowledge of the sender or the intended > recipient. If you are not comfortable with the risks associated with > e-mail messages, you may decide not to use e-mail to communicate with > IPC. IPC reserves the right, to the extent and under circumstances > permitted by applicable law, to retain, monitor and intercept e-mail > messages to and from its systems. > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From rmohanr@cisco.com Sun Apr 3 10:11:51 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E89DF3A69C1 for ; Sun, 3 Apr 2011 10:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.434 X-Spam-Level: X-Spam-Status: No, score=-10.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUgk8E89Hq54 for ; Sun, 3 Apr 2011 10:11:50 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 9D3963A6853 for ; Sun, 3 Apr 2011 10:11:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=10606; q=dns/txt; s=iport; t=1301850812; x=1303060412; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=DRLjqz+hO2ch8ez1oxv2b5dsKg2/6fwE55ETmYIqx+o=; b=U1p7Ho068ESMapqMvcbIZAnCj2YMYP1AG3/PA9tLuCHODvJfmbfZXl1W /+YwI57RlD8CadaDbsGauhYXdKJpxzn7SlK1Yz9LOHbnKPLWyaBwDfMUb W7XsoTRIYz6EhTe9QINeMxJQ8lhjej/iJh5H/nTwtBf19O2GPK0j523dB 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArwAAACqmE2Q/khMgWdsb2JhbACYII09FAEBFiYlpUyaaoVrBIVFiz8 X-IronPort-AV: E=Sophos;i="4.63,292,1299456000"; d="scan'208";a="24262868" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 03 Apr 2011 17:13:30 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p33HDQuV014158; Sun, 3 Apr 2011 17:13:30 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 3 Apr 2011 22:43:27 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 3 Apr 2011 22:43:23 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD05DD8C0C@XMB-BGL-417.cisco.com> In-Reply-To: <21866C7FE177A4449B9136B5B24B1B130BC011294A@EXMBXCLUS01.citservers.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] comments on draft-ram-siprec-metadata-04 Thread-Index: Acvr6KoPYFMcjPlASk+pOtN532GUhgBO/qTgAD5pH0AAJpm4YABBRncAAAC5KqAAABl2UAAAlZ6wAAOH8AAAVJiJUA== References: <21866C7FE177A4449B9136B5B24B1B130BC011290A@EXMBXCLUS01.citservers.local> <21866C7FE177A4449B9136B5B24B1B130BC011294A@EXMBXCLUS01.citservers.local> From: "Ram Mohan R (rmohanr)" To: "Scott Orton" , "Elwell, John" , "Charles Eckel (eckelcu)" , "Parthasarathi R (partr)" , X-OriginalArrivalTime: 03 Apr 2011 17:13:27.0029 (UTC) FILETIME=[72478250:01CBF222] Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2011 17:11:52 -0000 Scott, I am ok to make this change to the model. I would like to hear from others if they have any issues in incorporating this change in the model.=20 The updated portion of the model will look like +-------------------------------+ 1 | Recording Session (RS) |---------------+ +-------------------------------+ | | 1..* |1..* | | | | | 0..* |0..* | +--------------+ +-----------------+ | |Communication | | Communication | 1 |=20 | Session (CS) |----------| Session (CS) |---| | Group |0..1 1..*| | | 0..* +----------+ +--------------+ +-----------------+ |------|Extension | 1| | 0..* |1..* | | Data | | | 2..* |0..* | +----------+ 0..*| +---------+ |Extension| =20 | Data | +---------+ The only change in the association is : A CS MUST be associated with zero or one CS-Group Rest of the associations remain same. Further the association between CS and RS remains same as what is between CS-Group and RS. Comments ? Regards, Ram > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Scott Orton > Sent: Friday, April 01, 2011 12:18 AM > To: Elwell, John; Charles Eckel (eckelcu); Parthasarathi R (partr); > siprec@ietf.org > Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 >=20 > John, > Thanks for the information. >=20 > In that case I would like to see the CS group be made optional. > Rather than the CS pointing to the CS Group, I would like to suggest > that the CS point to the RS and have the CS group stand alone where it > would just have its own ID and then a list of CS ids that belong to the > group. >=20 > Scott >=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Thursday, March 31, 2011 11:50 AM > To: Scott Orton; Charles Eckel (eckelcu); Parthasarathi R (partr); > siprec@ietf.org > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 >=20 > Scott, >=20 > Some folks wanted to be able to group related CSs together (e.g., a CS > between a customer and an agent and a second CS resulting from the > customer being transferred to a second agent). I will leave it to those > folks to add to this. >=20 > John (chair hat on) >=20 >=20 > > -----Original Message----- > > From: Scott Orton [mailto:sorton@broadsoft.com] > > Sent: 31 March 2011 17:43 > > To: Elwell, John; Charles Eckel (eckelcu); Parthasarathi R > > (partr); siprec@ietf.org > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > > > John, Charles, Partha, > > I have a question. What is the purpose of the CS Group? I > > do not see it adding anything to the metadata. To me it seems > > that the whole purpose of the metadata is to describe the > > recording session to the SRS. Looking at the requirements I > > see 3 relationships that the spec is attempting to describe: > > > > A one to one relationship - one communication session to one > > recording session > > A one to many relationship - one communication session with > > multiple Recording sessions > > - one Recording session made up of > > multiple communications sessions > > > > The current metadata format allows all of these and I do not > > see what the group is adding. > > > > Regards, > > Scott > > > > -----Original Message----- > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > > Sent: Thursday, March 31, 2011 11:30 AM > > To: Charles Eckel (eckelcu); Parthasarathi R (partr); siprec@ietf.org > > Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 > > > > Charles, > > > > OK, I see how you got there, but really it describes the CSs > > (and CS groups) that are being carried in the RS. Any ideas > > how better to word it? > > > > John > > > > > -----Original Message----- > > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > Sent: 31 March 2011 17:11 > > > To: Elwell, John; Parthasarathi R (partr); siprec@ietf.org > > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > > > > > Hi John, > > > > > > Please see inline. > > > > > > > -----Original Message----- > > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > Sent: Wednesday, March 30, 2011 11:01 AM > > > > To: Charles Eckel (eckelcu); Parthasarathi R (partr); > > > siprec@ietf.org > > > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: siprec-bounces@ietf.org > > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Charles Eckel > > > (eckelcu) > > > > > Sent: 29 March 2011 15:38 > > > > > To: Parthasarathi R (partr); siprec@ietf.org > > > > > Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 > > > > > > > > > > Hi Partha, > > > > > > > > > > Thanks for your response. This addresses all of my concerns. > > > > > Please see > > > > > one additional clarification inline. > > > > > > > > > > > -----Original Message----- > > > > > > From: Parthasarathi R (partr) > > > > > > Sent: Tuesday, March 29, 2011 10:31 AM > > > > > > To: Charles Eckel (eckelcu); siprec@ietf.org > > > > > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata- > 04 > > > > > > > > > > > > Charles, > > > > > > > > > > > > Thanks for review the document. Please read inline. > > > > > > > > > > > > Thanks > > > > > > Partha > > > > > > > > > > > > -----Original Message----- > > > > > > From: siprec-bounces@ietf.org > > > [mailto:siprec-bounces@ietf.org] On > > > > > Behalf Of Charles Eckel (eckelcu) > > > > > > Sent: Sunday, March 27, 2011 12:35 AM > > > > > > To: siprec@ietf.org > > > > > > Subject: [siprec] comments on draft-ram-siprec-metadata-04 > > > > > > > > > > > > I gave the draft and read and have the following comments. > > > > > > > > > > > > Section 3. Think the metadata describes the recording > > > > > session, not the > > > > > communication session. Replace > > > > > > "metamodel" with "metadata model", and "MAY be conveyed in > > > Recording > > > > > Session" with "MAY be conveyed > > > > > > within the Recording Session", and "time a change > > occurred by be > > > > > assumed" with "time a change occurred > > > > > > may be assumed". > > > > [JRE] I am not sure exactly what text Charles was > > commenting on, but > > > in my opinion metadata describes > > > > a CS (and how media streams in the RS relate to that CS), > > > rather than > > > describing the RS. > > > > > > > > John (as individual) > > > > > > The metadata model is anchored by an element for the RS. This > > > recording > > > session contains 0 or more CS group each with 1 or more CS. > > > This is what > > > led to my comment that the metadata model describes an RS > > > rather than a > > > CS. > > > > > > Cheers, > > > Charles > > > > > > > > > > > > > > > > > > > > > > > Section 4, suggest rewording as, "The section describes each > > > element > > > > > of the metadata model, and the > > > > > > attributes of each element. This section also > > describes how the > > > > > different elements are associated." > > > > > > > > > > > > Section 4.1, RecordingRequestorID is not really an ID, it > > > > > is more of a > > > > > type. I think > > > > > > RecordingRequestor is more appropriate. > > > > > > > > > > > > > > > > > > Agreed. We will update in the next revision > > > > > > > > > > > > That said, I think you also need a unique ID for the > > Recording > > > > > Session, right? > > > > > > Please clarify whether you are interested > > in AOR of RS > > > or > > > > > just ID. In the model, Recording > > > > > > (1..*) is related to CSG (0..*) and there is no need > > of separate > > > > > attribute for unique id. In the > > > > > > metadata format, URN UUID in CSG (group) & recording exist > > > > > which helps > > > > > to visualize the association > > > > > > > > > > > > > > > > I am assuming there is a need to distinguish one RS from > > > > > another RS, and > > > > > that is the reason I was recommending adding a unique ID. > > > > > This ID would > > > > > not be the RS AOR as that may not be unique. > > > > > > > > > > Cheers, > > > > > Charles > > > > > > > > > > > Section 4.2.1, replace "SRC (or MAY be SRS)" with > > "SRC or SRS". > > > > > > Agreed. We will update in the next revision > > > > > > > > > > > > Section 4.3.2, why does a CS need two participants or more? > > > > > What about > > > > > studio mode recording? > > > > > > > > > > > > Section 4.4.1, what is participant type and what is > > its use, or > > > why > > > > > needed? > > > > > > This attribute has to be removed as per the > > > last interim > > > > > meeting. We will update in the next > > > > > > revision. > > > > > > > > > > > > Section 4.5, I think Media Stream requires a unique > > ID attribute > > > as > > > > > well. > > > > > > As mentioned above in the model draft, the > > association > > > > > between CS and participant is shown. > > > > > > In terms of format draft, it is represented by URN UUID > > > > > > > > > Is the "Media Stream Reference" the SDP label attribute? > > > > > > Your understanding is correct > > > > > > > > > > > > > > > > > > Thanks, > > > > > > Charles > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > siprec mailing list > > > > > > siprec@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > _______________________________________________ > > > > > siprec mailing list > > > > > siprec@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > > > _______________________________________________ > > siprec mailing 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 Sun Apr 3 11:21:03 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 015E83A6826 for ; Sun, 3 Apr 2011 11:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.578 X-Spam-Level: X-Spam-Status: No, score=-10.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGKxRqxQp6N1 for ; Sun, 3 Apr 2011 11:21:01 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 5F7973A6824 for ; Sun, 3 Apr 2011 11:21:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=8693; q=dns/txt; s=iport; t=1301854963; x=1303064563; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=GVPY3t32zWasygU6BL4zSHQ3VxOw1sk3NDhm3u1qb7c=; b=Ai3Xda0EzD7/YeghyROwKD3HqxC1cMCvbw2iKQjHFXXPbyK0r89t+xqB tdbxOO6zHCy1Yy5VzilyOzNTK5w3Mbpfv0YI/Gv2P4oFz4a/BaPIEVqeq FM+jCDnWR70makaXOdmXLALIwiGVrR2JAYU+ofkQYTLETz2Gg2/FFtFRL w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuIAAHm6mE2rRDoG/2dsb2JhbACYIY09d4h5nD2aaoVrBIVHiz0 X-IronPort-AV: E=Sophos;i="4.63,293,1299456000"; d="scan'208";a="423096017" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-1.cisco.com with ESMTP; 03 Apr 2011 18:22:28 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p33IMS9X027906; Sun, 3 Apr 2011 18:22:28 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 3 Apr 2011 11:22: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: Sun, 3 Apr 2011 11:22:23 -0700 Message-ID: In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD05DD8BC3@XMB-BGL-417.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] comments on draft-ram-siprec-metadata-04 Thread-Index: Acvr6KoPYFMcjPlASk+pOtN532GUhgBO/qTgAD5pH0AAJpm4YABBRncAAAC5KqAAKvS90AArRQBwAERwifA= References: <35BCE99A477D6A4986FB2216D8CF2CFD05DD8BC3@XMB-BGL-417.cisco.com> From: "Charles Eckel (eckelcu)" To: "Ram Mohan R (rmohanr)" , "Elwell, John" , "Parthasarathi R (partr)" , X-OriginalArrivalTime: 03 Apr 2011 18:22:27.0781 (UTC) FILETIME=[165C1F50:01CBF22C] Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2011 18:21:03 -0000 Hi Ram, I agree that main point focus of the metadata is the description of the communication sessions(s); however, the metadata model contains a recording session element, and the recording element contains attributes specific to the recording session. For that reason, I think it is misleading to say the metadata describes the communication session. Perhaps you are suggesting the recording session element should be removed from the model, and it may be maintained in an unspecified manner within the SRS? Cheers, Charles > -----Original Message----- > From: Ram Mohan R (rmohanr) > Sent: Saturday, April 02, 2011 11:41 AM > To: Charles Eckel (eckelcu); Elwell, John; Parthasarathi R (partr); siprec@ietf.org > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 >=20 > Hi Charles, >=20 > Inline >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Charles Eckel (eckelcu) > > Sent: Friday, April 01, 2011 6:39 PM > > To: Elwell, John; Parthasarathi R (partr); siprec@ietf.org > > Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 > > > > How about: > > > > OLD: > > Metadata is the data that describes the communication session. > > > > NEW: > > Metadata is the data that describes the recording session, including > > the > > communication sessions it is recording. >=20 > This text seems to create more confusion. Please note Metadata does not describe anything about RS. > It describes only about CS. >=20 > Ram >=20 > > > > Cheers, > > Charles > > > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > Sent: Thursday, March 31, 2011 6:30 PM > > > To: Charles Eckel (eckelcu); Parthasarathi R (partr); siprec@ietf.org > > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > > > > > Charles, > > > > > > OK, I see how you got there, but really it describes the CSs (and CS > > groups) that are being carried in > > > the RS. Any ideas how better to word it? > > > > > > John > > > > > > > -----Original Message----- > > > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > > Sent: 31 March 2011 17:11 > > > > To: Elwell, John; Parthasarathi R (partr); siprec@ietf.org > > > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > > > > > > > Hi John, > > > > > > > > Please see inline. > > > > > > > > > -----Original Message----- > > > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > > Sent: Wednesday, March 30, 2011 11:01 AM > > > > > To: Charles Eckel (eckelcu); Parthasarathi R (partr); > > > > siprec@ietf.org > > > > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: siprec-bounces@ietf.org > > > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Charles Eckel > > > > (eckelcu) > > > > > > Sent: 29 March 2011 15:38 > > > > > > To: Parthasarathi R (partr); siprec@ietf.org > > > > > > Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 > > > > > > > > > > > > Hi Partha, > > > > > > > > > > > > Thanks for your response. This addresses all of my concerns. > > > > > > Please see > > > > > > one additional clarification inline. > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Parthasarathi R (partr) > > > > > > > Sent: Tuesday, March 29, 2011 10:31 AM > > > > > > > To: Charles Eckel (eckelcu); siprec@ietf.org > > > > > > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata- > > 04 > > > > > > > > > > > > > > Charles, > > > > > > > > > > > > > > Thanks for review the document. Please read inline. > > > > > > > > > > > > > > Thanks > > > > > > > Partha > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: siprec-bounces@ietf.org > > > > [mailto:siprec-bounces@ietf.org] On > > > > > > Behalf Of Charles Eckel (eckelcu) > > > > > > > Sent: Sunday, March 27, 2011 12:35 AM > > > > > > > To: siprec@ietf.org > > > > > > > Subject: [siprec] comments on draft-ram-siprec-metadata-04 > > > > > > > > > > > > > > I gave the draft and read and have the following comments. > > > > > > > > > > > > > > Section 3. Think the metadata describes the recording > > > > > > session, not the > > > > > > communication session. Replace > > > > > > > "metamodel" with "metadata model", and "MAY be conveyed in > > > > Recording > > > > > > Session" with "MAY be conveyed > > > > > > > within the Recording Session", and "time a change occurred by > > be > > > > > > assumed" with "time a change occurred > > > > > > > may be assumed". > > > > > [JRE] I am not sure exactly what text Charles was commenting on, > > but > > > > in my opinion metadata describes > > > > > a CS (and how media streams in the RS relate to that CS), > > > > rather than > > > > describing the RS. > > > > > > > > > > John (as individual) > > > > > > > > The metadata model is anchored by an element for the RS. This > > > > recording > > > > session contains 0 or more CS group each with 1 or more CS. > > > > This is what > > > > led to my comment that the metadata model describes an RS > > > > rather than a > > > > CS. > > > > > > > > Cheers, > > > > Charles > > > > > > > > > > > > > > > > > > > > > > > > > > > > Section 4, suggest rewording as, "The section describes each > > > > element > > > > > > of the metadata model, and the > > > > > > > attributes of each element. This section also describes how > > the > > > > > > different elements are associated." > > > > > > > > > > > > > > Section 4.1, RecordingRequestorID is not really an ID, it > > > > > > is more of a > > > > > > type. I think > > > > > > > RecordingRequestor is more appropriate. > > > > > > > > > > > > > > > > > > > > > Agreed. We will update in the next revision > > > > > > > > > > > > > > That said, I think you also need a unique ID for the > > Recording > > > > > > Session, right? > > > > > > > Please clarify whether you are interested in AOR of > > RS > > > > or > > > > > > just ID. In the model, Recording > > > > > > > (1..*) is related to CSG (0..*) and there is no need of > > separate > > > > > > attribute for unique id. In the > > > > > > > metadata format, URN UUID in CSG (group) & recording exist > > > > > > which helps > > > > > > to visualize the association > > > > > > > > > > > > > > > > > > > I am assuming there is a need to distinguish one RS from > > > > > > another RS, and > > > > > > that is the reason I was recommending adding a unique ID. > > > > > > This ID would > > > > > > not be the RS AOR as that may not be unique. > > > > > > > > > > > > Cheers, > > > > > > Charles > > > > > > > > > > > > > Section 4.2.1, replace "SRC (or MAY be SRS)" with "SRC or > > SRS". > > > > > > > Agreed. We will update in the next revision > > > > > > > > > > > > > > Section 4.3.2, why does a CS need two participants or more? > > > > > > What about > > > > > > studio mode recording? > > > > > > > > > > > > > > Section 4.4.1, what is participant type and what is its use, > > or > > > > why > > > > > > needed? > > > > > > > This attribute has to be removed as per the > > > > last interim > > > > > > meeting. We will update in the next > > > > > > > revision. > > > > > > > > > > > > > > Section 4.5, I think Media Stream requires a unique ID > > attribute > > > > as > > > > > > well. > > > > > > > As mentioned above in the model draft, the > > association > > > > > > between CS and participant is shown. > > > > > > > In terms of format draft, it is represented by URN UUID > > > > > > > > > > > Is the "Media Stream Reference" the SDP label attribute? > > > > > > > Your understanding is correct > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > Charles > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > siprec mailing list > > > > > > > siprec@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > _______________________________________________ > > > > > > siprec mailing list > > > > > > siprec@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec From partr@cisco.com Sun Apr 3 11:44:12 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6C0128C0F7 for ; Sun, 3 Apr 2011 11:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.063 X-Spam-Level: X-Spam-Status: No, score=-9.063 tagged_above=-999 required=5 tests=[AWL=-0.461, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fy5-LwTU98Pr for ; Sun, 3 Apr 2011 11:44:10 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id E66EE28C0F3 for ; Sun, 3 Apr 2011 11:44:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=17134; q=dns/txt; s=iport; t=1301856352; x=1303065952; h=mime-version:subject:date:message-id:references:from:to: cc; bh=EbtEoHWMan+AIoAeZlGuXRmorX7dfqqIov7qyAwoCPg=; b=WKGInpLjLlElwKBYmPqu5kKYIDqyiECPDli6GWn+5yYeNaHgxODkicdN WCEheTK2rYKmJf/1FUEp9lqeOMa8inyNWcMUMWjljmzmYnF4rkwk6UR4U ZH8ICJvKHqXJNQ4IWmyDbmoRpnzGYllvAR5/GdGB4GHo82Q8lIJ0YJR44 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtEAAA7AmE2Q/khLgWdsb2JhbACYIYxdYBQBARYmJYh5nCuabIVrBIVFiz8 X-IronPort-AV: E=Sophos;i="4.63,293,1299456000"; d="scan'208,217";a="81992031" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 03 Apr 2011 18:45:51 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p33IjniK006118; Sun, 3 Apr 2011 18:45:50 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 4 Apr 2011 00:15:49 +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_01CBF22F.59C5AE79" Date: Mon, 4 Apr 2011 00:15:49 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] extensionData in XML Thread-Index: AcvxNFr/P3TGgoIBQ/abk6KeJk2EGwA8rJ/p References: From: "Parthasarathi R (partr)" To: "Hadriel Kaplan" X-OriginalArrivalTime: 03 Apr 2011 18:45:49.0711 (UTC) FILETIME=[59F9A9F0:01CBF22F] Cc: siprec@ietf.org, "Jain, Rajnish" Subject: Re: [siprec] extensionData in XML X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2011 18:44:12 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBF22F.59C5AE79 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hadriel, =20 I guess we have common understaning to the extend that the intention is = to send some extensiondata (Unknown) attribute by SRC which may or may = not understand by SRS and also for the usage of xs:any as the solution. = Few stuff are missing in yours proposal w.r.t partial data passing of = extensiondata: =20 The question is whether there is a need to pass the extension data = during every time the corresponding metadata block is passed or updated. = For example, CS metadata block sends extension data specific to call = center data like Agent is remote or local, agent or customer initiated = call (direction) during the CS block creation (INVITE) and these = constant information in extensiondata is not required to be passed in = each update of CS metadata like adding video stream in the mid-session. =20 The current model allows to pass extensiondata only during the initial = CS block creation and there is no need to update or resend while CS = block is getting updated with other CS information. IMO, The current = extensiondata mechanism is required as SIPREC puts lot of call centre = specific attributes proposed during metadata model draft review as = outside the scope of SIPREC and most of the attributes mentioned are = constant within the scope of session.=20 =20 Also, it is possible to pass update only extension data within RS = session without impacting parent element. Please let me know your and = others opinion whethter it is fine to continue with the current = extension-data element or to move xs:any element to each of the metadata = block. =20 Thanks Partha ________________________________ From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] Sent: Sat 4/2/2011 6:19 PM To: Parthasarathi R (partr) Cc: Jain, Rajnish; siprec@ietf.org Subject: Re: [siprec] extensionData in XML Hi Partha, I think you're missing my point (or I'm missing yours) - you can do all = of that without specifying an "extensionData" XML element. Unknown XML = elements are simply ignored by the other side, so Cisco can add a = "ciscoPrivateData" XML element wherever it wants and send it to an Acme; = and that private element will be ignored by Acme while everything else = will continue to work. Which I think is the behavior you want, right? -hadriel On Apr 1, 2011, at 10:37 AM, Parthasarathi R (partr) wrote: > Hadriel/Raj, > > Extensiondata XML is provided as per Metadata model extensiondata = block. > During the initial discussion of metadata model draft, we realized = that > lot of attributes specified for recording are call center specific or > specific domain related and it is outside the scope of IETF SIPREC but > it is required for those specific solution to work. Extensiondata XML > element helps to meet those requirement. > > Extensiondata is provided with URN UUID to pass or not pass > independently in partial data. But it is open item whether = extensiondata > has to be within specific metadatablock or not. > > Please read inline for more comments. > > Thanks > Partha > > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On = Behalf > Of Jain, Rajnish > Sent: Friday, April 01, 2011 6:41 PM > To: Hadriel Kaplan; siprec@ietf.org > Subject: Re: [siprec] extensionData in XML > > There may be such motivation from how the CSTA standards are = specified. > They have an element called privateData for each message. It is a > placeholder for any non-standardized extensions. This could be legacy > and may not mean much for the modern text based protocols. > > I really didn't get the reason why is it not require for = modern > text based protocols. This is more like generic param in SIP or xs:any > in XML. RFC 6120 is a new RFC which has the similar usage. > > > That said, I think you're right (this generally applies to any text > based protocols and is the fundamental basis for forward/backward > compatibility in such protocols). > > Raj > > > ----------------------------------------------------- > Please consider the environment before printing this email. > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Hadriel Kaplan >> Sent: Thursday, March 31, 2011 8:43 PM >> To: siprec@ietf.org >> Subject: [siprec] extensionData in XML >> >> Howdy, >> With regards to the extensionData concept and XML, I have a few basic >> questions. I am by no means an XML expert so it could just be my = lack > >> of knowledge which makes me confused. If so, just tell me to RTFM. >> >> draft-ram-siprec-metadata-04 says in section 4.6: >> A recording metadata object contains additional data not specified >> as >> part of siprec. This is intended to accommodate future standards >> track extensions, as well as vendor and user specific extensions. >> The mechanism MUST provide a means of unambiguously distinguishing >> such extension data. >> >> What confuses me is I didn't think XML had to do such machinations to >> accommodate this need. I thought we could just specify in our RFCs >> that unknown XML elements and attributes MUST be ignored, so that >> future RFCs could add them without having to leave specific "blob" = XML > >> elements to carry such data. Or at least that's what we've done so >> far in SIP RFCs with XML bodies, afaik.=20 >> namespace model that could be used to disambiguate proprietary >> elements from standard ones. If both of those theories are correct, >> why do we need to define an extensionData element? >> >> -hadriel >> >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec > > DISCLAIMER: This e-mail may contain information that is confidential, > privileged or otherwise protected from disclosure. If you are not an > intended recipient of this e-mail, do not duplicate or redistribute it > by any means. Please delete it and any attachments and notify the = sender > that you have received it in error. Unintended recipients are = prohibited > from taking action on the basis of information in this e-mail.E-mail > messages may contain computer viruses or other defects, may not be > accurately replicated on other systems, or may be intercepted, deleted > or interfered with without the knowledge of the sender or the intended > recipient. If you are not comfortable with the risks associated with > e-mail messages, you may decide not to use e-mail to communicate with > IPC. IPC reserves the right, to the extent and under circumstances > permitted by applicable law, to retain, monitor and intercept e-mail > messages to and from its systems. > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec ------_=_NextPart_001_01CBF22F.59C5AE79 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [siprec] extensionData in XML=0A= =0A= =0A= =0A=
=0A=
=0A=
=0A=
=0A=
Hadriel,
=0A=
 
=0A=
I guess we have common = understaning to the extend that the intention is to send = some extensiondata (Unknown) attribute by SRC which may or may not = understand by SRS and also for the usage of xs:any as the = solution.  Few stuff are missing in yours proposal w.r.t = partial data passing of extensiondata:
=0A=
 
=0A=
The question is = whether there is a need to pass the extension data during = every time the corresponding metadata block is passed or updated. For = example, CS metadata block sends extension data specific to call center = data like Agent is remote or local, agent or customer initiated = call (direction) during the CS block creation (INVITE) and these = constant information in extensiondata is not required to = be passed in each update of CS metadata like adding video stream in the mid-session.
=0A=
 
=0A=
The current model allows to = pass extensiondata only during the initial CS block creation and there = is no need to update or resend while CS block is getting updated = with other CS = information. IMO, The current extensiondata mechanism = is required as SIPREC puts lot of call centre specific attributes = proposed during metadata model draft review as outside the scope of = SIPREC and most of the attributes mentioned are constant = within the scope of session.
=0A=
 
=0A=
Also, it is possible to pass = update only extension data within RS session without impacting = parent element. Please let me know your and others opinion whethter it = is fine to continue with the current extension-data element or to move = xs:any element to each of the metadata block.
=0A=
 
=0A=
Thanks
=0A=
Partha
=0A=
=0A=
=0A=
From: Hadriel Kaplan = [mailto:HKaplan@acmepacket.com]
Sent: Sat 4/2/2011 6:19 = PM
To: Parthasarathi R (partr)
Cc: Jain, Rajnish; = siprec@ietf.org
Subject: Re: [siprec] extensionData in = XML

=0A=
=0A=

Hi Partha,
I think you're missing my point (or I'm = missing yours) - you can do all of that without specifying an = "extensionData" XML element.  Unknown XML elements are simply = ignored by the other side, so Cisco can add a "ciscoPrivateData" XML = element wherever it wants and send it to an Acme; and that private = element will be ignored by Acme while everything else will continue to = work.  Which I think is the behavior you want, = right?

-hadriel


On Apr 1, 2011, at 10:37 AM, = Parthasarathi R (partr) wrote:

> Hadriel/Raj,
>
> = Extensiondata XML is provided as per Metadata model extensiondata = block.
> During the initial discussion of metadata model draft, we = realized that
> lot of attributes specified for recording are call = center specific or
> specific domain related and it is outside the = scope of IETF SIPREC but
> it is required for those specific = solution to work. Extensiondata XML
> element helps to meet those = requirement.
>
> Extensiondata is provided with URN UUID to = pass or not pass
> independently in partial data. But it is open = item whether extensiondata
> has to be within specific = metadatablock or not.
>
> Please read inline for more = comments.
>
> Thanks
> Partha
>
> = -----Original Message-----
> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf
> Of Jain, Rajnish
> Sent: Friday, April 01, = 2011 6:41 PM
> To: Hadriel Kaplan; siprec@ietf.org
> = Subject: Re: [siprec] extensionData in XML
>
> There may be = such motivation from how the CSTA standards are specified.
> They = have an element called privateData for each message. It is a
> = placeholder for any non-standardized extensions. This could be = legacy
> and may not mean much for the modern text based = protocols.
>
> <partha> I really didn't get the reason = why is it not require for modern
> text based protocols. This is = more like generic param in SIP or xs:any
> in XML. RFC 6120 is a = new RFC which has the similar usage.
> = </partha>
>
> That said, I think you're right (this = generally applies to any text
> based protocols and is the = fundamental basis for forward/backward
> compatibility in such = protocols).
>
> Raj
>
>
> = -----------------------------------------------------
> Please = consider the environment before printing this email.
>
>> = -----Original Message-----
>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On
>> Behalf Of Hadriel Kaplan
>> Sent: Thursday, = March 31, 2011 8:43 PM
>> To: siprec@ietf.org
>> = Subject: [siprec] extensionData in XML
>>
>> = Howdy,
>> With regards to the extensionData concept and XML, I = have a few basic
>> questions.  I am by no means an XML = expert so it could just be my lack
>
>> of knowledge = which makes me confused.  If so, just tell me to = RTFM.
>>
>> draft-ram-siprec-metadata-04 says in = section 4.6:
>>   A recording metadata object = contains additional data not specified
>> = as
>>   part of siprec.  This is intended to = accommodate future standards
>>   track extensions, = as well as vendor and user specific extensions.
>>   = The mechanism MUST provide a means of unambiguously = distinguishing
>>   such extension = data.
>>
>> What confuses me is I didn't think XML had = to do such machinations to
>> accommodate this need.  I = thought we could just specify in our RFCs
>> that unknown XML = elements and attributes MUST be ignored, so that
>> future RFCs = could add them without having to leave specific "blob" = XML
>
>> elements to carry such data.  Or at least = that's what we've done so
>> far in SIP RFCs with XML bodies, = afaik. 
>> namespace model that could be used to = disambiguate proprietary
>> elements from standard ones.  = If both of those theories are correct,
>> why do we need to = define an extensionData element?
>>
>> = -hadriel
>>
>> = _______________________________________________
>> siprec = mailing list
>> siprec@ietf.org
>> https://www.ietf.or= g/mailman/listinfo/siprec
>
> DISCLAIMER: This e-mail = may contain information that is confidential,
> privileged or = otherwise protected from disclosure. If you are not an
> intended = recipient of this e-mail, do not duplicate or redistribute it
> by = any means. Please delete it and any attachments and notify the = sender
> that you have received it in error. Unintended recipients = are prohibited
> from taking action on the basis of information in = this e-mail.E-mail
> messages may contain computer viruses or = other defects, may not be
> accurately replicated on other = systems, or may be intercepted, deleted
> or interfered with = without the knowledge of the sender or the intended
> recipient. = If you are not comfortable with the risks associated with
> e-mail = messages, you may decide not to use e-mail to communicate with
> = IPC. IPC reserves the right, to the extent and under = circumstances
> permitted by applicable law, to retain, monitor = and intercept e-mail
> messages to and from its systems.
> = _______________________________________________
> siprec mailing = list
> siprec@ietf.org
> https://www.ietf.or= g/mailman/listinfo/siprec

------_=_NextPart_001_01CBF22F.59C5AE79-- From rmohanr@cisco.com Sun Apr 3 20:40:49 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6CBA28C0CE for ; Sun, 3 Apr 2011 20:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.145 X-Spam-Level: X-Spam-Status: No, score=-10.145 tagged_above=-999 required=5 tests=[AWL=-0.146, BAYES_00=-2.599, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZaPU+Uy71gZo for ; Sun, 3 Apr 2011 20:40:47 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 1F9853A6910 for ; Sun, 3 Apr 2011 20:40:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=10127; q=dns/txt; s=iport; t=1301888548; x=1303098148; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=0Td9Bed71NpESnzybafK9IuzY6tmf3DgCev5jcahiuk=; b=lwDTrOiwfkU5m2MPRPxnT1aDOvZUpWb/DwD+AliodLGPJFPtnTJ/vS9y OcXLO52lWhZD1+WlSpVZSXXG3GzXG+GjgqYYM4iebaxxhqc6Wt6uDtS7D ycfkzYbOxHSJBIDcBzSfVp/8Nv5/M5ZPGJKA71VOdDZw19UyL1Y4gTYh/ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar0AAHo8mU2Q/khLgWdsb2JhbACYHI0/FAEBFiYliHmcI5p5hWsEhUWLPw X-IronPort-AV: E=Sophos;i="4.63,294,1299456000"; d="scan'208";a="24286073" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 04 Apr 2011 03:42:27 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p343gOHe006838; Mon, 4 Apr 2011 03:42:27 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 4 Apr 2011 09:12:25 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 4 Apr 2011 09:12:23 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD05DD8C2A@XMB-BGL-417.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] comments on draft-ram-siprec-metadata-04 Thread-Index: Acvr6KoPYFMcjPlASk+pOtN532GUhgBO/qTgAD5pH0AAJpm4YABBRncAAAC5KqAAKvS90AArRQBwAERwifAAE0OMcA== References: <35BCE99A477D6A4986FB2216D8CF2CFD05DD8BC3@XMB-BGL-417.cisco.com> From: "Ram Mohan R (rmohanr)" To: "Charles Eckel (eckelcu)" , "Elwell, John" , "Parthasarathi R (partr)" , X-OriginalArrivalTime: 04 Apr 2011 03:42:25.0563 (UTC) FILETIME=[5032CEB0:01CBF27A] Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 04 Apr 2011 03:40:49 -0000 Hi Charles, Please see inline > -----Original Message----- > From: Charles Eckel (eckelcu) > Sent: Sunday, April 03, 2011 11:52 PM > To: Ram Mohan R (rmohanr); 'Elwell, John'; Parthasarathi R (partr); > 'siprec@ietf.org' > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 >=20 > Hi Ram, >=20 > I agree that main point focus of the metadata is the description of the > communication sessions(s); however, the metadata model contains a > recording session element, and the recording element contains > attributes specific to the recording session. For that reason, I think > it is misleading to say the metadata describes the communication > session. > Perhaps you are suggesting the recording session element should be > removed from the model, and it may be maintained in an unspecified > manner within the SRS? No I am not suggesting that. I think we need slightly better wording than that. Metadata describes the CS but is carried in RS. Metadata has information about CS participants, different transactions of CS(which are carried in RS). Metadata maps CS participants to the recorded media sent in RS. So to summarize Metadata describes the recorded media sent in RS and its relation to CS. Perhaps we could retain the wordings of the Req draft ? The requirement draft has Metadata: Information that describes recorded media and the CS to which they relate. Thoughts ? Ram >=20 > Cheers, > Charles >=20 > > -----Original Message----- > > From: Ram Mohan R (rmohanr) > > Sent: Saturday, April 02, 2011 11:41 AM > > To: Charles Eckel (eckelcu); Elwell, John; Parthasarathi R (partr); > siprec@ietf.org > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > > > Hi Charles, > > > > Inline > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > > Behalf Of Charles Eckel (eckelcu) > > > Sent: Friday, April 01, 2011 6:39 PM > > > To: Elwell, John; Parthasarathi R (partr); siprec@ietf.org > > > Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 > > > > > > How about: > > > > > > OLD: > > > Metadata is the data that describes the communication session. > > > > > > NEW: > > > Metadata is the data that describes the recording session, > including > > > the > > > communication sessions it is recording. > > > > This text seems to create more confusion. Please note Metadata does > not describe anything about RS. > > It describes only about CS. > > > > Ram > > > > > > > > Cheers, > > > Charles > > > > > > > -----Original Message----- > > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > Sent: Thursday, March 31, 2011 6:30 PM > > > > To: Charles Eckel (eckelcu); Parthasarathi R (partr); > siprec@ietf.org > > > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > > > > > > > Charles, > > > > > > > > OK, I see how you got there, but really it describes the CSs (and > CS > > > groups) that are being carried in > > > > the RS. Any ideas how better to word it? > > > > > > > > John > > > > > > > > > -----Original Message----- > > > > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > > > Sent: 31 March 2011 17:11 > > > > > To: Elwell, John; Parthasarathi R (partr); siprec@ietf.org > > > > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > > > > > > > > > Hi John, > > > > > > > > > > Please see inline. > > > > > > > > > > > -----Original Message----- > > > > > > From: Elwell, John [mailto:john.elwell@siemens- > enterprise.com] > > > > > > Sent: Wednesday, March 30, 2011 11:01 AM > > > > > > To: Charles Eckel (eckelcu); Parthasarathi R (partr); > > > > > siprec@ietf.org > > > > > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata- > 04 > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: siprec-bounces@ietf.org > > > > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Charles Eckel > > > > > (eckelcu) > > > > > > > Sent: 29 March 2011 15:38 > > > > > > > To: Parthasarathi R (partr); siprec@ietf.org > > > > > > > Subject: Re: [siprec] comments on draft-ram-siprec- > metadata-04 > > > > > > > > > > > > > > Hi Partha, > > > > > > > > > > > > > > Thanks for your response. This addresses all of my > concerns. > > > > > > > Please see > > > > > > > one additional clarification inline. > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Parthasarathi R (partr) > > > > > > > > Sent: Tuesday, March 29, 2011 10:31 AM > > > > > > > > To: Charles Eckel (eckelcu); siprec@ietf.org > > > > > > > > Subject: RE: [siprec] comments on draft-ram-siprec- > metadata- > > > 04 > > > > > > > > > > > > > > > > Charles, > > > > > > > > > > > > > > > > Thanks for review the document. Please read inline. > > > > > > > > > > > > > > > > Thanks > > > > > > > > Partha > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: siprec-bounces@ietf.org > > > > > [mailto:siprec-bounces@ietf.org] On > > > > > > > Behalf Of Charles Eckel (eckelcu) > > > > > > > > Sent: Sunday, March 27, 2011 12:35 AM > > > > > > > > To: siprec@ietf.org > > > > > > > > Subject: [siprec] comments on draft-ram-siprec-metadata- > 04 > > > > > > > > > > > > > > > > I gave the draft and read and have the following > comments. > > > > > > > > > > > > > > > > Section 3. Think the metadata describes the recording > > > > > > > session, not the > > > > > > > communication session. Replace > > > > > > > > "metamodel" with "metadata model", and "MAY be conveyed > in > > > > > Recording > > > > > > > Session" with "MAY be conveyed > > > > > > > > within the Recording Session", and "time a change > occurred by > > > be > > > > > > > assumed" with "time a change occurred > > > > > > > > may be assumed". > > > > > > [JRE] I am not sure exactly what text Charles was commenting > on, > > > but > > > > > in my opinion metadata describes > > > > > > a CS (and how media streams in the RS relate to that CS), > > > > > rather than > > > > > describing the RS. > > > > > > > > > > > > John (as individual) > > > > > > > > > > The metadata model is anchored by an element for the RS. This > > > > > recording > > > > > session contains 0 or more CS group each with 1 or more CS. > > > > > This is what > > > > > led to my comment that the metadata model describes an RS > > > > > rather than a > > > > > CS. > > > > > > > > > > Cheers, > > > > > Charles > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Section 4, suggest rewording as, "The section describes > each > > > > > element > > > > > > > of the metadata model, and the > > > > > > > > attributes of each element. This section also describes > how > > > the > > > > > > > different elements are associated." > > > > > > > > > > > > > > > > Section 4.1, RecordingRequestorID is not really an ID, it > > > > > > > is more of a > > > > > > > type. I think > > > > > > > > RecordingRequestor is more appropriate. > > > > > > > > > > > > > > > > > > > > > > > > Agreed. We will update in the next revision > > > > > > > > > > > > > > > > > That said, I think you also need a unique ID for the > > > Recording > > > > > > > Session, right? > > > > > > > > Please clarify whether you are interested in > AOR of > > > RS > > > > > or > > > > > > > just ID. In the model, Recording > > > > > > > > (1..*) is related to CSG (0..*) and there is no need of > > > separate > > > > > > > attribute for unique id. In the > > > > > > > > metadata format, URN UUID in CSG (group) & recording > exist > > > > > > > which helps > > > > > > > to visualize the association > > > > > > > > > > > > > > > > > > > > > > I am assuming there is a need to distinguish one RS from > > > > > > > another RS, and > > > > > > > that is the reason I was recommending adding a unique ID. > > > > > > > This ID would > > > > > > > not be the RS AOR as that may not be unique. > > > > > > > > > > > > > > Cheers, > > > > > > > Charles > > > > > > > > > > > > > > > Section 4.2.1, replace "SRC (or MAY be SRS)" with "SRC or > > > SRS". > > > > > > > > Agreed. We will update in the next revision > > > > > > > > > > > > > > > > > Section 4.3.2, why does a CS need two participants or > more? > > > > > > > What about > > > > > > > studio mode recording? > > > > > > > > > > > > > > > > Section 4.4.1, what is participant type and what is its > use, > > > or > > > > > why > > > > > > > needed? > > > > > > > > This attribute has to be removed as per the > > > > > last interim > > > > > > > meeting. We will update in the next > > > > > > > > revision. > > > > > > > > > > > > > > > > Section 4.5, I think Media Stream requires a unique ID > > > attribute > > > > > as > > > > > > > well. > > > > > > > > As mentioned above in the model draft, the > > > association > > > > > > > between CS and participant is shown. > > > > > > > > In terms of format draft, it is represented by URN UUID > > > > > > > > > > > > > Is the "Media Stream Reference" the SDP label attribute? > > > > > > > > Your understanding is correct > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Charles > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > siprec mailing list > > > > > > > > siprec@ietf.org > > > > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > _______________________________________________ > > > > > > > siprec mailing list > > > > > > > siprec@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > > > > > > > > _______________________________________________ > > > siprec mailing list > > > siprec@ietf.org > > > https://www.ietf.org/mailman/listinfo/siprec From eckelcu@cisco.com Mon Apr 4 00:40:24 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C5BF3A6931 for ; Mon, 4 Apr 2011 00:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.536 X-Spam-Level: X-Spam-Status: No, score=-6.536 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_25=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kf2VJZhL0Kjb for ; Mon, 4 Apr 2011 00:40:17 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id F12793A692D for ; Mon, 4 Apr 2011 00:40:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=9693; q=dns/txt; s=iport; t=1301902919; x=1303112519; h=subject:references:content-transfer-encoding:from: in-reply-to:message-id:date:to:cc:mime-version; bh=DpLtnFK+fiZqbRSpft8hLxhGDFUt7KGNln1qialpwqc=; b=CJ/i7OURgq2fXP+1Z8JHX3GzZOqikOam4LpywbEXwlKxuUsDC3W5Cp6p XmCOINOHWF3emY3DPKJnXyMBuJ6tnnpiHUMPFNcjsrrQBs0Z4tMrjTisB NKbYJwDABwQ8mSperHzT4MmO9QFAsX/XiX9EwkzuqgPpWUyTxuLGn5CF1 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al8BAHN1mU2rRDoJ/2dsb2JhbACYG4xfYAJ3iHmbYJsMhWsEjSODYQ X-IronPort-AV: E=Sophos;i="4.63,296,1299456000"; d="scan'208";a="675174817" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-6.cisco.com with ESMTP; 04 Apr 2011 07:41:59 +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 p347fxqx027432; Mon, 4 Apr 2011 07:41:59 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, 4 Apr 2011 00:41:59 -0700 Received: from 72.163.63.12 ([72.163.63.12]) by xmb-sjc-234.amer.cisco.com ([128.107.191.111]) with Microsoft Exchange Server HTTP-DAV ; Mon, 4 Apr 2011 07:41:58 +0000 References: <35BCE99A477D6A4986FB2216D8CF2CFD05DD8BC3@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD05DD8C2A@XMB-BGL-417.cisco.com> Content-Transfer-Encoding: quoted-printable From: "Charles Eckel (eckelcu)" Content-Type: text/plain; charset="us-ascii" Thread-Topic: [siprec] comments on draft-ram-siprec-metadata-04 thread-index: Acvym8c6ze1biSmuSseX9NIPrqwitA== In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD05DD8C2A@XMB-BGL-417.cisco.com> Message-ID: Date: Mon, 4 Apr 2011 09:41:51 +0200 To: "Ram Mohan R (rmohanr)" MIME-Version: 1.0 (iPhone Mail 8C148a) X-OriginalArrivalTime: 04 Apr 2011 07:41:59.0142 (UTC) FILETIME=[C784E860:01CBF29B] Cc: siprec@ietf.org Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 04 Apr 2011 07:40:24 -0000 Sure, that wording works for me.=20 Thanks, Charles On Apr 4, 2011, at 5:42 AM, "Ram Mohan R (rmohanr)" wrot= e: > Hi Charles, >=20 > Please see inline >=20 >> -----Original Message----- >> From: Charles Eckel (eckelcu) >> Sent: Sunday, April 03, 2011 11:52 PM >> To: Ram Mohan R (rmohanr); 'Elwell, John'; Parthasarathi R (partr); >> 'siprec@ietf.org' >> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 >>=20 >> Hi Ram, >>=20 >> I agree that main point focus of the metadata is the description of > the >> communication sessions(s); however, the metadata model contains a >> recording session element, and the recording element contains >> attributes specific to the recording session. For that reason, I think >> it is misleading to say the metadata describes the communication >> session. >> Perhaps you are suggesting the recording session element should be >> removed from the model, and it may be maintained in an unspecified >> manner within the SRS? >=20 > No I am not suggesting that. I think we need slightly better wording > than that. > Metadata describes the CS but is carried in RS. Metadata has information > about CS participants, different transactions of CS(which are carried in > RS). Metadata maps CS participants to the recorded media sent in RS. > So to summarize Metadata describes the recorded media sent in RS and its > relation to CS. >=20 > Perhaps we could retain the wordings of the Req draft ? > The requirement draft has > Metadata: Information that describes recorded media and the CS to > which they relate. >=20 > Thoughts ? >=20 > Ram >=20 >>=20 >> Cheers, >> Charles >>=20 >>> -----Original Message----- >>> From: Ram Mohan R (rmohanr) >>> Sent: Saturday, April 02, 2011 11:41 AM >>> To: Charles Eckel (eckelcu); Elwell, John; Parthasarathi R (partr); >> siprec@ietf.org >>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 >>>=20 >>> Hi Charles, >>>=20 >>> Inline >>>=20 >>>> -----Original Message----- >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>>> Behalf Of Charles Eckel (eckelcu) >>>> Sent: Friday, April 01, 2011 6:39 PM >>>> To: Elwell, John; Parthasarathi R (partr); siprec@ietf.org >>>> Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 >>>>=20 >>>> How about: >>>>=20 >>>> OLD: >>>> Metadata is the data that describes the communication session. >>>>=20 >>>> NEW: >>>> Metadata is the data that describes the recording session, >> including >>>> the >>>> communication sessions it is recording. >>>=20 >>> This text seems to create more confusion. Please note Metadata does >> not describe anything about RS. >>> It describes only about CS. >>>=20 >>> Ram >>>=20 >>>>=20 >>>> Cheers, >>>> Charles >>>>=20 >>>>> -----Original Message----- >>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>>>> Sent: Thursday, March 31, 2011 6:30 PM >>>>> To: Charles Eckel (eckelcu); Parthasarathi R (partr); >> siprec@ietf.org >>>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 >>>>>=20 >>>>> Charles, >>>>>=20 >>>>> OK, I see how you got there, but really it describes the CSs > (and >> CS >>>> groups) that are being carried in >>>>> the RS. Any ideas how better to word it? >>>>>=20 >>>>> John >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] >>>>>> Sent: 31 March 2011 17:11 >>>>>> To: Elwell, John; Parthasarathi R (partr); siprec@ietf.org >>>>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 >>>>>>=20 >>>>>> Hi John, >>>>>>=20 >>>>>> Please see inline. >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Elwell, John [mailto:john.elwell@siemens- >> enterprise.com] >>>>>>> Sent: Wednesday, March 30, 2011 11:01 AM >>>>>>> To: Charles Eckel (eckelcu); Parthasarathi R (partr); >>>>>> siprec@ietf.org >>>>>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata- >> 04 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: siprec-bounces@ietf.org >>>>>>>> [mailto:siprec-bounces@ietf.org] On Behalf Of Charles > Eckel >>>>>> (eckelcu) >>>>>>>> Sent: 29 March 2011 15:38 >>>>>>>> To: Parthasarathi R (partr); siprec@ietf.org >>>>>>>> Subject: Re: [siprec] comments on draft-ram-siprec- >> metadata-04 >>>>>>>>=20 >>>>>>>> Hi Partha, >>>>>>>>=20 >>>>>>>> Thanks for your response. This addresses all of my >> concerns. >>>>>>>> Please see >>>>>>>> one additional clarification inline. >>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: Parthasarathi R (partr) >>>>>>>>> Sent: Tuesday, March 29, 2011 10:31 AM >>>>>>>>> To: Charles Eckel (eckelcu); siprec@ietf.org >>>>>>>>> Subject: RE: [siprec] comments on draft-ram-siprec- >> metadata- >>>> 04 >>>>>>>>>=20 >>>>>>>>> Charles, >>>>>>>>>=20 >>>>>>>>> Thanks for review the document. Please read inline. >>>>>>>>>=20 >>>>>>>>> Thanks >>>>>>>>> Partha >>>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: siprec-bounces@ietf.org >>>>>> [mailto:siprec-bounces@ietf.org] On >>>>>>>> Behalf Of Charles Eckel (eckelcu) >>>>>>>>> Sent: Sunday, March 27, 2011 12:35 AM >>>>>>>>> To: siprec@ietf.org >>>>>>>>> Subject: [siprec] comments on draft-ram-siprec-metadata- >> 04 >>>>>>>>>=20 >>>>>>>>> I gave the draft and read and have the following >> comments. >>>>>>>>>=20 >>>>>>>>> Section 3. Think the metadata describes the recording >>>>>>>> session, not the >>>>>>>> communication session. Replace >>>>>>>>> "metamodel" with "metadata model", and "MAY be conveyed >> in >>>>>> Recording >>>>>>>> Session" with "MAY be conveyed >>>>>>>>> within the Recording Session", and "time a change >> occurred by >>>> be >>>>>>>> assumed" with "time a change occurred >>>>>>>>> may be assumed". >>>>>>> [JRE] I am not sure exactly what text Charles was commenting >> on, >>>> but >>>>>> in my opinion metadata describes >>>>>>> a CS (and how media streams in the RS relate to that CS), >>>>>> rather than >>>>>> describing the RS. >>>>>>>=20 >>>>>>> John (as individual) >>>>>>=20 >>>>>> The metadata model is anchored by an element for the RS. This >>>>>> recording >>>>>> session contains 0 or more CS group each with 1 or more CS. >>>>>> This is what >>>>>> led to my comment that the metadata model describes an RS >>>>>> rather than a >>>>>> CS. >>>>>>=20 >>>>>> Cheers, >>>>>> Charles >>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Section 4, suggest rewording as, "The section describes >> each >>>>>> element >>>>>>>> of the metadata model, and the >>>>>>>>> attributes of each element. This section also describes >> how >>>> the >>>>>>>> different elements are associated." >>>>>>>>>=20 >>>>>>>>> Section 4.1, RecordingRequestorID is not really an ID, > it >>>>>>>> is more of a >>>>>>>> type. I think >>>>>>>>> RecordingRequestor is more appropriate. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Agreed. We will update in the next revision >> >>>>>>>>>=20 >>>>>>>>> That said, I think you also need a unique ID for the >>>> Recording >>>>>>>> Session, right? >>>>>>>>> Please clarify whether you are interested in >> AOR of >>>> RS >>>>>> or >>>>>>>> just ID. In the model, Recording >>>>>>>>> (1..*) is related to CSG (0..*) and there is no need of >>>> separate >>>>>>>> attribute for unique id. In the >>>>>>>>> metadata format, URN UUID in CSG (group) & recording >> exist >>>>>>>> which helps >>>>>>>> to visualize the association >>>>>>>>> >>>>>>>>=20 >>>>>>>> I am assuming there is a need to distinguish one RS from >>>>>>>> another RS, and >>>>>>>> that is the reason I was recommending adding a unique ID. >>>>>>>> This ID would >>>>>>>> not be the RS AOR as that may not be unique. >>>>>>>>=20 >>>>>>>> Cheers, >>>>>>>> Charles >>>>>>>>=20 >>>>>>>>> Section 4.2.1, replace "SRC (or MAY be SRS)" with "SRC > or >>>> SRS". >>>>>>>>> Agreed. We will update in the next revision >> >>>>>>>>>=20 >>>>>>>>> Section 4.3.2, why does a CS need two participants or >> more? >>>>>>>> What about >>>>>>>> studio mode recording? >>>>>>>>>=20 >>>>>>>>> Section 4.4.1, what is participant type and what is its >> use, >>>> or >>>>>> why >>>>>>>> needed? >>>>>>>>> This attribute has to be removed as per the >>>>>> last interim >>>>>>>> meeting. We will update in the next >>>>>>>>> revision. >>>>>>>>>=20 >>>>>>>>> Section 4.5, I think Media Stream requires a unique ID >>>> attribute >>>>>> as >>>>>>>> well. >>>>>>>>> As mentioned above in the model draft, the >>>> association >>>>>>>> between CS and participant is shown. >>>>>>>>> In terms of format draft, it is represented by URN UUID >>>>>> >>>>>>>>> Is the "Media Stream Reference" the SDP label attribute? >>>>>>>>> Your understanding is correct >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Thanks, >>>>>>>>> Charles >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> siprec mailing list >>>>>>>>> siprec@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>>> _______________________________________________ >>>>>>>> siprec mailing list >>>>>>>> siprec@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>>>=20 >>>>>>=20 >>>> _______________________________________________ >>>> siprec mailing list >>>> siprec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/siprec From rmohanr@cisco.com Mon Apr 4 01:10:55 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D71F28C0D0 for ; Mon, 4 Apr 2011 01:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.135 X-Spam-Level: X-Spam-Status: No, score=-10.135 tagged_above=-999 required=5 tests=[AWL=-0.137, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ybkexfyLpxdP for ; Mon, 4 Apr 2011 01:10:44 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 4E7443A6935 for ; Mon, 4 Apr 2011 01:10:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=27808; q=dns/txt; s=iport; t=1301904742; x=1303114342; h=mime-version:subject:date:message-id:references:from:to: cc; bh=sBd3roK4rkK3+wBKoWicr85FnFKLsY0p59cN5WQIDr8=; b=N5uIpsZbC9j3t/f9/J6EPshY+YWg7C2Tj4MhnnO5hUem9xlcdtF+fGCo MAWt/lFKhgs5amboIEc6gb6raA2+ZazC4wH99aEthPDjFworXC9aBEMZw 7nHp3hPF4vCu5qMkXdfbBF5/HVud9R9j3VZUd/PFweUBW+LUtbNaVS0xQ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuoAAHR8mU2Q/khLgWdsb2JhbACYHI1BFAEBFiYliHmbX5sNhWsEhUWLPw X-IronPort-AV: E=Sophos;i="4.63,296,1299456000"; d="scan'208,217";a="82042656" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 04 Apr 2011 08:12:20 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p348CJ97010108; Mon, 4 Apr 2011 08:12:20 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); Mon, 4 Apr 2011 13:42:19 +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_01CBF2A0.046B548E" Date: Mon, 4 Apr 2011 13:41:35 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD01346BF1@XMB-BGL-417.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] comments on draft-ram-siprec-metadata-04 Thread-Index: Acvym8c6ze1biSmuSseX9NIPrqwitAABCNAT References: <35BCE99A477D6A4986FB2216D8CF2CFD05DD8BC3@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD05DD8C2A@XMB-BGL-417.cisco.com> From: "Ram Mohan R (rmohanr)" To: "Charles Eckel (eckelcu)" X-OriginalArrivalTime: 04 Apr 2011 08:12:19.0779 (UTC) FILETIME=[04B41130:01CBF2A0] Cc: siprec@ietf.org Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 04 Apr 2011 08:10:55 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBF2A0.046B548E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable OK. I will update the same in the next revision. Ram -----Original Message----- From: Charles Eckel (eckelcu) Sent: Mon 4/4/2011 1:11 PM To: Ram Mohan R (rmohanr) Cc: Elwell, John; Parthasarathi R (partr); siprec@ietf.org Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 =20 Sure, that wording works for me.=20 Thanks, Charles On Apr 4, 2011, at 5:42 AM, "Ram Mohan R (rmohanr)" = wrote: > Hi Charles, >=20 > Please see inline >=20 >> -----Original Message----- >> From: Charles Eckel (eckelcu) >> Sent: Sunday, April 03, 2011 11:52 PM >> To: Ram Mohan R (rmohanr); 'Elwell, John'; Parthasarathi R (partr); >> 'siprec@ietf.org' >> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 >>=20 >> Hi Ram, >>=20 >> I agree that main point focus of the metadata is the description of > the >> communication sessions(s); however, the metadata model contains a >> recording session element, and the recording element contains >> attributes specific to the recording session. For that reason, I = think >> it is misleading to say the metadata describes the communication >> session. >> Perhaps you are suggesting the recording session element should be >> removed from the model, and it may be maintained in an unspecified >> manner within the SRS? >=20 > No I am not suggesting that. I think we need slightly better wording > than that. > Metadata describes the CS but is carried in RS. Metadata has = information > about CS participants, different transactions of CS(which are carried = in > RS). Metadata maps CS participants to the recorded media sent in RS. > So to summarize Metadata describes the recorded media sent in RS and = its > relation to CS. >=20 > Perhaps we could retain the wordings of the Req draft ? > The requirement draft has > Metadata: Information that describes recorded media and the CS to > which they relate. >=20 > Thoughts ? >=20 > Ram >=20 >>=20 >> Cheers, >> Charles >>=20 >>> -----Original Message----- >>> From: Ram Mohan R (rmohanr) >>> Sent: Saturday, April 02, 2011 11:41 AM >>> To: Charles Eckel (eckelcu); Elwell, John; Parthasarathi R (partr); >> siprec@ietf.org >>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 >>>=20 >>> Hi Charles, >>>=20 >>> Inline >>>=20 >>>> -----Original Message----- >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>>> Behalf Of Charles Eckel (eckelcu) >>>> Sent: Friday, April 01, 2011 6:39 PM >>>> To: Elwell, John; Parthasarathi R (partr); siprec@ietf.org >>>> Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 >>>>=20 >>>> How about: >>>>=20 >>>> OLD: >>>> Metadata is the data that describes the communication session. >>>>=20 >>>> NEW: >>>> Metadata is the data that describes the recording session, >> including >>>> the >>>> communication sessions it is recording. >>>=20 >>> This text seems to create more confusion. Please note Metadata does >> not describe anything about RS. >>> It describes only about CS. >>>=20 >>> Ram >>>=20 >>>>=20 >>>> Cheers, >>>> Charles >>>>=20 >>>>> -----Original Message----- >>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>>>> Sent: Thursday, March 31, 2011 6:30 PM >>>>> To: Charles Eckel (eckelcu); Parthasarathi R (partr); >> siprec@ietf.org >>>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 >>>>>=20 >>>>> Charles, >>>>>=20 >>>>> OK, I see how you got there, but really it describes the CSs > (and >> CS >>>> groups) that are being carried in >>>>> the RS. Any ideas how better to word it? >>>>>=20 >>>>> John >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] >>>>>> Sent: 31 March 2011 17:11 >>>>>> To: Elwell, John; Parthasarathi R (partr); siprec@ietf.org >>>>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 >>>>>>=20 >>>>>> Hi John, >>>>>>=20 >>>>>> Please see inline. >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Elwell, John [mailto:john.elwell@siemens- >> enterprise.com] >>>>>>> Sent: Wednesday, March 30, 2011 11:01 AM >>>>>>> To: Charles Eckel (eckelcu); Parthasarathi R (partr); >>>>>> siprec@ietf.org >>>>>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata- >> 04 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: siprec-bounces@ietf.org >>>>>>>> [mailto:siprec-bounces@ietf.org] On Behalf Of Charles > Eckel >>>>>> (eckelcu) >>>>>>>> Sent: 29 March 2011 15:38 >>>>>>>> To: Parthasarathi R (partr); siprec@ietf.org >>>>>>>> Subject: Re: [siprec] comments on draft-ram-siprec- >> metadata-04 >>>>>>>>=20 >>>>>>>> Hi Partha, >>>>>>>>=20 >>>>>>>> Thanks for your response. This addresses all of my >> concerns. >>>>>>>> Please see >>>>>>>> one additional clarification inline. >>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: Parthasarathi R (partr) >>>>>>>>> Sent: Tuesday, March 29, 2011 10:31 AM >>>>>>>>> To: Charles Eckel (eckelcu); siprec@ietf.org >>>>>>>>> Subject: RE: [siprec] comments on draft-ram-siprec- >> metadata- >>>> 04 >>>>>>>>>=20 >>>>>>>>> Charles, >>>>>>>>>=20 >>>>>>>>> Thanks for review the document. Please read inline. >>>>>>>>>=20 >>>>>>>>> Thanks >>>>>>>>> Partha >>>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: siprec-bounces@ietf.org >>>>>> [mailto:siprec-bounces@ietf.org] On >>>>>>>> Behalf Of Charles Eckel (eckelcu) >>>>>>>>> Sent: Sunday, March 27, 2011 12:35 AM >>>>>>>>> To: siprec@ietf.org >>>>>>>>> Subject: [siprec] comments on draft-ram-siprec-metadata- >> 04 >>>>>>>>>=20 >>>>>>>>> I gave the draft and read and have the following >> comments. >>>>>>>>>=20 >>>>>>>>> Section 3. Think the metadata describes the recording >>>>>>>> session, not the >>>>>>>> communication session. Replace >>>>>>>>> "metamodel" with "metadata model", and "MAY be conveyed >> in >>>>>> Recording >>>>>>>> Session" with "MAY be conveyed >>>>>>>>> within the Recording Session", and "time a change >> occurred by >>>> be >>>>>>>> assumed" with "time a change occurred >>>>>>>>> may be assumed". >>>>>>> [JRE] I am not sure exactly what text Charles was commenting >> on, >>>> but >>>>>> in my opinion metadata describes >>>>>>> a CS (and how media streams in the RS relate to that CS), >>>>>> rather than >>>>>> describing the RS. >>>>>>>=20 >>>>>>> John (as individual) >>>>>>=20 >>>>>> The metadata model is anchored by an element for the RS. This >>>>>> recording >>>>>> session contains 0 or more CS group each with 1 or more CS. >>>>>> This is what >>>>>> led to my comment that the metadata model describes an RS >>>>>> rather than a >>>>>> CS. >>>>>>=20 >>>>>> Cheers, >>>>>> Charles >>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Section 4, suggest rewording as, "The section describes >> each >>>>>> element >>>>>>>> of the metadata model, and the >>>>>>>>> attributes of each element. This section also describes >> how >>>> the >>>>>>>> different elements are associated." >>>>>>>>>=20 >>>>>>>>> Section 4.1, RecordingRequestorID is not really an ID, > it >>>>>>>> is more of a >>>>>>>> type. I think >>>>>>>>> RecordingRequestor is more appropriate. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Agreed. We will update in the next revision >> >>>>>>>>>=20 >>>>>>>>> That said, I think you also need a unique ID for the >>>> Recording >>>>>>>> Session, right? >>>>>>>>> Please clarify whether you are interested in >> AOR of >>>> RS >>>>>> or >>>>>>>> just ID. In the model, Recording >>>>>>>>> (1..*) is related to CSG (0..*) and there is no need of >>>> separate >>>>>>>> attribute for unique id. In the >>>>>>>>> metadata format, URN UUID in CSG (group) & recording >> exist >>>>>>>> which helps >>>>>>>> to visualize the association >>>>>>>>> >>>>>>>>=20 >>>>>>>> I am assuming there is a need to distinguish one RS from >>>>>>>> another RS, and >>>>>>>> that is the reason I was recommending adding a unique ID. >>>>>>>> This ID would >>>>>>>> not be the RS AOR as that may not be unique. >>>>>>>>=20 >>>>>>>> Cheers, >>>>>>>> Charles >>>>>>>>=20 >>>>>>>>> Section 4.2.1, replace "SRC (or MAY be SRS)" with "SRC > or >>>> SRS". >>>>>>>>> Agreed. We will update in the next revision >> >>>>>>>>>=20 >>>>>>>>> Section 4.3.2, why does a CS need two participants or >> more? >>>>>>>> What about >>>>>>>> studio mode recording? >>>>>>>>>=20 >>>>>>>>> Section 4.4.1, what is participant type and what is its >> use, >>>> or >>>>>> why >>>>>>>> needed? >>>>>>>>> This attribute has to be removed as per the >>>>>> last interim >>>>>>>> meeting. We will update in the next >>>>>>>>> revision. >>>>>>>>>=20 >>>>>>>>> Section 4.5, I think Media Stream requires a unique ID >>>> attribute >>>>>> as >>>>>>>> well. >>>>>>>>> As mentioned above in the model draft, the >>>> association >>>>>>>> between CS and participant is shown. >>>>>>>>> In terms of format draft, it is represented by URN UUID >>>>>> >>>>>>>>> Is the "Media Stream Reference" the SDP label attribute? >>>>>>>>> Your understanding is correct >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Thanks, >>>>>>>>> Charles >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> siprec mailing list >>>>>>>>> siprec@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>>> _______________________________________________ >>>>>>>> siprec mailing list >>>>>>>> siprec@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>>>=20 >>>>>>=20 >>>> _______________________________________________ >>>> siprec mailing list >>>> siprec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/siprec ------_=_NextPart_001_01CBF2A0.046B548E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [siprec] comments on draft-ram-siprec-metadata-04

OK.
I will update the same in the next revision.

Ram

-----Original Message-----
From: Charles Eckel (eckelcu)
Sent: Mon 4/4/2011 1:11 PM
To: Ram Mohan R (rmohanr)
Cc: Elwell, John; Parthasarathi R (partr); siprec@ietf.org
Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04

Sure, that wording works for me.

Thanks,
Charles



On Apr 4, 2011, at 5:42 AM, "Ram Mohan R (rmohanr)" = <rmohanr@cisco.com> wrote:

> Hi Charles,
>
> Please see inline
>
>> -----Original Message-----
>> From: Charles Eckel (eckelcu)
>> Sent: Sunday, April 03, 2011 11:52 PM
>> To: Ram Mohan R (rmohanr); 'Elwell, John'; Parthasarathi R = (partr);
>> 'siprec@ietf.org'
>> Subject: RE: [siprec] comments on = draft-ram-siprec-metadata-04
>>
>> Hi Ram,
>>
>> I agree that main point focus of the metadata is the = description of
> the
>> communication sessions(s); however, the metadata model contains = a
>> recording session element, and the recording element = contains
>> attributes specific to the recording session. For that reason, = I think
>> it is misleading to say the metadata describes the = communication
>> session.
>> Perhaps you are suggesting the recording session element should = be
>> removed from the model, and it may be maintained in an = unspecified
>> manner within the SRS?
>
> No I am not suggesting that.  I think we need slightly better = wording
> than that.
> Metadata describes the CS but is carried in RS. Metadata has = information
> about CS participants, different transactions of CS(which are = carried in
> RS). Metadata maps  CS participants to the recorded media sent = in RS.
> So to summarize Metadata describes the recorded media sent in RS = and its
> relation to CS.
>
> Perhaps we could retain the wordings of the Req draft ?
> The requirement draft has
> Metadata: Information that describes recorded media and the CS = to
> which they relate.
>
> Thoughts ?
>
> Ram
>
>>
>> Cheers,
>> Charles
>>
>>> -----Original Message-----
>>> From: Ram Mohan R (rmohanr)
>>> Sent: Saturday, April 02, 2011 11:41 AM
>>> To: Charles Eckel (eckelcu); Elwell, John; Parthasarathi R = (partr);
>> siprec@ietf.org
>>> Subject: RE: [siprec] comments on = draft-ram-siprec-metadata-04
>>>
>>> Hi Charles,
>>>
>>> Inline
>>>
>>>> -----Original Message-----
>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On
>>>> Behalf Of Charles Eckel (eckelcu)
>>>> Sent: Friday, April 01, 2011 6:39 PM
>>>> To: Elwell, John; Parthasarathi R (partr); = siprec@ietf.org
>>>> Subject: Re: [siprec] comments on = draft-ram-siprec-metadata-04
>>>>
>>>> How about:
>>>>
>>>> OLD:
>>>> Metadata is the data that describes the communication = session.
>>>>
>>>> NEW:
>>>> Metadata is the data that describes the recording = session,
>> including
>>>> the
>>>> communication sessions it is recording.
>>>
>>> This  text seems to create more confusion. Please note = Metadata does
>> not describe anything about RS.
>>> It describes only about CS.
>>>
>>> Ram
>>>
>>>>
>>>> Cheers,
>>>> Charles
>>>>
>>>>> -----Original Message-----
>>>>> From: Elwell, John [mailto:john.elwell@sie= mens-enterprise.com]
>>>>> Sent: Thursday, March 31, 2011 6:30 PM
>>>>> To: Charles Eckel (eckelcu); Parthasarathi R = (partr);
>> siprec@ietf.org
>>>>> Subject: RE: [siprec] comments on = draft-ram-siprec-metadata-04
>>>>>
>>>>> Charles,
>>>>>
>>>>> OK, I see how you got there, but really it = describes the CSs
> (and
>> CS
>>>> groups) that are being carried in
>>>>> the RS. Any ideas how better to word it?
>>>>>
>>>>> John
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com]
>>>>>> Sent: 31 March 2011 17:11
>>>>>> To: Elwell, John; Parthasarathi R (partr); = siprec@ietf.org
>>>>>> Subject: RE: [siprec] comments on = draft-ram-siprec-metadata-04
>>>>>>
>>>>>> Hi John,
>>>>>>
>>>>>> Please see inline.
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Elwell, John [mailto:john.elwell@siemens-
>> enterprise.com]
>>>>>>> Sent: Wednesday, March 30, 2011 11:01 = AM
>>>>>>> To: Charles Eckel (eckelcu); Parthasarathi = R (partr);
>>>>>> siprec@ietf.org
>>>>>>> Subject: RE: [siprec] comments on = draft-ram-siprec-metadata-
>> 04
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: siprec-bounces@ietf.org
>>>>>>>> [mailto:siprec-bounces@ietf.org] On Behalf Of Charles
> Eckel
>>>>>> (eckelcu)
>>>>>>>> Sent: 29 March 2011 15:38
>>>>>>>> To: Parthasarathi R (partr); = siprec@ietf.org
>>>>>>>> Subject: Re: [siprec] comments on = draft-ram-siprec-
>> metadata-04
>>>>>>>>
>>>>>>>> Hi Partha,
>>>>>>>>
>>>>>>>> Thanks for your response. This = addresses all of my
>> concerns.
>>>>>>>> Please see
>>>>>>>> one additional clarification = inline.
>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Parthasarathi R (partr)
>>>>>>>>> Sent: Tuesday, March 29, 2011 10:31 = AM
>>>>>>>>> To: Charles Eckel (eckelcu); = siprec@ietf.org
>>>>>>>>> Subject: RE: [siprec] comments on = draft-ram-siprec-
>> metadata-
>>>> 04
>>>>>>>>>
>>>>>>>>> Charles,
>>>>>>>>>
>>>>>>>>> Thanks for review the document. = Please read inline.
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> Partha
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: siprec-bounces@ietf.org
>>>>>> [mailto:siprec-bounces@ietf.org] On
>>>>>>>> Behalf Of Charles Eckel (eckelcu)
>>>>>>>>> Sent: Sunday, March 27, 2011 12:35 = AM
>>>>>>>>> To: siprec@ietf.org
>>>>>>>>> Subject: [siprec] comments on = draft-ram-siprec-metadata-
>> 04
>>>>>>>>>
>>>>>>>>> I gave the draft and read and have = the following
>> comments.
>>>>>>>>>
>>>>>>>>> Section 3. Think the metadata = describes the recording
>>>>>>>> session, not the
>>>>>>>> communication session. Replace
>>>>>>>>> "metamodel" with = "metadata model", and "MAY be conveyed
>> in
>>>>>> Recording
>>>>>>>> Session" with "MAY be = conveyed
>>>>>>>>> within the Recording Session", = and "time a change
>> occurred by
>>>> be
>>>>>>>> assumed" with "time a change = occurred
>>>>>>>>> may be assumed".
>>>>>>> [JRE] I am not sure exactly what text = Charles was commenting
>> on,
>>>> but
>>>>>> in my opinion metadata describes
>>>>>>> a CS (and how media streams in the RS = relate to that CS),
>>>>>> rather than
>>>>>> describing the RS.
>>>>>>>
>>>>>>> John (as individual)
>>>>>>
>>>>>> The metadata model is anchored by an element = for the RS. This
>>>>>> recording
>>>>>> session contains 0 or more CS group each with 1 = or more CS.
>>>>>> This is what
>>>>>> led to my comment that the metadata model = describes an RS
>>>>>> rather than a
>>>>>> CS.
>>>>>>
>>>>>> Cheers,
>>>>>> Charles
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>
>>>>>>>>> Section 4, suggest rewording as, = "The section describes
>> each
>>>>>> element
>>>>>>>> of the metadata model, and the
>>>>>>>>> attributes of each element. This = section also describes
>> how
>>>> the
>>>>>>>> different elements are = associated."
>>>>>>>>>
>>>>>>>>> Section 4.1, RecordingRequestorID = is not really an ID,
> it
>>>>>>>> is more of a
>>>>>>>> type. I think
>>>>>>>>> RecordingRequestor is more = appropriate.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> <Partha>Agreed. We will = update in the next revision
>> </partha>
>>>>>>>>>
>>>>>>>>> That said, I think you also need a = unique ID for the
>>>> Recording
>>>>>>>> Session, right?
>>>>>>>>> <partha>  Please clarify = whether you are interested in
>> AOR of
>>>> RS
>>>>>> or
>>>>>>>> just ID. In the model, Recording
>>>>>>>>> (1..*) is related to CSG (0..*) and = there is no need of
>>>> separate
>>>>>>>> attribute for unique id. In the
>>>>>>>>> metadata format, URN UUID in CSG = (group) & recording
>> exist
>>>>>>>> which helps
>>>>>>>> to visualize the association
>>>>>>>>> </partha>
>>>>>>>>
>>>>>>>> I am assuming there is a need to = distinguish one RS from
>>>>>>>> another RS, and
>>>>>>>> that is the reason I was recommending = adding a unique ID.
>>>>>>>> This ID would
>>>>>>>> not be the RS AOR as that may not be = unique.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Charles
>>>>>>>>
>>>>>>>>> Section 4.2.1, replace "SRC = (or MAY be SRS)" with "SRC
> or
>>>> SRS".
>>>>>>>>> <Partha>Agreed. We will = update in the next revision
>> </partha>
>>>>>>>>>
>>>>>>>>> Section 4.3.2, why does a CS need = two participants or
>> more?
>>>>>>>> What about
>>>>>>>> studio mode recording?
>>>>>>>>>
>>>>>>>>> Section 4.4.1, what is participant = type and what is its
>> use,
>>>> or
>>>>>> why
>>>>>>>> needed?
>>>>>>>>> <partha> This attribute has = to be removed as per the
>>>>>> last interim
>>>>>>>> meeting. We will update in the next
>>>>>>>>> revision. </partha>
>>>>>>>>>
>>>>>>>>> Section 4.5, I think Media Stream = requires a unique ID
>>>> attribute
>>>>>> as
>>>>>>>> well.
>>>>>>>>> <partha> As mentioned above = in the model draft, the
>>>> association
>>>>>>>> between CS and participant is = shown.
>>>>>>>>> In terms of format draft, it is = represented by URN UUID
>>>>>> </partha>
>>>>>>>>> Is the "Media Stream = Reference" the SDP label attribute?
>>>>>>>>> <partha> Your understanding = is correct </partha>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Charles
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> = _______________________________________________
>>>>>>>>> siprec mailing list
>>>>>>>>> siprec@ietf.org
>>>>>>>>> https://www.ietf.or= g/mailman/listinfo/siprec
>>>>>>>> = _______________________________________________
>>>>>>>> siprec mailing list
>>>>>>>> siprec@ietf.org
>>>>>>>> https://www.ietf.or= g/mailman/listinfo/siprec
>>>>>>>>
>>>>>>
>>>> _______________________________________________
>>>> siprec mailing list
>>>> siprec@ietf.org
>>>> https://www.ietf.or= g/mailman/listinfo/siprec

------_=_NextPart_001_01CBF2A0.046B548E-- From Leon.Portman@nice.com Tue Apr 5 06:59:37 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2170128C115 for ; Tue, 5 Apr 2011 06:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.131 X-Spam-Level: X-Spam-Status: No, score=-2.131 tagged_above=-999 required=5 tests=[AWL=-0.132, BAYES_00=-2.599, J_CHICKENPOX_25=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QrHysfMvU77g for ; Tue, 5 Apr 2011 06:59:28 -0700 (PDT) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by core3.amsl.com (Postfix) with ESMTP id 3096F3A693B for ; Tue, 5 Apr 2011 06:59:28 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Tue, 5 Apr 2011 17:01:10 +0300 From: Leon Portman To: "Charles Eckel (eckelcu)" , "Ram Mohan R (rmohanr)" Date: Tue, 5 Apr 2011 17:01:09 +0300 Thread-Topic: [siprec] comments on draft-ram-siprec-metadata-04 Thread-Index: Acvym8c6ze1biSmuSseX9NIPrqwitAA/iB3w Message-ID: <07465C1D981ABC41A344374066AE1A2C38AB633694@TLVMBX01.nice.com> References: <35BCE99A477D6A4986FB2216D8CF2CFD05DD8BC3@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD05DD8C2A@XMB-BGL-417.cisco.com> In-Reply-To: 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] comments on draft-ram-siprec-metadata-04 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 05 Apr 2011 13:59:37 -0000 +1 Leon -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Charles Eckel (eckelcu) Sent: Monday, April 04, 2011 10:42 AM To: Ram Mohan R (rmohanr) Cc: siprec@ietf.org Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 Sure, that wording works for me.=20 Thanks, Charles On Apr 4, 2011, at 5:42 AM, "Ram Mohan R (rmohanr)" wro= te: > Hi Charles, >=20 > Please see inline >=20 >> -----Original Message----- >> From: Charles Eckel (eckelcu) >> Sent: Sunday, April 03, 2011 11:52 PM >> To: Ram Mohan R (rmohanr); 'Elwell, John'; Parthasarathi R (partr);=20 >> 'siprec@ietf.org' >> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 >>=20 >> Hi Ram, >>=20 >> I agree that main point focus of the metadata is the description of > the >> communication sessions(s); however, the metadata model contains a=20 >> recording session element, and the recording element contains=20 >> attributes specific to the recording session. For that reason, I=20 >> think it is misleading to say the metadata describes the=20 >> communication session. >> Perhaps you are suggesting the recording session element should be=20 >> removed from the model, and it may be maintained in an unspecified=20 >> manner within the SRS? >=20 > No I am not suggesting that. I think we need slightly better wording=20 > than that. > Metadata describes the CS but is carried in RS. Metadata has=20 > information about CS participants, different transactions of CS(which=20 > are carried in RS). Metadata maps CS participants to the recorded media = sent in RS. > So to summarize Metadata describes the recorded media sent in RS and=20 > its relation to CS. >=20 > Perhaps we could retain the wordings of the Req draft ? > The requirement draft has > Metadata: Information that describes recorded media and the CS to=20 > which they relate. >=20 > Thoughts ? >=20 > Ram >=20 >>=20 >> Cheers, >> Charles >>=20 >>> -----Original Message----- >>> From: Ram Mohan R (rmohanr) >>> Sent: Saturday, April 02, 2011 11:41 AM >>> To: Charles Eckel (eckelcu); Elwell, John; Parthasarathi R (partr); >> siprec@ietf.org >>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 >>>=20 >>> Hi Charles, >>>=20 >>> Inline >>>=20 >>>> -----Original Message----- >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 >>>> Behalf Of Charles Eckel (eckelcu) >>>> Sent: Friday, April 01, 2011 6:39 PM >>>> To: Elwell, John; Parthasarathi R (partr); siprec@ietf.org >>>> Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 >>>>=20 >>>> How about: >>>>=20 >>>> OLD: >>>> Metadata is the data that describes the communication session. >>>>=20 >>>> NEW: >>>> Metadata is the data that describes the recording session, >> including >>>> the >>>> communication sessions it is recording. >>>=20 >>> This text seems to create more confusion. Please note Metadata does >> not describe anything about RS. >>> It describes only about CS. >>>=20 >>> Ram >>>=20 >>>>=20 >>>> Cheers, >>>> Charles >>>>=20 >>>>> -----Original Message----- >>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>>>> Sent: Thursday, March 31, 2011 6:30 PM >>>>> To: Charles Eckel (eckelcu); Parthasarathi R (partr); >> siprec@ietf.org >>>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 >>>>>=20 >>>>> Charles, >>>>>=20 >>>>> OK, I see how you got there, but really it describes the CSs > (and >> CS >>>> groups) that are being carried in >>>>> the RS. Any ideas how better to word it? >>>>>=20 >>>>> John >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] >>>>>> Sent: 31 March 2011 17:11 >>>>>> To: Elwell, John; Parthasarathi R (partr); siprec@ietf.org >>>>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 >>>>>>=20 >>>>>> Hi John, >>>>>>=20 >>>>>> Please see inline. >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Elwell, John [mailto:john.elwell@siemens- >> enterprise.com] >>>>>>> Sent: Wednesday, March 30, 2011 11:01 AM >>>>>>> To: Charles Eckel (eckelcu); Parthasarathi R (partr); >>>>>> siprec@ietf.org >>>>>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata- >> 04 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: siprec-bounces@ietf.org >>>>>>>> [mailto:siprec-bounces@ietf.org] On Behalf Of Charles > Eckel >>>>>> (eckelcu) >>>>>>>> Sent: 29 March 2011 15:38 >>>>>>>> To: Parthasarathi R (partr); siprec@ietf.org >>>>>>>> Subject: Re: [siprec] comments on draft-ram-siprec- >> metadata-04 >>>>>>>>=20 >>>>>>>> Hi Partha, >>>>>>>>=20 >>>>>>>> Thanks for your response. This addresses all of my >> concerns. >>>>>>>> Please see >>>>>>>> one additional clarification inline. >>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: Parthasarathi R (partr) >>>>>>>>> Sent: Tuesday, March 29, 2011 10:31 AM >>>>>>>>> To: Charles Eckel (eckelcu); siprec@ietf.org >>>>>>>>> Subject: RE: [siprec] comments on draft-ram-siprec- >> metadata- >>>> 04 >>>>>>>>>=20 >>>>>>>>> Charles, >>>>>>>>>=20 >>>>>>>>> Thanks for review the document. Please read inline. >>>>>>>>>=20 >>>>>>>>> Thanks >>>>>>>>> Partha >>>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: siprec-bounces@ietf.org >>>>>> [mailto:siprec-bounces@ietf.org] On >>>>>>>> Behalf Of Charles Eckel (eckelcu) >>>>>>>>> Sent: Sunday, March 27, 2011 12:35 AM >>>>>>>>> To: siprec@ietf.org >>>>>>>>> Subject: [siprec] comments on draft-ram-siprec-metadata- >> 04 >>>>>>>>>=20 >>>>>>>>> I gave the draft and read and have the following >> comments. >>>>>>>>>=20 >>>>>>>>> Section 3. Think the metadata describes the recording >>>>>>>> session, not the >>>>>>>> communication session. Replace >>>>>>>>> "metamodel" with "metadata model", and "MAY be conveyed >> in >>>>>> Recording >>>>>>>> Session" with "MAY be conveyed >>>>>>>>> within the Recording Session", and "time a change >> occurred by >>>> be >>>>>>>> assumed" with "time a change occurred >>>>>>>>> may be assumed". >>>>>>> [JRE] I am not sure exactly what text Charles was commenting >> on, >>>> but >>>>>> in my opinion metadata describes >>>>>>> a CS (and how media streams in the RS relate to that CS), >>>>>> rather than >>>>>> describing the RS. >>>>>>>=20 >>>>>>> John (as individual) >>>>>>=20 >>>>>> The metadata model is anchored by an element for the RS. This=20 >>>>>> recording session contains 0 or more CS group each with 1 or more=20 >>>>>> CS. >>>>>> This is what >>>>>> led to my comment that the metadata model describes an RS rather=20 >>>>>> than a CS. >>>>>>=20 >>>>>> Cheers, >>>>>> Charles >>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Section 4, suggest rewording as, "The section describes >> each >>>>>> element >>>>>>>> of the metadata model, and the >>>>>>>>> attributes of each element. This section also describes >> how >>>> the >>>>>>>> different elements are associated." >>>>>>>>>=20 >>>>>>>>> Section 4.1, RecordingRequestorID is not really an ID, > it >>>>>>>> is more of a >>>>>>>> type. I think >>>>>>>>> RecordingRequestor is more appropriate. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Agreed. We will update in the next revision >> >>>>>>>>>=20 >>>>>>>>> That said, I think you also need a unique ID for the >>>> Recording >>>>>>>> Session, right? >>>>>>>>> Please clarify whether you are interested in >> AOR of >>>> RS >>>>>> or >>>>>>>> just ID. In the model, Recording >>>>>>>>> (1..*) is related to CSG (0..*) and there is no need of >>>> separate >>>>>>>> attribute for unique id. In the >>>>>>>>> metadata format, URN UUID in CSG (group) & recording >> exist >>>>>>>> which helps >>>>>>>> to visualize the association >>>>>>>>> >>>>>>>>=20 >>>>>>>> I am assuming there is a need to distinguish one RS from=20 >>>>>>>> another RS, and that is the reason I was recommending adding a=20 >>>>>>>> unique ID. >>>>>>>> This ID would >>>>>>>> not be the RS AOR as that may not be unique. >>>>>>>>=20 >>>>>>>> Cheers, >>>>>>>> Charles >>>>>>>>=20 >>>>>>>>> Section 4.2.1, replace "SRC (or MAY be SRS)" with "SRC > or >>>> SRS". >>>>>>>>> Agreed. We will update in the next revision >> >>>>>>>>>=20 >>>>>>>>> Section 4.3.2, why does a CS need two participants or >> more? >>>>>>>> What about >>>>>>>> studio mode recording? >>>>>>>>>=20 >>>>>>>>> Section 4.4.1, what is participant type and what is its >> use, >>>> or >>>>>> why >>>>>>>> needed? >>>>>>>>> This attribute has to be removed as per the >>>>>> last interim >>>>>>>> meeting. We will update in the next >>>>>>>>> revision. >>>>>>>>>=20 >>>>>>>>> Section 4.5, I think Media Stream requires a unique ID >>>> attribute >>>>>> as >>>>>>>> well. >>>>>>>>> As mentioned above in the model draft, the >>>> association >>>>>>>> between CS and participant is shown. >>>>>>>>> In terms of format draft, it is represented by URN UUID >>>>>> >>>>>>>>> Is the "Media Stream Reference" the SDP label attribute? >>>>>>>>> Your understanding is correct >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Thanks, >>>>>>>>> Charles >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> siprec mailing list >>>>>>>>> siprec@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>>> _______________________________________________ >>>>>>>> siprec mailing list >>>>>>>> siprec@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>>>=20 >>>>>>=20 >>>> _______________________________________________ >>>> siprec mailing list >>>> siprec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/siprec _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From Leon.Portman@nice.com Tue Apr 5 06:59:46 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D668928C11D for ; Tue, 5 Apr 2011 06:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wxbt65tFZQFR for ; Tue, 5 Apr 2011 06:59:39 -0700 (PDT) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by core3.amsl.com (Postfix) with ESMTP id E014B28C121 for ; Tue, 5 Apr 2011 06:59:38 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Tue, 5 Apr 2011 17:01:21 +0300 From: Leon Portman To: "Ram Mohan R (rmohanr)" , Scott Orton , "Elwell, John" , "Charles Eckel (eckelcu)" , "Parthasarathi R (partr)" , "siprec@ietf.org" Date: Tue, 5 Apr 2011 17:01:20 +0300 Thread-Topic: [siprec] comments on draft-ram-siprec-metadata-04 Thread-Index: Acvr6KoPYFMcjPlASk+pOtN532GUhgBO/qTgAD5pH0AAJpm4YABBRncAAAC5KqAAABl2UAAAlZ6wAAOH8AAAVJiJUACdgDNw Message-ID: <07465C1D981ABC41A344374066AE1A2C38AB633696@TLVMBX01.nice.com> References: <21866C7FE177A4449B9136B5B24B1B130BC011290A@EXMBXCLUS01.citservers.local> <21866C7FE177A4449B9136B5B24B1B130BC011294A@EXMBXCLUS01.citservers.local> <35BCE99A477D6A4986FB2216D8CF2CFD05DD8C0C@XMB-BGL-417.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD05DD8C0C@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] comments on draft-ram-siprec-metadata-04 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 05 Apr 2011 13:59:46 -0000 I am ok Leon -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Ram Mohan R (rmohanr) Sent: Sunday, April 03, 2011 8:13 PM To: Scott Orton; Elwell, John; Charles Eckel (eckelcu); Parthasarathi R (pa= rtr); siprec@ietf.org Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 Scott, I am ok to make this change to the model. I would like to hear from others = if they have any issues in incorporating this change in the model.=20 The updated portion of the model will look like +-------------------------------+ 1 | Recording Session (RS) |---------------+ +-------------------------------+ | | 1..* |1..* | | | | | 0..* |0..* | +--------------+ +-----------------+ | |Communication | | Communication | 1 |=20 | Session (CS) |----------| Session (CS) |---| | Group |0..1 1..*| | | 0..* +----------+ +--------------+ +-----------------+ |------|Extension | 1| | 0..* |1..* | | Data | | | 2..* |0..* | +----------+ 0..*| +---------+ |Extension| =20 | Data | +---------+ The only change in the association is : A CS MUST be associated with zero or one CS-Group Rest of the associations remain same. Further the association between CS an= d RS remains same as what is between CS-Group and RS. Comments ? Regards, Ram > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > Behalf Of Scott Orton > Sent: Friday, April 01, 2011 12:18 AM > To: Elwell, John; Charles Eckel (eckelcu); Parthasarathi R (partr);=20 > siprec@ietf.org > Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 >=20 > John, > Thanks for the information. >=20 > In that case I would like to see the CS group be made optional. > Rather than the CS pointing to the CS Group, I would like to suggest=20 > that the CS point to the RS and have the CS group stand alone where it=20 > would just have its own ID and then a list of CS ids that belong to the > group. >=20 > Scott >=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Thursday, March 31, 2011 11:50 AM > To: Scott Orton; Charles Eckel (eckelcu); Parthasarathi R (partr);=20 > siprec@ietf.org > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 >=20 > Scott, >=20 > Some folks wanted to be able to group related CSs together (e.g., a CS=20 > between a customer and an agent and a second CS resulting from the=20 > customer being transferred to a second agent). I will leave it to those > folks to add to this. >=20 > John (chair hat on) >=20 >=20 > > -----Original Message----- > > From: Scott Orton [mailto:sorton@broadsoft.com] > > Sent: 31 March 2011 17:43 > > To: Elwell, John; Charles Eckel (eckelcu); Parthasarathi R (partr);=20 > > siprec@ietf.org > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > > > John, Charles, Partha, > > I have a question. What is the purpose of the CS Group? I do not=20 > > see it adding anything to the metadata. To me it seems that the=20 > > whole purpose of the metadata is to describe the recording session=20 > > to the SRS. Looking at the requirements I see 3 relationships that=20 > > the spec is attempting to describe: > > > > A one to one relationship - one communication session to one=20 > > recording session A one to many relationship - one communication=20 > > session with multiple Recording sessions > > - one Recording session made up of=20 > > multiple communications sessions > > > > The current metadata format allows all of these and I do not see=20 > > what the group is adding. > > > > Regards, > > Scott > > > > -----Original Message----- > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > > Sent: Thursday, March 31, 2011 11:30 AM > > To: Charles Eckel (eckelcu); Parthasarathi R (partr); siprec@ietf.org > > Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 > > > > Charles, > > > > OK, I see how you got there, but really it describes the CSs (and CS=20 > > groups) that are being carried in the RS. Any ideas how better to=20 > > word it? > > > > John > > > > > -----Original Message----- > > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > Sent: 31 March 2011 17:11 > > > To: Elwell, John; Parthasarathi R (partr); siprec@ietf.org > > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > > > > > Hi John, > > > > > > Please see inline. > > > > > > > -----Original Message----- > > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > Sent: Wednesday, March 30, 2011 11:01 AM > > > > To: Charles Eckel (eckelcu); Parthasarathi R (partr); > > > siprec@ietf.org > > > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: siprec-bounces@ietf.org > > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Charles Eckel > > > (eckelcu) > > > > > Sent: 29 March 2011 15:38 > > > > > To: Parthasarathi R (partr); siprec@ietf.org > > > > > Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 > > > > > > > > > > Hi Partha, > > > > > > > > > > Thanks for your response. This addresses all of my concerns. > > > > > Please see > > > > > one additional clarification inline. > > > > > > > > > > > -----Original Message----- > > > > > > From: Parthasarathi R (partr) > > > > > > Sent: Tuesday, March 29, 2011 10:31 AM > > > > > > To: Charles Eckel (eckelcu); siprec@ietf.org > > > > > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata- > 04 > > > > > > > > > > > > Charles, > > > > > > > > > > > > Thanks for review the document. Please read inline. > > > > > > > > > > > > Thanks > > > > > > Partha > > > > > > > > > > > > -----Original Message----- > > > > > > From: siprec-bounces@ietf.org > > > [mailto:siprec-bounces@ietf.org] On > > > > > Behalf Of Charles Eckel (eckelcu) > > > > > > Sent: Sunday, March 27, 2011 12:35 AM > > > > > > To: siprec@ietf.org > > > > > > Subject: [siprec] comments on draft-ram-siprec-metadata-04 > > > > > > > > > > > > I gave the draft and read and have the following comments. > > > > > > > > > > > > Section 3. Think the metadata describes the recording > > > > > session, not the > > > > > communication session. Replace > > > > > > "metamodel" with "metadata model", and "MAY be conveyed in > > > Recording > > > > > Session" with "MAY be conveyed > > > > > > within the Recording Session", and "time a change > > occurred by be > > > > > assumed" with "time a change occurred > > > > > > may be assumed". > > > > [JRE] I am not sure exactly what text Charles was > > commenting on, but > > > in my opinion metadata describes > > > > a CS (and how media streams in the RS relate to that CS), > > > rather than > > > describing the RS. > > > > > > > > John (as individual) > > > > > > The metadata model is anchored by an element for the RS. This=20 > > > recording session contains 0 or more CS group each with 1 or more=20 > > > CS. > > > This is what > > > led to my comment that the metadata model describes an RS rather=20 > > > than a CS. > > > > > > Cheers, > > > Charles > > > > > > > > > > > > > > > > > > > > > > > Section 4, suggest rewording as, "The section describes each > > > element > > > > > of the metadata model, and the > > > > > > attributes of each element. This section also > > describes how the > > > > > different elements are associated." > > > > > > > > > > > > Section 4.1, RecordingRequestorID is not really an ID, it > > > > > is more of a > > > > > type. I think > > > > > > RecordingRequestor is more appropriate. > > > > > > > > > > > > > > > > > > Agreed. We will update in the next revision > > > > > > > > > > > > That said, I think you also need a unique ID for the > > Recording > > > > > Session, right? > > > > > > Please clarify whether you are interested > > in AOR of RS > > > or > > > > > just ID. In the model, Recording > > > > > > (1..*) is related to CSG (0..*) and there is no need > > of separate > > > > > attribute for unique id. In the > > > > > > metadata format, URN UUID in CSG (group) & recording exist > > > > > which helps > > > > > to visualize the association > > > > > > > > > > > > > > > > I am assuming there is a need to distinguish one RS from=20 > > > > > another RS, and that is the reason I was recommending adding a=20 > > > > > unique ID. > > > > > This ID would > > > > > not be the RS AOR as that may not be unique. > > > > > > > > > > Cheers, > > > > > Charles > > > > > > > > > > > Section 4.2.1, replace "SRC (or MAY be SRS)" with > > "SRC or SRS". > > > > > > Agreed. We will update in the next revision > > > > > > > > > > > > Section 4.3.2, why does a CS need two participants or more? > > > > > What about > > > > > studio mode recording? > > > > > > > > > > > > Section 4.4.1, what is participant type and what is > > its use, or > > > why > > > > > needed? > > > > > > This attribute has to be removed as per the > > > last interim > > > > > meeting. We will update in the next > > > > > > revision. > > > > > > > > > > > > Section 4.5, I think Media Stream requires a unique > > ID attribute > > > as > > > > > well. > > > > > > As mentioned above in the model draft, the > > association > > > > > between CS and participant is shown. > > > > > > In terms of format draft, it is represented by URN UUID > > > > > > > > > Is the "Media Stream Reference" the SDP label attribute? > > > > > > Your understanding is correct > > > > > > > > > > > > > > > > > > Thanks, > > > > > > Charles > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > siprec mailing list > > > > > > siprec@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > _______________________________________________ > > > > > siprec mailing list > > > > > siprec@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > > > _______________________________________________ > > siprec mailing 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 ietf@meetecho.com Tue Apr 5 09:39:35 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 954323A6960 for ; Tue, 5 Apr 2011 09:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.027 X-Spam-Level: X-Spam-Status: No, score=-0.027 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j3W9jM+uttH9 for ; Tue, 5 Apr 2011 09:39:35 -0700 (PDT) Received: from smtpw2.aruba.it (smtpa1.aruba.it [62.149.128.210]) by core3.amsl.com (Postfix) with SMTP id 4B4C33A695F for ; Tue, 5 Apr 2011 09:39:34 -0700 (PDT) Received: (qmail 22124 invoked by uid 89); 5 Apr 2011 16:41:16 -0000 Received: from unknown (HELO aruba.it) (62.149.158.91) by smtpw2.ad.aruba.it with SMTP; 5 Apr 2011 16:41:16 -0000 Date: Tue, 5 Apr 2011 18:41:16 +0200 Message-Id: MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: multipart/alternative; boundary="_=__=_XaM3_.1302021676.2A.833138.42.9111.52.42.007.436863217" From: "ietf@meetecho.com" To: siprec@ietf.org X-XaM3-API-Version: V3(R2) X-SenderIP: 143.225.229.199 X-Spam-Rating: smtpw2.ad.aruba.it 1.6.2 0/1000/N Subject: [siprec] SIPREC recording available -- update X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 05 Apr 2011 16:39:35 -0000 --_=__=_XaM3_.1302021676.2A.833138.42.9111.52.42.007.436863217 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dear all,the full recording (synchronized video, audio, slides and jabber= room) of the SIPREC session at IETF80 is available at the following URL:= http://ietf.conf.meetecho.comYou can either choose to watch it online (tw= o different approaches are available) or download and replay it whenever = you want.In case of problems with the playout, just drop an e-mail to iet= f-support@meetecho.com.For the chair(s): please feel free to put the link= to the recording in the minutes, if you think this might be useful.Cheer= s,the Meetecho Team --_=__=_XaM3_.1302021676.2A.833138.42.9111.52.42.007.436863217 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable =0A
=0A
Dear all,

the full recording (synchronized v= ideo, audio, slides and jabber room) of the SIPREC session at IETF80 is a= vailable at the following URL:
http://ietf.conf.meetecho.com

Yo= u can either choose to watch it online (two different approaches are avai= lable) or download and replay it whenever you want.

In case of pro= blems with the playout, just drop an e-mail to ietf-support@meetecho.com.=

For the chair(s): please feel free to put the link to the recordi= ng in the minutes, if you think this might be useful.

Cheers,
t= he Meetecho Team
=0A
=0A --_=__=_XaM3_.1302021676.2A.833138.42.9111.52.42.007.436863217-- From john.elwell@siemens-enterprise.com Wed Apr 6 00:17:16 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D96423A68CE for ; Wed, 6 Apr 2011 00:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXdZ65LY4c0l for ; Wed, 6 Apr 2011 00:17:16 -0700 (PDT) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 00A3A3A68BF for ; Wed, 6 Apr 2011 00:17:15 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-4030097 for siprec@ietf.org; Wed, 6 Apr 2011 09:18:58 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 8883E23F028E for ; Wed, 6 Apr 2011 09:18:58 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 6 Apr 2011 09:18:58 +0200 From: "Elwell, John" To: "siprec@ietf.org" Date: Wed, 6 Apr 2011 09:18:56 +0200 Thread-Topic: Draft minutes Thread-Index: Acv0KuRtWxJtgqTqTaGi2ivs8BUIyQ== 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 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2011 07:17:16 -0000 Draft minutes from Prague are available at: http://www.ietf.org/proceedings/80/minutes/siprec.txt Please let me have any corrections by 2011-04-17. John= From john.elwell@siemens-enterprise.com Wed Apr 6 00:19:12 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6A863A68CD for ; Wed, 6 Apr 2011 00:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RR7qvbD9lFZT for ; Wed, 6 Apr 2011 00:19:11 -0700 (PDT) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 5929B3A68CC for ; Wed, 6 Apr 2011 00:19:08 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-4021794 for siprec@ietf.org; Wed, 6 Apr 2011 09:20:51 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 86F4823F0290 for ; Wed, 6 Apr 2011 09:20:51 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 6 Apr 2011 09:20:51 +0200 From: "Elwell, John" To: "siprec@ietf.org" Date: Wed, 6 Apr 2011 09:20:49 +0200 Thread-Topic: Changes to draft-ietf-siprec-architecture Thread-Index: Acv0KyfY0X23joTET5mkU+vXGvFSEg== 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] Changes to draft-ietf-siprec-architecture X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2011 07:19:12 -0000 >From the Prague minutes: "Slides: http://www.ietf.org/proceedings/80/slides/siprec-2.ppt Slide 3: Open issue: Figure to show how to decompose SRC? Partha would like= an additional figure and will provide ASCII art for review on the list. Slide 4: Addition of Conference Focus Interaction diagram. No objection. Slide 5: Removal of Metadata Supported indication. No objection. Slide 6: Removal of Metadata Content and reference the Metadata Model draft= instead. No objections. Slide 7: Metadata delivery. The sense of the room was to mention delivery b= y SIP, but leave the particular methods to the protocol draft, and to state= that non-SIP methods are out of scope. Slide 8: Security Considerations, removal of statement on decryption / re-e= ncryption. No objection. Slide 9: Security Considerations, removal of statement on SRTP. No objectio= n." I doubt there is anything controversial here, but if there is any counter o= pinion, please raise it on the list by the end of this week (2011-04-10). I= would like the editors to produce -02 with these changes early next week. John= From john.elwell@siemens-enterprise.com Wed Apr 6 00:19:42 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0958B3A68CD for ; Wed, 6 Apr 2011 00:19:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h42LDrhSJWeI for ; Wed, 6 Apr 2011 00:19:41 -0700 (PDT) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 380B93A68C7 for ; Wed, 6 Apr 2011 00:19:41 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-4030124 for siprec@ietf.org; Wed, 6 Apr 2011 09:21:24 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 9192E23F0290 for ; Wed, 6 Apr 2011 09:21:24 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 6 Apr 2011 09:21:24 +0200 From: "Elwell, John" To: "siprec@ietf.org" Date: Wed, 6 Apr 2011 09:21:22 +0200 Thread-Topic: Changes to metadata model Thread-Index: Acv0Kztn1HsWWdpDSIaKHoqN2B1Zpg== 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] Changes to metadata model X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2011 07:19:42 -0000 During the discussions in Prague on draft-ram-siprec-metadata-04 (already a= greed for adoption by WG) the following agreements were reached: - add start/stop time attributes for Communication Session; - do not include session state attribute for Communication Session; - the metadata model should include media streams that are not being delive= red to the SRS (e.g., those offered by the SRC but not accepted by the SRS)= . If there is any counter opinion, please raise it on the list by the end of = this week (2011-04-10). I would like the editors to produce draft-ietf-sipr= ec-metadata-00 with these changes early next week. John From john.elwell@siemens-enterprise.com Wed Apr 6 00:22:09 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3062B3A68C7 for ; Wed, 6 Apr 2011 00:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9qQ3-wjiw80 for ; Wed, 6 Apr 2011 00:22:08 -0700 (PDT) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 797AE3A68BF for ; Wed, 6 Apr 2011 00:22:07 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-4031021 for siprec@ietf.org; Wed, 6 Apr 2011 09:23:50 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id AD32B1EB82B0 for ; Wed, 6 Apr 2011 09:23:50 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 6 Apr 2011 09:23:50 +0200 From: "Elwell, John" To: "siprec@ietf.org" Date: Wed, 6 Apr 2011 09:23:49 +0200 Thread-Topic: How many deliverables? Thread-Index: Acv0K5KknwluuJp1Sd2DqCWhHDXRYg== 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] How many deliverables? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2011 07:22:09 -0000 At present we have milestones for the following: - Requirements (draft-ietf-siprec-req, already submitted to IESG) - Architecture (draft-ietf-siprec-architecture) - Metadata model (draft-ietf-siprec-metadata, to be posted shortly) - Protocol (draft-portman-siprec-protocol is the sole candidate at present) We also have draft-ram-siprec-metadata-format, which we anticipate adopting= in some form in the fairly near future. The question was asked in Prague w= hether to create another milestone for metadata-format. Other possibilities= are to do some mergers. In considering what documents to deliver, one cons= ideration is a newcomer trying to make sense of what has to be implemented,= which may lean us towards fewer documents and fewer cross references. Some of the possible options: A) Add metadata format as a 5th milestone and create a 5th deliverable. B) Add metadata format to the metadata model deliverable. This would reduce= cross-referencing between the two documents. C) Add metadata format to the protocol deliverable. This would keep the stu= ff that needs to be implemented in one place. Opinions? John From john.elwell@siemens-enterprise.com Wed Apr 6 00:33:55 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEAC23A68BF for ; Wed, 6 Apr 2011 00:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Fx68ELlACP7 for ; Wed, 6 Apr 2011 00:33:52 -0700 (PDT) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 2725A3A68B5 for ; Wed, 6 Apr 2011 00:33:51 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-4037626; Wed, 6 Apr 2011 09:35:34 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id C644B1EB82B0; Wed, 6 Apr 2011 09:35:34 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 6 Apr 2011 09:35:34 +0200 From: "Elwell, John" To: "Parthasarathi R (partr)" , Leon Portman , "Charles Eckel (eckelcu)" , "Hutton, Andrew" , "Ram Mohan R (rmohanr)" Date: Wed, 6 Apr 2011 09:35:33 +0200 Thread-Topic: [siprec] Dialog state in the CS block of metadatamodel[wasRE:Progressing the architecture document] Thread-Index: AcvY+qyFanmfNOL5Qlq3osURZ2w4qAJbzb1IACUhGWAAGstGAwFGdfdAAAXbWKAAA+XmQAAAGhNQABG/CmwAHSHXEAAZDuOFABzjR+AAVixTcAAUeoQQAAAj4EAAHgihsAAClqhQAAXOdEAADtUDkAAjidVAAABgrFAAAo/hIAAdpARgAAc8P9ABkDDsUA== Message-ID: References: <101C6067BEC68246B0C3F6843BCCC1E30B61DB3370@MCHP058A.global-ad.net><07465C1D981ABC41A344374066AE1A2C38A960C8F0@TLVMBX01.nice.com><101C6067BEC68246B0C3F6843BCCC1E30B61E96D11@MCHP058A.global-ad.net><07465C1D981ABC41A344374066AE1A2C38A960C9CA@TLVMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD05CC9E38@XMB-BGL-417.cisco.com> <07465C1D981ABC41A344374066AE1A2C38AB466335@TLVMBX01.nice.com> <07465C1D981ABC41A344374066AE1A2C38AB46639F@TLVMBX01.nice.com> <07465C1D981ABC41A344374066AE1A2C38AB466603@TLVMBX01.nice.com> <101C6067BEC68246B0C3F6843BCCC1E30B6D1ED8E0@MCHP058A.global-ad.net> <07465C1D981ABC41A344374066AE1A2C38AB466C1B@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] Dialog state in the CS block of metadatamodel[wasRE:Progressing the architecture document] X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2011 07:33:56 -0000 So you are saying we might want to distinguish between media generated auto= matically and media generated by a human? I guess the only SIP mechanism fo= r determining this is that "Automata" media feature tag in RFC 3840, but I = don't know how widely implemented it is. John > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > Sent: 29 March 2011 09:50 > To: Elwell, John; Leon Portman; Charles Eckel (eckelcu); > Hutton, Andrew; Ram Mohan R (rmohanr) > Cc: siprec@ietf.org > Subject: RE: [siprec] Dialog state in the CS block of > metadatamodel[wasRE:Progressing the architecture document] > > John, > > I agree with you in case of media server participant sends "ringback" > media stream during the early dialog and later stage, the callee > participant sends actual stream of the session using another > offer/answer exchange. It is also possible that callee sends > "ringback" > media stream wherein there is no difference between early or regular > media in terms of metadata information. > > Having said that, it "may" or "may not" be matter whether the > devices of > the participant automatically creates the media stream or participant > actually creates media stream. > > Thanks > Partha > > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Tuesday, March 29, 2011 10:39 AM > To: Parthasarathi R (partr); Leon Portman; Charles Eckel (eckelcu); > Hutton, Andrew; Ram Mohan R (rmohanr) > Cc: siprec@ietf.org > Subject: RE: [siprec] Dialog state in the CS block of > metadatamodel[wasRE:Progressing the architecture document] > > Partha, > > I think the real distinction you wish to make is between media coming > from a particular participant (associated with the UAS) and > media coming > from some other entity (e.g., media server). In my view the > latter case, > if we choose to record it, comes from a different > "participant". It has > nothing to do with whether it is deemed early or regular from a SIP > dialog perspective. > > John (as individual) > > > > -----Original Message----- > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > Sent: 28 March 2011 17:53 > > To: Leon Portman; Charles Eckel (eckelcu); Hutton, Andrew; Elwell, > > John; Ram Mohan R (rmohanr) > > Cc: siprec@ietf.org > > Subject: RE: [siprec] Dialog state in the CS block of > > metadatamodel[wasRE:Progressing the architecture document] > > > > > > The question of "session" state is raised in my mind mainly to > > distinguish between early media (Media before session > establishment) > > from normal media. Without the information in SIPREC metadata, the > > early media will be associated with UAS participant's media stream. > > I'm interested in knowing whether SIPREC solution has to > differentiate > > > between early media from normal media. > > > > As per John below mail, there is no need to differentiate > as per the > > current requirement. If most of the folks feel so, I'm fine > with not > > including "session state" in metadata. > > > > Thanks > > Partha > > > > -----Original Message----- > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > Sent: Monday, March 28, 2011 7:16 PM > > To: Charles Eckel (eckelcu); Hutton, Andrew; Elwell, John; > > Parthasarathi R (partr); Ram Mohan R (rmohanr) > > Cc: siprec@ietf.org > > Subject: RE: [siprec] Dialog state in the CS block of > > metadatamodel[wasRE:Progressing the architecture document] > > > > Charles Hi > > > > Just to make clear, I don't think SRS should receive dialog level > > state events about all CS dialogs. I think that we should > to support > > reporting high level session events. > > I understand the complexity of that and Ok to keep it open or next > > phase extensions > > > > Leon > > > > -----Original Message----- > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > Sent: Monday, March 28, 2011 3:35 PM > > To: Hutton, Andrew; Elwell, John; Leon Portman; Parthasarathi R > > (partr); Ram Mohan R (rmohanr) > > Cc: siprec@ietf.org > > Subject: RE: [siprec] Dialog state in the CS block of > > metadatamodel[wasRE:Progressing the architecture document] > > > > I agree with this approach. Hopefully Leon and others that saw the > > need for this state information can confirm if it works for them. > > > > Cheers, > > Charles > > > > > -----Original Message----- > > > From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com] > > > Sent: Monday, March 28, 2011 9:13 AM > > > To: Elwell, John; Leon Portman; Charles Eckel (eckelcu); > > Parthasarathi > > R (partr); Ram Mohan R > > > (rmohanr) > > > Cc: siprec@ietf.org > > > Subject: RE: [siprec] Dialog state in the CS block of > > metadatamodel[wasRE:Progressing the architecture > > > document] > > > > > > Hi, > > > > > > The draft-ietf-siprec-architecture has from the very > > beginning listed > > dialog state as an example of > > > what would be included in metadata which is why I raised > > the question. > > > > > > However it is true to say this was put in the > architecture document > > before we had firmed up the > > > requirements or starting any indepth work on metadata so I could > > accept that the architecture draft > > > simply got this wrong from the start and it maybe should > be removed. > > We could of course take the view > > > that if dialog events are important then the SRS could > subscribe to > > the dialog event package at the > > > SRC and SIPREC does not need to touch this. > > > > > > I don't think we can allow SIPREC metadata to extend as far as > > reporting everything that happens to > > > the CS including how it is linked to other CS's and what > > services are > > used on the CS (E.g. types of > > > transfer etc.). This would quickly get very difficult to > > define and we > > would probably fail. > > > > > > I would prefer to not report this state information in > metadata than > > open up the possibility of adding > > > lots of complexity. > > > > > > Regards > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Elwell, John > > > > Sent: 27 March 2011 14:50 > > > > To: Leon Portman; Charles Eckel (eckelcu); Parthasarathi > > R (partr); > > > > Ram Mohan R (rmohanr); Hutton, Andrew > > > > Cc: siprec@ietf.org > > > > Subject: RE: [siprec] Dialog state in the CS block of > > > > metadatamodel[wasRE:Progressing the architecture document] > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > > > > Sent: 27 March 2011 11:48 > > > > > To: Charles Eckel (eckelcu); Elwell, John; Parthasarathi R > > > > > (partr); Ram Mohan R (rmohanr); Hutton, Andrew > > > > > Cc: siprec@ietf.org > > > > > Subject: RE: [siprec] Dialog state in the CS block of > > > > > metadatamodel[wasRE:Progressing the architecture document] > > > > > > > > > > Charles Hi > > > > > > > > > > Yes, it will be good to discuss it face to face. > > > > > > > > > > Just little background for such requirements. Today, > especially > > > > > for contact centers, it is important for SRS to capture the > > > > > information how long customer was waiting for agent to > > answer the > > > > > call, which party hang up, how long was the hold time, > > if it was > > > > > blind transfer or consultation transfer. This information > > > > > important both from quality management point of view > > and customer > > > > > experience point of view. > > > > [JRE] (as chair) I think the group needs to consider > > whether this is > > > > > > within scope. Looking at the requirements, we have: > > > > "REQ-012 The mechanism MUST provide the SRS with metadata > > describing > > > > CSs that are being recorded, including the media > being used and > > the > > > > identities of parties involved." > > > > If we are not recording the session while the caller is > > waiting to > > > > be answered, it seems we perhaps don't have a requirement for > > > > metadata about that. This seems to be more about call detail > > > > recording (CDR) rather than session recording. We can by > > all means > > > > have this discussion, but I am concerned about scope creep. > > > > > > > > > It is important also from compliance point of view to > detect if > > > > > somebody actually received the media stream or still was in > > > > > pending state or media stream was disconnected. > > > > [JRE] (as individual) I agree we should show a participant as > > > > receiving media only if the SRC believes media is > actually being > > > > sent to that participant (even then, there can be no > > guarantee it is > > > > > > received, e.g., because NAT or firewall traversal isn't > > functioning > > > > properly, severe packet loss, speaker volume is muted, > > etc..). But I > > > > > > have doubts whether it is necessarily to try to account > > for periods > > > > when the SRC knows a participant is not receiving media > > by saying it > > > > > > is because of alerting, hold or whatever. > > > > > > > > John > > > > > > > > > > > > > > > > > > Leon > > > > > > > > > > -----Original Message----- > > > > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > > > Sent: Sunday, March 27, 2011 11:35 AM > > > > > To: Leon Portman; Elwell, John; Parthasarathi R > > (partr); Ram Mohan > > > > > > > R (rmohanr); Hutton, Andrew > > > > > Cc: siprec@ietf.org > > > > > Subject: RE: [siprec] Dialog state in the CS block of > > > > > metadatamodel[wasRE:Progressing the architecture document] > > > > > > > > > > Hi Leon, > > > > > > > > > > Thank you for your patience in trying to explain this to me; > > > > > however, I still am not able to understand why the SRS > > might need > > > > > to know this information, or what it would do with it. > > > > > Is it that you need to know when a given participant > > was receiving > > > > > > > the recorded media and when it was not? If so, I do not think > > > > > dialog state is sufficient. Is there some other > requirement or > > > > > functionality addressed by the SRS having such information? > > > > > Perhaps it is easier to discuss in person at the > > breakfast meeting > > > > > > > Wednesday or during the working group session. > > > > > > > > > > Cheers, > > > > > Charles > > > > > > > > > > > -----Original Message----- > > > > > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > > > > > Sent: Saturday, March 26, 2011 8:15 PM > > > > > > To: Charles Eckel (eckelcu); Elwell, John; Parthasarathi > > > > R (partr); > > > > > Ram Mohan R (rmohanr); Hutton, > > > > > > Andrew > > > > > > Cc: siprec@ietf.org > > > > > > Subject: RE: [siprec] Dialog state in the CS block of > > > > > metadatamodel[wasRE:Progressing the architecture > > > > > > document] > > > > > > > > > > > > Charles Hi > > > > > > > > > > > > Without participant session state, SRS will know only when > > > > > participant > > > > > is part of the session and will > > > > > > not know about intermediate states like ringing, > retrying etc. > > > > > > I know that we have media stream information per > > > > participant but not > > > > > sure that it is enough. > > > > > > > > > > > > Leon > > > > > > -----Original Message----- > > > > > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > > > > Sent: Saturday, March 26, 2011 9:07 PM > > > > > > To: Leon Portman; Elwell, John; Parthasarathi R (partr); > > > > Ram Mohan R > > > > > (rmohanr); Hutton, Andrew > > > > > > Cc: siprec@ietf.org > > > > > > Subject: RE: [siprec] Dialog state in the CS block of > > > > metadatamodel > > > > > [wasRE:Progressing the > > > > > > architecture document] > > > > > > > > > > > > Hi Leon, > > > > > > > > > > > > I am still having a hard time understanding why we need > > > > the session > > > > > state information per CS > > > > > > participant? Why is this required, who uses it, and how? > > > > > > > > > > > > Thanks, > > > > > > Charles > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: siprec-bounces@ietf.org > > > > [mailto:siprec-bounces@ietf.org] On > > > > > > Behalf Of Leon Portman > > > > > > > Sent: Saturday, March 26, 2011 10:31 AM > > > > > > > To: Elwell, John; Parthasarathi R (partr); Ram Mohan R > > > > (rmohanr); > > > > > > Hutton, Andrew > > > > > > > Cc: siprec@ietf.org > > > > > > > Subject: Re: [siprec] Dialog state in the CS block of > > > > > metadatamodel > > > > > > [wasRE:Progressing the > > > > > > > architecture document] > > > > > > > > > > > > > > John Hello > > > > > > > > > > > > > > I agree that SRS (and its application clients) interested > > > > > in SESSION > > > > > > level events and not underlying > > > > > > > DIALOG events. However we do need to support reporting > > > > > session state > > > > > > information per CS participant > > > > > > > that sometimes equals to dialog level and sometimes not. > > > > > > > > > > > > > > We could have define more application level state > > events like > > > > > instead > > > > > > of TRYING - > RINGING etc. > > > > > > > However they could be domain specific. > > > > > > > > > > > > > > Leon > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Elwell, John > > [mailto:john.elwell@siemens-enterprise.com] > > > > > > > Sent: Thursday, March 24, 2011 6:34 PM > > > > > > > To: Parthasarathi R (partr); Ram Mohan R (rmohanr); > > > > Leon Portman; > > > > > > Hutton, Andrew > > > > > > > Cc: siprec@ietf.org > > > > > > > Subject: RE: [siprec] Dialog state in the CS block of > > > > > metadata model > > > > > > [wasRE:Progressing the > > > > > > > architecture document] > > > > > > > > > > > > > > This discussion gives me some concerns, echoing to some > > > > > extent what > > > > > > Ram is saying. > > > > > > > > > > > > > > SIPREC is about session recording, where a session is the > > > > > information > > > > > > exchanged between participants > > > > > > > in a CS (the media streams) plus metadata. The > > metadata should > > > > > provide > > > > > > additional information about > > > > > > > the CS. This means information about the communication > > > > > SESSION, not > > > > > > about the SIP dialog that is used > > > > > > > to control that session. With this in mind, consider > > > > the following > > > > > > points, some of which have already > > > > > > > been raised: > > > > > > > > > > > > > > 1. There may be more than one SIP dialog involved if the > > > > > SRC is at a > > > > > > B2BUA or conference focus. > > > > > > > > > > > > > > 2. Does the CS necessarily need to be controlled > by SIP? For > > > > > example, > > > > > > it could be a PSTN call, an RTC- > > > > > > > Web call or a Jingle call. None of these preclude using > > > > > SIP for the > > > > > RS > > > > > > (that is what the charter of > > > > > > > SIPREC is all about - a SIP-based RS). > > > > > > > > > > > > > > 3. Somebody retrieving and playing back a recorded > > CS will be > > > > > > interested in session-related events > > > > > > > like participants leaving and joining (including the first > > > > > > participants joining at the start of the CS > > > > > > > and the last participants leaving a the end of the > > CS), media > > > > > streams > > > > > > starting and ending and > > > > > > > participants starting or stopping receipt of a > media stream. > > In > > > > > other > > > > > > words, changes of SESSION state, > > > > > > > not dialog state. > > > > > > > > > > > > > > 4. Some of the SIP dialog states just don't seem > > relevant. The > > > > > > distinction between early dialog and > > > > > > > full dialog in SIP does not necessarily > corresponding to any > > > > > > meaningful state change of the session. > > > > > > > For example, A makes a call to B and B answers and > > > > starts sending > > > > > > media. A receives and renders media > > > > > > > (perhaps it has already received SDP answer, allowing > > > > it to verify > > > > > the > > > > > > source of the media). Then A > > > > > > > receives the 200 OK (transitioning from an early dialog > > > > to a full > > > > > > dialog) and continues to receive > > > > > > > media. So although there is a dialog state > change, there is > > not > > > > > really > > > > > > a session state change. > > > > > > > > > > > > > > The bit about dialog state in the architecture > > draft is, in my > > > > > > opinion, a legacy from some earlier > > > > > > > discussions, before we started having the metadata > > > > discussions. I > > > > > > think the metadata discussions have > > > > > > > taken us in the right direction. > > > > > > > > > > > > > > John (as individual) > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: siprec-bounces@ietf.org > > > > > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of > > Parthasarathi > > R > > > > > > (partr) > > > > > > > > Sent: 24 March 2011 02:36 > > > > > > > > To: Ram Mohan R (rmohanr); Leon Portman; Hutton, Andrew > > > > > > > > Cc: siprec@ietf.org > > > > > > > > Subject: Re: [siprec] Dialog state in the CS block of > > metadata > > > > > model > > > > > > > > [wasRE:Progressing the architecture document] > > > > > > > > > > > > > > > > Ram, > > > > > > > > > > > > > > > > Please read inline. > > > > > > > > > > > > > > > > Thanks > > > > > > > > Partha > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > > > > > > > From: Ram Mohan R (rmohanr) > > > > > > > > Sent: Wed 3/23/2011 7:59 PM > > > > > > > > To: Parthasarathi R (partr); Leon Portman; > Hutton, Andrew > > > > > > > > Cc: siprec@ietf.org > > > > > > > > Subject: RE: [siprec] Dialog state in the CS block of > > metadata > > > > > model > > > > > > > > [wasRE:Progressing the architecture document] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I am still trying to understand what is the > > > > significance of this > > > > > > > > attribute w.r.t CS. Are we saying the attribute > represents > > the > > > > > state > > > > > > > > of CS ? > > > > > > > > > > > > > > > > Note that CS need not be one dialog. > > > > > > > > > > > > > > > > The attribute is to show the state of CS > > > > > only. As it is > > > > > > not > > > > > > > > single dialog, I have mentioned as session > state attribute > > > > > > > > > > > > > > > > > > > > > For cases like Conference where there may be different > > > > > participants, > > > > > > > > if SRC happens to be Focus how do you derive/what is > > "session > > > > > state" > > > > > > ? > > > > > > > > > > > > > > > > I really don't know whether it is generic. My > > thought > > > > > > > > processing of session state for conference is > as follows: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 1) First participant of conference early media (ivr > > > > play) may be > > > > > > > > considered as "early" state of session. > > > > > > > > > > > > > > > > 2) The session state is chaged to confirmed in case any > > > > > one of the > > > > > > > > participant joined in the conference. > > > > > > > > > > > > > > > > 3) The session state is move to terminated when the last > > > > > participant > > > > > > > > moved out of the conference. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Please let me know in case other way to represent the > > session > > > > > state > > > > > > of > > > > > > > > conference > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > For cases where B2BUA acts as SRC what is > > "session state" ? > > > > > > > > > > > > > > > > It looks straight forward for me. In > B2BUA case , > > > > > > > > > > > > > > > > 1) The stage where in two party is not connected, it is > > > > > considered > > > > > > as > > > > > > > > early state. > > > > > > > > > > > > > > > > 2) when both are connected, it is confirmed state > > > > > > > > > > > > > > > > 3) In case of BYE received from any one of the party, > > > > then CS is > > > > > > > > considered as terminated state > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Please note that this is applicable for 3PCC as well. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ram > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: siprec-bounces@ietf.org > > > > > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of > > Parthasarathi > > R > > > > > > (partr) > > > > > > > > Sent: Wednesday, March 23, 2011 6:13 AM > > > > > > > > To: Leon Portman; Hutton, Andrew > > > > > > > > Cc: siprec@ietf.org > > > > > > > > Subject: Re: [siprec] Dialog state in the CS block of > > metadata > > > > > model > > > > > > > > [wasRE:Progressing the architecture document] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Leon, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Shall we have optional "event" attribute to indicate the > > state > > > > > > change > > > > > > > > which is similar to "event" attribute in RFC 4235. > > > > The "event" > > > > > will > > > > > > > > include the following: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 1) cancelled > > > > > > > > > > > > > > > > 2) rejected > > > > > > > > > > > > > > > > 3) replaced > > > > > > > > > > > > > > > > 4) bye > > > > > > > > > > > > > > > > 5) error > > > > > > > > > > > > > > > > 6) timeout > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > Partha > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > > > > > > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > > > > > > > Sent: Tue 3/22/2011 9:37 PM > > > > > > > > To: Hutton, Andrew; Parthasarathi R (partr) > > > > > > > > Cc: siprec@ietf.org > > > > > > > > Subject: RE: Dialog state in the CS block of metadata > > > > model [was > > > > > > > > RE:Progressing the architecture document] > > > > > > > > > > > > > > > > It can be either application level error or dialog > > > > > level errors - > > > > > > like > > > > > > > > timeout or failures. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Leon > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: Hutton, Andrew > > > > > [mailto:andrew.hutton@siemens-enterprise.com] > > > > > > > > Sent: Tuesday, March 22, 2011 6:02 PM > > > > > > > > To: Leon Portman; Parthasarathi R (partr) > > > > > > > > Cc: siprec@ietf.org > > > > > > > > Subject: RE: Dialog state in the CS block of metadata > > > > model [was > > > > > RE: > > > > > > > > Progressing the architecture document] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > What would it be used for? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > > > > > > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > > > > > > > Sent: 22 March 2011 14:11 > > > > > > > > To: Parthasarathi R (partr); Hutton, Andrew > > > > > > > > Cc: siprec@ietf.org > > > > > > > > Subject: RE: Dialog state in the CS block of metadata > > > > > model [was > > > > > > RE: > > > > > > > > Progressing the architecture document] > > > > > > > > > > > > > > > > Should we have error state as well? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Leon > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: siprec-bounces@ietf.org > > > > > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of > > Parthasarathi > > R > > > > > > (partr) > > > > > > > > Sent: Tuesday, March 22, 2011 3:33 PM > > > > > > > > To: Parthasarathi R (partr); Hutton, Andrew > > > > > > > > Cc: siprec@ietf.org > > > > > > > > Subject: [siprec] Dialog state in the CS block of > > > > > metadata model > > > > > > [was > > > > > > > > RE: Progressing the architecture document] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The architecture document proposes to have > > > > > dialog/session state > > > > > > in > > > > > > > > Metadata model. To achieve this, "session state" > > > > > attribute has to > > > > > be > > > > > > > > added in the CS block of Metadata model. The possible > > > > values for > > > > > > > > session state are > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 1) Trying > > > > > > > > > > > > > > > > 2) Proceeding > > > > > > > > > > > > > > > > 3) Early > > > > > > > > > > > > > > > > 4) Confirmed > > > > > > > > > > > > > > > > 5) Terminated > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Please let me know in case any objection to add > > > > this attribute > > > > > > in > > > > > > > > Metadata model. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > Partha > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > > > > > > > From: Parthasarathi R (partr) > > > > > > > > Sent: Wednesday, March 16, 2011 5:40 AM > > > > > > > > To: Hutton, Andrew > > > > > > > > Cc: Elwell, John; siprec@ietf.org > > > > > > > > Subject: RE: Progressing the architecture document > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: siprec-bounces@ietf.org > > > > > > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of > > > > > Parthasarathi R > > > > > > > > (partr) > > > > > > > > > Sent: 14 March 2011 17:05 > > > > > > > > > To: Elwell, John; siprec@ietf.org > > > > > > > > > Subject: Re: [siprec] Progressing the > > > > architecture document > > > > > > > > > > > > > > > > > > > > > > > > > > Sec 4.3.1 whether 3rd bullet is required? > > > > > > > > > > > > > > > > > > > > > > > > > [AndyH]I assume it is as for example I assume > > it would be > > > > > > necessary > > > > > > > > to record early-media and update the SRS when the > > > > dialog changes > > > > > to > > > > > > > > the confirmed or terminated state. Does not > seem to be in > > the > > > > > > metadata > > > > > > > > draft though. In the end I will either remove > > these bullets > > or > > > > > align > > > > > > > > with the metadata draft. > > > > > > > > It is a good point. Dialog state shall be > > > > > added as one > > > > > > of > > > > > > > > the optional attribute in CS metadata block with > > > > > default value as > > > > > > > > mid-dialog. This helps to differentiate between > > early dialog > > > > > > > > (ringback) vs mid-dialog (normal > > > > > > > > conversation) in recording. In case of no > > objection for this > > > > > > attribute > > > > > > > > in metadata model, we will add it. We will work > > out metadata > > > > > format > > > > > > > > once the consensus occurs for metadata model. > > > > > > > > In case required, we will span separate mail thread to > > > > > close this > > > > > > > > issue > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > siprec mailing list > > > > > > > siprec@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > > > > > From john.elwell@siemens-enterprise.com Wed Apr 6 01:03:44 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE34C3A69B1 for ; Wed, 6 Apr 2011 01:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 86dY9GCVT-fm for ; Wed, 6 Apr 2011 01:03:44 -0700 (PDT) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 1A2603A69B0 for ; Wed, 6 Apr 2011 01:03:43 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-4038062 for siprec@ietf.org; Wed, 6 Apr 2011 10:05:26 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id D658F1EB82B4 for ; Wed, 6 Apr 2011 10:05:26 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 6 Apr 2011 10:05:27 +0200 From: "Elwell, John" To: "siprec@ietf.org" Date: Wed, 6 Apr 2011 10:05:25 +0200 Thread-Topic: RTP model Thread-Index: Acv0MWJQOZvQ2yljS52JVmSTv8qT7g== 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] RTP model X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2011 08:03:45 -0000 There were discussions before and during the Prague meeting about multiplex= ing media streams from different participants on to the same port. It becam= e apparent that we need a better understanding of the RTP model we are usin= g first, before we can answer this. The question is whether the SRC acts as a translator or as a mixer or end s= ystem. A translator is defined in RFC 3550 as: "An intermediate system that forwards RTP packets with their synchronization source identifier intact. Examples of translators include devices that convert encodings without mixing, replicators from multicast to unicast, and application-level filters in firewalls." A mixer or end system, in contrast, would assign new synchronisation source= s to RTP packets. The translator model seems to require less processing in the SRC - RTP pack= ets would just be forwarded unchanged to the SRC (i.e., the UDP packet woul= d change but its RTP payload would be unchanged). However, the translator model prevents some capabilities, e.g.: - the SRC cannot transcode (e.g., if the SRS does not support the codec use= d in the CS); - the SRC cannot mix streams from different participants (e.g., to reduce t= he bandwidth required on the RS path); - the SRC cannot encrypt streams on the RS path if unencrypted on the CS pa= th or vice versa; - the SRC cannot use different encryption keys on the CS path and the RS pa= th. Therefore, although the translator model might work in some situations, it = probably can't satisfy all requirements. Also with the translator model, we would need to be clear how RTCP would wo= rk. Consider an SRC at a B2BUA. It receives RTP packets from party A, forwa= rds them as a translator to party B, and also forwards them as a translator= to the SRS. The SRC will receive RTCP packets from both party B and the SR= S and needs to send RTCP packets to party A - how does the SRC handle this? John (as individual) = From john.elwell@siemens-enterprise.com Wed Apr 6 01:19:50 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BE163A68D6 for ; Wed, 6 Apr 2011 01:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.645 X-Spam-Level: X-Spam-Status: No, score=-101.645 tagged_above=-999 required=5 tests=[AWL=-0.846, BAYES_00=-2.599, J_CHICKENPOX_210=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_29=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dakIyHrSpFx8 for ; Wed, 6 Apr 2011 01:19:47 -0700 (PDT) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 3701F3A68D0 for ; Wed, 6 Apr 2011 01:19:45 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-4031062; Wed, 6 Apr 2011 10:21:28 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 3B5A21EB82B4; Wed, 6 Apr 2011 10:21:28 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 6 Apr 2011 10:21:28 +0200 From: "Elwell, John" To: Scott Orton , "Parthasarathi R (partr)" , "Paul Kyzivat (pkyzivat)" , Peter Saint-Andre Date: Wed, 6 Apr 2011 10:21:27 +0200 Thread-Topic: Extension data (was RE: [siprec] draft-ram-siprec-metadata-format-01) Thread-Index: AcvvneGYaEpydjZiTmOKSohan6QgKQAGBOGgAADiJqAAAD+KEAEeE8UQ Message-ID: References: <4D93ADCB.2050106@stpeter.im> <4D94416E.7070102@cisco.com><4D944429.10607@stpeter.im> <4D94714B.8010102@cisco.com> <21866C7FE177A4449B9136B5B24B1B130BC01128BC@EXMBXCLUS01.citservers.local> <21866C7FE177A4449B9136B5B24B1B130BC01128FB@EXMBXCLUS01.citservers.local> Keywords: SIPREC In-Reply-To: <21866C7FE177A4449B9136B5B24B1B130BC01128FB@EXMBXCLUS01.citservers.local> 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] Extension data (was RE: draft-ram-siprec-metadata-format-01) X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2011 08:19:50 -0000 I tend to agree with Scott that it would be easier to send extension data a= s part of the object to which it relates, rather than as a separate object. Advantages: 1. There is no need for an identifier on the extension data, since it is al= ways sent as part of the object. 2. When sending an updated object, it is clear by the presence or absence o= f extension data whether previous extension data still applies. Disadvantages: 1. It is not possible to update the extension data without updating the ent= ire object. I believe the advantages outweigh the disadvantage. John (as individual) > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Scott Orton > Sent: 31 March 2011 17:21 > To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); Peter=20 > Saint-Andre > Cc: siprec@ietf.org > Subject: Re: [siprec] draft-ram-siprec-metadata-format-01 >=20 > Inline comments. >=20 > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com]=20 > Sent: Thursday, March 31, 2011 10:42 AM > To: Scott Orton; Paul Kyzivat (pkyzivat); Peter Saint-Andre > Cc: siprec@ietf.org > Subject: RE: [siprec] draft-ram-siprec-metadata-format-01 >=20 > Scott, >=20 > Thanks for the feedback. >=20 > Thanks > Partha >=20 > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf > Of Scott Orton > Sent: Thursday, March 31, 2011 8:59 PM > To: Paul Kyzivat (pkyzivat); Peter Saint-Andre > Cc: siprec@ietf.org > Subject: Re: [siprec] draft-ram-siprec-metadata-format-01 >=20 > Here is some feedback on draft-ram-siprec-metadata-format-01.=20 >=20 > In the xml schema, the group is not listed as an element in=20 > the sequence > for the recording-metadata, which conflicts with the example in 5.1. >=20 > Agreed. I'll update in the next revision >=20 > In addition, I found it confusing that the extension data is=20 > included in > the participant type but not included in any of the other defined > elements in the recording-metadata. I think it might be good idea to > include the extension data as last element in the sequences for the > group, session, etc. As that would eliminate the need for the parent > attribute in the extension data assuming it stays close to its current > format. >=20 > It purely depend on whether extension-data has to be=20 > partially > passed across separately or not. Currently mechanism allows to pass > extension data partially within RS whereas in case it is an element > within any of the metadata block element like participant, stream then > it has to be passed across with any change in that particular metadata > block element. >=20 >=20 > I see the advantages of it being separate for the=20 > partial update. I would just like it to be consistent. Either=20 > in each element or in none of the elements. I think the key=20 > to deciding where to include the extension data is how a=20 > partial update should treat the data. If for example in the=20 > initial metadata you send to the SRS there is extensiondata=20 > associated with the participant. Then in an UPDATE the=20 > partial metadata for the participant update the stop-time,=20 > but does not include the extensiondata. How is the SRS=20 > expected to handle the lack of extensiondata? Should it treat=20 > it as the extensiondata is no longer relevant and delete it=20 > or should it assume it is not changed. If it should treat it=20 > as unchanged then how do you delete the extension data if it=20 > is no longer relevant. Since the definition of the extension=20 > data requires at least one string there is no way to remove=20 > it. All this leads me to believe that the extension data=20 > should be part of each element and there s > hould be no generic extensiondata element in the=20 > recording-metadata. >=20 > In case everyone feels that there is no need to pass extensiondata > explicitly, it realy simply the solution as there is no need another > open item like parent id within extensiondata > =20 >=20 > Regards, > Scott > =20 >=20 > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf > Of Paul Kyzivat > Sent: Thursday, March 31, 2011 7:19 AM > To: Peter Saint-Andre > Cc: siprec@ietf.org > Subject: Re: [siprec] draft-ram-siprec-metadata-format-01 >=20 >=20 >=20 > On 3/31/2011 5:06 AM, Peter Saint-Andre wrote: > > I am booked through 11 PM tonight. > > > > Tomorrow I have the following windows of time: > > > > 07:00-07:30 > > 15:15-16:00 > > > > Naturally that time might get filled if issues come up in=20 > some of my=20 > > working groups. :) >=20 > But you also have 11-12pm tonite? :-) > (That is much better for me than the others.) >=20 > Maybe its just too late in the week to hope for this. > We can take it to the list. >=20 > Thanks, > Paul >=20 > > On 3/31/11 10:55 AM, Paul Kyzivat wrote: > >> Peter/Joe, > >> > >> Do either of you have any time in the remainder of the=20 > week when some >=20 > >> of us could sit and try to sort out the right way to do=20 > the extension > data? > >> I doubt it would take very long. > >> > >> Thanks, > >> Paul > >> > >> On 3/30/2011 6:25 PM, Peter Saint-Andre wrote: > >>> Here is some quick feedback on=20 > draft-ram-siprec-metadata-format-01.=20 > >>> I hope to review it more fully soon. > >>> > >>> 1. I would change application/recording to=20 > application/recording+xml >=20 > >>> in accordance with RFC 3023 (many specs illustrate the use of XML=20 > >>> media types -- see for example RFC 4287). > >>> > >>> 2. The large number of elements is a=20 > bit confusing > in > >>> the examples. > >>> > >>> 3. In Section 5.1, the example has one element > >>> qualified by the 'urn:ietf:params:xml:ns:siprec'=20 > namespace (no other > >>> namespace is defined) and then multiple elements > >>> qualified by other namespaces ('http://example.com/groupapp',=20 > >>> 'http://example.com/sessionapp', etc.). Although those other=20 > >>> namespaces are certainly *allowed* to use "extensiondata" as an=20 > >>> element name (that's the beauty of namespaces), it is confusing in > this document. > >>> Perhaps you even meant to have elements=20 > qualified > by > >>> the 'urn:ietf:params:xml:ns:siprec' and then child elements=20 > >>> qualified by other namespaces (in accordance with the schema).=20 > >>> However, that is not clear in the spec. > >>> > >>> 4. There is no built-in datatype for xs:urnuuid, xs:streamMode,=20 > >>> xs:requester, and so on. See W3C XML Schema Part 2: > >>> > >>> http://www.w3.org/TR/xmlschema-2/#built-in-datatypes > >>> > >>> 5. The data in the elements with xml:lang=3D"it" really > should be > >>> Giulietta Capuleti and Romeo Montecchi. ;-) > >>> > >>> Peter > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> siprec mailing 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 Wed Apr 6 01:30:58 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1174C3A68E2 for ; Wed, 6 Apr 2011 01:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.238 X-Spam-Level: X-Spam-Status: No, score=-102.238 tagged_above=-999 required=5 tests=[AWL=-0.239, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6c-XWCF9asuR for ; Wed, 6 Apr 2011 01:30:56 -0700 (PDT) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 16E103A68D9 for ; Wed, 6 Apr 2011 01:30:55 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-4022900; Wed, 6 Apr 2011 10:32:17 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 37D3D1EB82B0; Wed, 6 Apr 2011 10:32:17 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 6 Apr 2011 10:32:17 +0200 From: "Elwell, John" To: "Parthasarathi R (partr)" , Hadriel Kaplan Date: Wed, 6 Apr 2011 10:32:16 +0200 Thread-Topic: [siprec] extensionData in XML Thread-Index: AcvxNFr/P3TGgoIBQ/abk6KeJk2EGwA8rJ/pAINJrbA= 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 Cc: "siprec@ietf.org" , "Jain, Rajnish" Subject: Re: [siprec] extensionData in XML X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2011 08:30:58 -0000 I already posted on this topic on the other thread. Partha states below an = additional motivation for handling extension data in the way specified in t= he current I-D. My counter argument is that anyone specifying particular ex= tension data could specify the expected behaviour when extension data is pr= esent in an object and then absent when that object is updated. For some ty= pes of metadata it could be that absence means it no longer applies, and fo= r other types of metadata it could be that absence means it has not changed= . The latter approach would avoid the need for repeating large quantities o= f metadata each time there is a minor change to an object. John (as individual) > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi R (partr) > Sent: 03 April 2011 19:46 > To: Hadriel Kaplan > Cc: siprec@ietf.org; Jain, Rajnish > Subject: Re: [siprec] extensionData in XML >=20 > Hadriel, > =20 > I guess we have common understaning to the extend that the=20 > intention is to send some extensiondata (Unknown) attribute=20 > by SRC which may or may not understand by SRS and also for=20 > the usage of xs:any as the solution. Few stuff are missing=20 > in yours proposal w.r.t partial data passing of extensiondata: > =20 > The question is whether there is a need to pass the extension=20 > data during every time the corresponding metadata block is=20 > passed or updated. For example, CS metadata block sends=20 > extension data specific to call center data like Agent is=20 > remote or local, agent or customer initiated call (direction)=20 > during the CS block creation (INVITE) and these constant=20 > information in extensiondata is not required to be passed in=20 > each update of CS metadata like adding video stream in the=20 > mid-session. > =20 > The current model allows to pass extensiondata only during=20 > the initial CS block creation and there is no need to update=20 > or resend while CS block is getting updated with other CS=20 > information. IMO, The current extensiondata mechanism is=20 > required as SIPREC puts lot of call centre specific=20 > attributes proposed during metadata model draft review as=20 > outside the scope of SIPREC and most of the attributes=20 > mentioned are constant within the scope of session.=20 > =20 > Also, it is possible to pass update only extension data=20 > within RS session without impacting parent element. Please=20 > let me know your and others opinion whethter it is fine to=20 > continue with the current extension-data element or to move=20 > xs:any element to each of the metadata block. > =20 > Thanks > Partha > ________________________________ >=20 > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: Sat 4/2/2011 6:19 PM > To: Parthasarathi R (partr) > Cc: Jain, Rajnish; siprec@ietf.org > Subject: Re: [siprec] extensionData in XML >=20 >=20 >=20 > Hi Partha, > I think you're missing my point (or I'm missing yours) - you=20 > can do all of that without specifying an "extensionData" XML=20 > element. Unknown XML elements are simply ignored by the=20 > other side, so Cisco can add a "ciscoPrivateData" XML element=20 > wherever it wants and send it to an Acme; and that private=20 > element will be ignored by Acme while everything else will=20 > continue to work. Which I think is the behavior you want, right? >=20 > -hadriel >=20 >=20 > On Apr 1, 2011, at 10:37 AM, Parthasarathi R (partr) wrote: >=20 > > Hadriel/Raj, > > > > Extensiondata XML is provided as per Metadata model=20 > extensiondata block. > > During the initial discussion of metadata model draft, we=20 > realized that > > lot of attributes specified for recording are call center=20 > specific or > > specific domain related and it is outside the scope of IETF=20 > SIPREC but > > it is required for those specific solution to work.=20 > Extensiondata XML > > element helps to meet those requirement. > > > > Extensiondata is provided with URN UUID to pass or not pass > > independently in partial data. But it is open item whether=20 > extensiondata > > has to be within specific metadatablock or not. > > > > Please read inline for more comments. > > > > Thanks > > Partha > > > > -----Original Message----- > > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf > > Of Jain, Rajnish > > Sent: Friday, April 01, 2011 6:41 PM > > To: Hadriel Kaplan; siprec@ietf.org > > Subject: Re: [siprec] extensionData in XML > > > > There may be such motivation from how the CSTA standards=20 > are specified. > > They have an element called privateData for each message. It is a > > placeholder for any non-standardized extensions. This could=20 > be legacy > > and may not mean much for the modern text based protocols. > > > > I really didn't get the reason why is it not=20 > require for modern > > text based protocols. This is more like generic param in=20 > SIP or xs:any > > in XML. RFC 6120 is a new RFC which has the similar usage. > > > > > > That said, I think you're right (this generally applies to any text > > based protocols and is the fundamental basis for forward/backward > > compatibility in such protocols). > > > > Raj > > > > > > ----------------------------------------------------- > > Please consider the environment before printing this email. > > > >> -----Original Message----- > >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >> Behalf Of Hadriel Kaplan > >> Sent: Thursday, March 31, 2011 8:43 PM > >> To: siprec@ietf.org > >> Subject: [siprec] extensionData in XML > >> > >> Howdy, > >> With regards to the extensionData concept and XML, I have=20 > a few basic > >> questions. I am by no means an XML expert so it could=20 > just be my lack > > > >> of knowledge which makes me confused. If so, just tell me to RTFM. > >> > >> draft-ram-siprec-metadata-04 says in section 4.6: > >> A recording metadata object contains additional data not=20 > specified > >> as > >> part of siprec. This is intended to accommodate future standards > >> track extensions, as well as vendor and user specific extensions. > >> The mechanism MUST provide a means of unambiguously=20 > distinguishing > >> such extension data. > >> > >> What confuses me is I didn't think XML had to do such=20 > machinations to > >> accommodate this need. I thought we could just specify in our RFCs > >> that unknown XML elements and attributes MUST be ignored, so that > >> future RFCs could add them without having to leave=20 > specific "blob" XML > > > >> elements to carry such data. Or at least that's what we've done so > >> far in SIP RFCs with XML bodies, afaik.=20 > >> namespace model that could be used to disambiguate proprietary > >> elements from standard ones. If both of those theories=20 > are correct, > >> why do we need to define an extensionData element? > >> > >> -hadriel > >> > >> _______________________________________________ > >> siprec mailing list > >> siprec@ietf.org > >> https://www.ietf.org/mailman/listinfo/siprec > > > > DISCLAIMER: This e-mail may contain information that is=20 > confidential, > > privileged or otherwise protected from disclosure. If you are not an > > intended recipient of this e-mail, do not duplicate or=20 > redistribute it > > by any means. Please delete it and any attachments and=20 > notify the sender > > that you have received it in error. Unintended recipients=20 > are prohibited > > from taking action on the basis of information in this e-mail.E-mail > > messages may contain computer viruses or other defects, may not be > > accurately replicated on other systems, or may be=20 > intercepted, deleted > > or interfered with without the knowledge of the sender or=20 > the intended > > recipient. If you are not comfortable with the risks associated with > > e-mail messages, you may decide not to use e-mail to=20 > communicate with > > IPC. IPC reserves the right, to the extent and under circumstances > > permitted by applicable law, to retain, monitor and intercept e-mail > > messages to and from its systems. > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec >=20 >=20 >=20 > = From partr@cisco.com Wed Apr 6 02:00:03 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 404F528C0F9 for ; Wed, 6 Apr 2011 02:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.054 X-Spam-Level: X-Spam-Status: No, score=-10.054 tagged_above=-999 required=5 tests=[AWL=0.545, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PRJyf+Qjn2ld for ; Wed, 6 Apr 2011 02:00:00 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 4503728C0DF for ; Wed, 6 Apr 2011 01:59:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=28878; q=dns/txt; s=iport; t=1302080503; x=1303290103; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=/AO0fDijNrBp8SF91+lx2iimk9VthGdS1pjmkxvKFNI=; b=I05ZBFmuaqFk2qEL4HblpNLASGQR5/9GYu99ebDiOYGI612jS763AhwS n/JzFksdhAA3pYFcizds9uCs2n0TS5KNpXqfTVkCLehgZ5oHM26mSKvhn XZ3U2aKpEAANp9G6AMV+5OW9n7EAzerv7vSWz/El6ubQFMV0KlsEQbGYy k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtMAAGMrnE2Q/khLgWdsb2JhbACYLY1KFAEBFiYliHmcI5wUgxCCXASFTItW X-IronPort-AV: E=Sophos;i="4.63,309,1299456000"; d="scan'208";a="82382433" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 06 Apr 2011 09:01:40 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3691XeB009073; Wed, 6 Apr 2011 09:01:40 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Apr 2011 14:31:33 +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: Wed, 6 Apr 2011 14:31:31 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Dialog state in the CS block of metadatamodel[wasRE:Progressing the architecture document] Thread-Index: AcvY+qyFanmfNOL5Qlq3osURZ2w4qAJbzb1IACUhGWAAGstGAwFGdfdAAAXbWKAAA+XmQAAAGhNQABG/CmwAHSHXEAAZDuOFABzjR+AAVixTcAAUeoQQAAAj4EAAHgihsAAClqhQAAXOdEAADtUDkAAjidVAAABgrFAAAo/hIAAdpARgAAc8P9ABkDDsUAACY20A References: <101C6067BEC68246B0C3F6843BCCC1E30B61DB3370@MCHP058A.global-ad.net><07465C1D981ABC41A344374066AE1A2C38A960C8F0@TLVMBX01.nice.com><101C6067BEC68246B0C3F6843BCCC1E30B61E96D11@MCHP058A.global-ad.net><07465C1D981ABC41A344374066AE1A2C38A960C9CA@TLVMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD05CC9E38@XMB-BGL-417.cisco.com> <07465C1D981ABC41A344374066AE1A2C38AB466335@TLVMBX01.nice.com> <07465C1D981ABC41A344374066AE1A2C38AB46639F@TLVMBX01.nice.com> <07465C1D981ABC41A344374066AE1A2C38AB466603@TLVMBX01.nice.com> <101C6067BEC68246B0C3F6843BCCC1E30B6D1ED8E0@MCHP058A.global-ad.net> <07465C1D981ABC41A344374066AE1A2C38AB466C1B@TLVMBX01.nice.com> From: "Parthasarathi R (partr)" To: "Elwell, John" , "Leon Portman" , "Charles Eckel (eckelcu)" , "Hutton, Andrew" , "Ram Mohan R (rmohanr)" X-OriginalArrivalTime: 06 Apr 2011 09:01:33.0459 (UTC) FILETIME=[3A0F5E30:01CBF439] Cc: siprec@ietf.org Subject: Re: [siprec] Dialog state in the CS block of metadatamodel[wasRE:Progressing the architecture document] X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2011 09:00:03 -0000 John, As we agreed upon on IETF-80 SIPREC meeting, session state attribute will not be included as part of the metadata model & format. In case any requires this attribute, Let them speak for it. I really don't very sure whether it is required to pass feature tag in SIPREC Metadata.=20 Thanks Partha=20 -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 Sent: Wednesday, April 06, 2011 1:06 PM To: Parthasarathi R (partr); Leon Portman; Charles Eckel (eckelcu); Hutton, Andrew; Ram Mohan R (rmohanr) Cc: siprec@ietf.org Subject: RE: [siprec] Dialog state in the CS block of metadatamodel[wasRE:Progressing the architecture document] So you are saying we might want to distinguish between media generated automatically and media generated by a human? I guess the only SIP mechanism for determining this is that "Automata" media feature tag in RFC 3840, but I don't know how widely implemented it is. John > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > Sent: 29 March 2011 09:50 > To: Elwell, John; Leon Portman; Charles Eckel (eckelcu); Hutton,=20 > Andrew; Ram Mohan R (rmohanr) > Cc: siprec@ietf.org > Subject: RE: [siprec] Dialog state in the CS block of=20 > metadatamodel[wasRE:Progressing the architecture document] > > John, > > I agree with you in case of media server participant sends "ringback" > media stream during the early dialog and later stage, the callee=20 > participant sends actual stream of the session using another=20 > offer/answer exchange. It is also possible that callee sends=20 > "ringback" > media stream wherein there is no difference between early or regular=20 > media in terms of metadata information. > > Having said that, it "may" or "may not" be matter whether the devices=20 > of the participant automatically creates the media stream or=20 > participant actually creates media stream. > > Thanks > Partha > > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Tuesday, March 29, 2011 10:39 AM > To: Parthasarathi R (partr); Leon Portman; Charles Eckel (eckelcu);=20 > Hutton, Andrew; Ram Mohan R (rmohanr) > Cc: siprec@ietf.org > Subject: RE: [siprec] Dialog state in the CS block of=20 > metadatamodel[wasRE:Progressing the architecture document] > > Partha, > > I think the real distinction you wish to make is between media coming=20 > from a particular participant (associated with the UAS) and media=20 > coming from some other entity (e.g., media server). In my view the=20 > latter case, if we choose to record it, comes from a different=20 > "participant". It has nothing to do with whether it is deemed early or > regular from a SIP dialog perspective. > > John (as individual) > > > > -----Original Message----- > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > Sent: 28 March 2011 17:53 > > To: Leon Portman; Charles Eckel (eckelcu); Hutton, Andrew; Elwell,=20 > > John; Ram Mohan R (rmohanr) > > Cc: siprec@ietf.org > > Subject: RE: [siprec] Dialog state in the CS block of=20 > > metadatamodel[wasRE:Progressing the architecture document] > > > > > > The question of "session" state is raised in my mind mainly to=20 > > distinguish between early media (Media before session > establishment) > > from normal media. Without the information in SIPREC metadata, the=20 > > early media will be associated with UAS participant's media stream. > > I'm interested in knowing whether SIPREC solution has to > differentiate > > > between early media from normal media. > > > > As per John below mail, there is no need to differentiate > as per the > > current requirement. If most of the folks feel so, I'm fine > with not > > including "session state" in metadata. > > > > Thanks > > Partha > > > > -----Original Message----- > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > Sent: Monday, March 28, 2011 7:16 PM > > To: Charles Eckel (eckelcu); Hutton, Andrew; Elwell, John;=20 > > Parthasarathi R (partr); Ram Mohan R (rmohanr) > > Cc: siprec@ietf.org > > Subject: RE: [siprec] Dialog state in the CS block of=20 > > metadatamodel[wasRE:Progressing the architecture document] > > > > Charles Hi > > > > Just to make clear, I don't think SRS should receive dialog level=20 > > state events about all CS dialogs. I think that we should > to support > > reporting high level session events. > > I understand the complexity of that and Ok to keep it open or next=20 > > phase extensions > > > > Leon > > > > -----Original Message----- > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > Sent: Monday, March 28, 2011 3:35 PM > > To: Hutton, Andrew; Elwell, John; Leon Portman; Parthasarathi R=20 > > (partr); Ram Mohan R (rmohanr) > > Cc: siprec@ietf.org > > Subject: RE: [siprec] Dialog state in the CS block of=20 > > metadatamodel[wasRE:Progressing the architecture document] > > > > I agree with this approach. Hopefully Leon and others that saw the=20 > > need for this state information can confirm if it works for them. > > > > Cheers, > > Charles > > > > > -----Original Message----- > > > From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com] > > > Sent: Monday, March 28, 2011 9:13 AM > > > To: Elwell, John; Leon Portman; Charles Eckel (eckelcu); > > Parthasarathi > > R (partr); Ram Mohan R > > > (rmohanr) > > > Cc: siprec@ietf.org > > > Subject: RE: [siprec] Dialog state in the CS block of > > metadatamodel[wasRE:Progressing the architecture > > > document] > > > > > > Hi, > > > > > > The draft-ietf-siprec-architecture has from the very > > beginning listed > > dialog state as an example of > > > what would be included in metadata which is why I raised > > the question. > > > > > > However it is true to say this was put in the > architecture document > > before we had firmed up the > > > requirements or starting any indepth work on metadata so I could > > accept that the architecture draft > > > simply got this wrong from the start and it maybe should > be removed. > > We could of course take the view > > > that if dialog events are important then the SRS could > subscribe to > > the dialog event package at the > > > SRC and SIPREC does not need to touch this. > > > > > > I don't think we can allow SIPREC metadata to extend as far as > > reporting everything that happens to > > > the CS including how it is linked to other CS's and what > > services are > > used on the CS (E.g. types of > > > transfer etc.). This would quickly get very difficult to > > define and we > > would probably fail. > > > > > > I would prefer to not report this state information in > metadata than > > open up the possibility of adding > > > lots of complexity. > > > > > > Regards > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Elwell, John > > > > Sent: 27 March 2011 14:50 > > > > To: Leon Portman; Charles Eckel (eckelcu); Parthasarathi > > R (partr); > > > > Ram Mohan R (rmohanr); Hutton, Andrew > > > > Cc: siprec@ietf.org > > > > Subject: RE: [siprec] Dialog state in the CS block of=20 > > > > metadatamodel[wasRE:Progressing the architecture document] > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > > > > Sent: 27 March 2011 11:48 > > > > > To: Charles Eckel (eckelcu); Elwell, John; Parthasarathi R=20 > > > > > (partr); Ram Mohan R (rmohanr); Hutton, Andrew > > > > > Cc: siprec@ietf.org > > > > > Subject: RE: [siprec] Dialog state in the CS block of=20 > > > > > metadatamodel[wasRE:Progressing the architecture document] > > > > > > > > > > Charles Hi > > > > > > > > > > Yes, it will be good to discuss it face to face. > > > > > > > > > > Just little background for such requirements. Today, > especially > > > > > for contact centers, it is important for SRS to capture the=20 > > > > > information how long customer was waiting for agent to > > answer the > > > > > call, which party hang up, how long was the hold time, > > if it was > > > > > blind transfer or consultation transfer. This information=20 > > > > > important both from quality management point of view > > and customer > > > > > experience point of view. > > > > [JRE] (as chair) I think the group needs to consider > > whether this is > > > > > > within scope. Looking at the requirements, we have: > > > > "REQ-012 The mechanism MUST provide the SRS with metadata > > describing > > > > CSs that are being recorded, including the media > being used and > > the > > > > identities of parties involved." > > > > If we are not recording the session while the caller is > > waiting to > > > > be answered, it seems we perhaps don't have a requirement for=20 > > > > metadata about that. This seems to be more about call detail=20 > > > > recording (CDR) rather than session recording. We can by > > all means > > > > have this discussion, but I am concerned about scope creep. > > > > > > > > > It is important also from compliance point of view to > detect if > > > > > somebody actually received the media stream or still was in=20 > > > > > pending state or media stream was disconnected. > > > > [JRE] (as individual) I agree we should show a participant as=20 > > > > receiving media only if the SRC believes media is > actually being > > > > sent to that participant (even then, there can be no > > guarantee it is > > > > > > received, e.g., because NAT or firewall traversal isn't > > functioning > > > > properly, severe packet loss, speaker volume is muted, > > etc..). But I > > > > > > have doubts whether it is necessarily to try to account > > for periods > > > > when the SRC knows a participant is not receiving media > > by saying it > > > > > > is because of alerting, hold or whatever. > > > > > > > > John > > > > > > > > > > > > > > > > > > Leon > > > > > > > > > > -----Original Message----- > > > > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > > > Sent: Sunday, March 27, 2011 11:35 AM > > > > > To: Leon Portman; Elwell, John; Parthasarathi R > > (partr); Ram Mohan > > > > > > > R (rmohanr); Hutton, Andrew > > > > > Cc: siprec@ietf.org > > > > > Subject: RE: [siprec] Dialog state in the CS block of=20 > > > > > metadatamodel[wasRE:Progressing the architecture document] > > > > > > > > > > Hi Leon, > > > > > > > > > > Thank you for your patience in trying to explain this to me;=20 > > > > > however, I still am not able to understand why the SRS > > might need > > > > > to know this information, or what it would do with it. > > > > > Is it that you need to know when a given participant > > was receiving > > > > > > > the recorded media and when it was not? If so, I do not think=20 > > > > > dialog state is sufficient. Is there some other > requirement or > > > > > functionality addressed by the SRS having such information? > > > > > Perhaps it is easier to discuss in person at the > > breakfast meeting > > > > > > > Wednesday or during the working group session. > > > > > > > > > > Cheers, > > > > > Charles > > > > > > > > > > > -----Original Message----- > > > > > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > > > > > Sent: Saturday, March 26, 2011 8:15 PM > > > > > > To: Charles Eckel (eckelcu); Elwell, John; Parthasarathi > > > > R (partr); > > > > > Ram Mohan R (rmohanr); Hutton, > > > > > > Andrew > > > > > > Cc: siprec@ietf.org > > > > > > Subject: RE: [siprec] Dialog state in the CS block of > > > > > metadatamodel[wasRE:Progressing the architecture > > > > > > document] > > > > > > > > > > > > Charles Hi > > > > > > > > > > > > Without participant session state, SRS will know only when > > > > > participant > > > > > is part of the session and will > > > > > > not know about intermediate states like ringing, > retrying etc. > > > > > > I know that we have media stream information per > > > > participant but not > > > > > sure that it is enough. > > > > > > > > > > > > Leon > > > > > > -----Original Message----- > > > > > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > > > > Sent: Saturday, March 26, 2011 9:07 PM > > > > > > To: Leon Portman; Elwell, John; Parthasarathi R (partr); > > > > Ram Mohan R > > > > > (rmohanr); Hutton, Andrew > > > > > > Cc: siprec@ietf.org > > > > > > Subject: RE: [siprec] Dialog state in the CS block of > > > > metadatamodel > > > > > [wasRE:Progressing the > > > > > > architecture document] > > > > > > > > > > > > Hi Leon, > > > > > > > > > > > > I am still having a hard time understanding why we need > > > > the session > > > > > state information per CS > > > > > > participant? Why is this required, who uses it, and how? > > > > > > > > > > > > Thanks, > > > > > > Charles > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: siprec-bounces@ietf.org > > > > [mailto:siprec-bounces@ietf.org] On > > > > > > Behalf Of Leon Portman > > > > > > > Sent: Saturday, March 26, 2011 10:31 AM > > > > > > > To: Elwell, John; Parthasarathi R (partr); Ram Mohan R > > > > (rmohanr); > > > > > > Hutton, Andrew > > > > > > > Cc: siprec@ietf.org > > > > > > > Subject: Re: [siprec] Dialog state in the CS block of > > > > > metadatamodel > > > > > > [wasRE:Progressing the > > > > > > > architecture document] > > > > > > > > > > > > > > John Hello > > > > > > > > > > > > > > I agree that SRS (and its application clients) interested > > > > > in SESSION > > > > > > level events and not underlying > > > > > > > DIALOG events. However we do need to support reporting > > > > > session state > > > > > > information per CS participant > > > > > > > that sometimes equals to dialog level and sometimes not. > > > > > > > > > > > > > > We could have define more application level state > > events like > > > > > instead > > > > > > of TRYING - > RINGING etc. > > > > > > > However they could be domain specific. > > > > > > > > > > > > > > Leon > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Elwell, John > > [mailto:john.elwell@siemens-enterprise.com] > > > > > > > Sent: Thursday, March 24, 2011 6:34 PM > > > > > > > To: Parthasarathi R (partr); Ram Mohan R (rmohanr); > > > > Leon Portman; > > > > > > Hutton, Andrew > > > > > > > Cc: siprec@ietf.org > > > > > > > Subject: RE: [siprec] Dialog state in the CS block of > > > > > metadata model > > > > > > [wasRE:Progressing the > > > > > > > architecture document] > > > > > > > > > > > > > > This discussion gives me some concerns, echoing to some > > > > > extent what > > > > > > Ram is saying. > > > > > > > > > > > > > > SIPREC is about session recording, where a session is the > > > > > information > > > > > > exchanged between participants > > > > > > > in a CS (the media streams) plus metadata. The > > metadata should > > > > > provide > > > > > > additional information about > > > > > > > the CS. This means information about the communication > > > > > SESSION, not > > > > > > about the SIP dialog that is used > > > > > > > to control that session. With this in mind, consider > > > > the following > > > > > > points, some of which have already > > > > > > > been raised: > > > > > > > > > > > > > > 1. There may be more than one SIP dialog involved if the > > > > > SRC is at a > > > > > > B2BUA or conference focus. > > > > > > > > > > > > > > 2. Does the CS necessarily need to be controlled > by SIP? For > > > > > example, > > > > > > it could be a PSTN call, an RTC- > > > > > > > Web call or a Jingle call. None of these preclude using > > > > > SIP for the > > > > > RS > > > > > > (that is what the charter of > > > > > > > SIPREC is all about - a SIP-based RS). > > > > > > > > > > > > > > 3. Somebody retrieving and playing back a recorded > > CS will be > > > > > > interested in session-related events > > > > > > > like participants leaving and joining (including the first > > > > > > participants joining at the start of the CS > > > > > > > and the last participants leaving a the end of the > > CS), media > > > > > streams > > > > > > starting and ending and > > > > > > > participants starting or stopping receipt of a > media stream. > > In > > > > > other > > > > > > words, changes of SESSION state, > > > > > > > not dialog state. > > > > > > > > > > > > > > 4. Some of the SIP dialog states just don't seem > > relevant. The > > > > > > distinction between early dialog and > > > > > > > full dialog in SIP does not necessarily > corresponding to any > > > > > > meaningful state change of the session. > > > > > > > For example, A makes a call to B and B answers and > > > > starts sending > > > > > > media. A receives and renders media > > > > > > > (perhaps it has already received SDP answer, allowing > > > > it to verify > > > > > the > > > > > > source of the media). Then A > > > > > > > receives the 200 OK (transitioning from an early dialog > > > > to a full > > > > > > dialog) and continues to receive > > > > > > > media. So although there is a dialog state > change, there is > > not > > > > > really > > > > > > a session state change. > > > > > > > > > > > > > > The bit about dialog state in the architecture > > draft is, in my > > > > > > opinion, a legacy from some earlier > > > > > > > discussions, before we started having the metadata > > > > discussions. I > > > > > > think the metadata discussions have > > > > > > > taken us in the right direction. > > > > > > > > > > > > > > John (as individual) > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: siprec-bounces@ietf.org=20 > > > > > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of > > Parthasarathi > > R > > > > > > (partr) > > > > > > > > Sent: 24 March 2011 02:36 > > > > > > > > To: Ram Mohan R (rmohanr); Leon Portman; Hutton, Andrew > > > > > > > > Cc: siprec@ietf.org > > > > > > > > Subject: Re: [siprec] Dialog state in the CS block of > > metadata > > > > > model > > > > > > > > [wasRE:Progressing the architecture document] > > > > > > > > > > > > > > > > Ram, > > > > > > > > > > > > > > > > Please read inline. > > > > > > > > > > > > > > > > Thanks > > > > > > > > Partha > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > > > > > > > From: Ram Mohan R (rmohanr) > > > > > > > > Sent: Wed 3/23/2011 7:59 PM > > > > > > > > To: Parthasarathi R (partr); Leon Portman; > Hutton, Andrew > > > > > > > > Cc: siprec@ietf.org > > > > > > > > Subject: RE: [siprec] Dialog state in the CS block of > > metadata > > > > > model > > > > > > > > [wasRE:Progressing the architecture document] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I am still trying to understand what is the > > > > significance of this > > > > > > > > attribute w.r.t CS. Are we saying the attribute > represents > > the > > > > > state > > > > > > > > of CS ? > > > > > > > > > > > > > > > > Note that CS need not be one dialog. > > > > > > > > > > > > > > > > The attribute is to show the state of CS > > > > > only. As it is > > > > > > not > > > > > > > > single dialog, I have mentioned as session > state attribute > > > > > > > > > > > > > > > > > > > > > For cases like Conference where there may be different > > > > > participants, > > > > > > > > if SRC happens to be Focus how do you derive/what is > > "session > > > > > state" > > > > > > ? > > > > > > > > > > > > > > > > I really don't know whether it is generic. My > > thought > > > > > > > > processing of session state for conference is > as follows: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 1) First participant of conference early media (ivr > > > > play) may be > > > > > > > > considered as "early" state of session. > > > > > > > > > > > > > > > > 2) The session state is chaged to confirmed in case any > > > > > one of the > > > > > > > > participant joined in the conference. > > > > > > > > > > > > > > > > 3) The session state is move to terminated when the last > > > > > participant > > > > > > > > moved out of the conference. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Please let me know in case other way to represent the > > session > > > > > state > > > > > > of > > > > > > > > conference > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > For cases where B2BUA acts as SRC what is > > "session state" ? > > > > > > > > > > > > > > > > It looks straight forward for me. In > B2BUA case , > > > > > > > > > > > > > > > > 1) The stage where in two party is not connected, it is > > > > > considered > > > > > > as > > > > > > > > early state. > > > > > > > > > > > > > > > > 2) when both are connected, it is confirmed state > > > > > > > > > > > > > > > > 3) In case of BYE received from any one of the party, > > > > then CS is > > > > > > > > considered as terminated state > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Please note that this is applicable for 3PCC as well. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ram > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: siprec-bounces@ietf.org=20 > > > > > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of > > Parthasarathi > > R > > > > > > (partr) > > > > > > > > Sent: Wednesday, March 23, 2011 6:13 AM > > > > > > > > To: Leon Portman; Hutton, Andrew > > > > > > > > Cc: siprec@ietf.org > > > > > > > > Subject: Re: [siprec] Dialog state in the CS block of > > metadata > > > > > model > > > > > > > > [wasRE:Progressing the architecture document] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Leon, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Shall we have optional "event" attribute to indicate the > > state > > > > > > change > > > > > > > > which is similar to "event" attribute in RFC 4235. > > > > The "event" > > > > > will > > > > > > > > include the following: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 1) cancelled > > > > > > > > > > > > > > > > 2) rejected > > > > > > > > > > > > > > > > 3) replaced > > > > > > > > > > > > > > > > 4) bye > > > > > > > > > > > > > > > > 5) error > > > > > > > > > > > > > > > > 6) timeout > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > Partha > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > > > > > > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > > > > > > > Sent: Tue 3/22/2011 9:37 PM > > > > > > > > To: Hutton, Andrew; Parthasarathi R (partr) > > > > > > > > Cc: siprec@ietf.org > > > > > > > > Subject: RE: Dialog state in the CS block of metadata > > > > model [was > > > > > > > > RE:Progressing the architecture document] > > > > > > > > > > > > > > > > It can be either application level error or dialog > > > > > level errors - > > > > > > like > > > > > > > > timeout or failures. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Leon > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: Hutton, Andrew > > > > > [mailto:andrew.hutton@siemens-enterprise.com] > > > > > > > > Sent: Tuesday, March 22, 2011 6:02 PM > > > > > > > > To: Leon Portman; Parthasarathi R (partr) > > > > > > > > Cc: siprec@ietf.org > > > > > > > > Subject: RE: Dialog state in the CS block of metadata > > > > model [was > > > > > RE: > > > > > > > > Progressing the architecture document] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > What would it be used for? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > > > > > > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > > > > > > > Sent: 22 March 2011 14:11 > > > > > > > > To: Parthasarathi R (partr); Hutton, Andrew > > > > > > > > Cc: siprec@ietf.org > > > > > > > > Subject: RE: Dialog state in the CS block of metadata > > > > > model [was > > > > > > RE: > > > > > > > > Progressing the architecture document] > > > > > > > > > > > > > > > > Should we have error state as well? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Leon > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: siprec-bounces@ietf.org=20 > > > > > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of > > Parthasarathi > > R > > > > > > (partr) > > > > > > > > Sent: Tuesday, March 22, 2011 3:33 PM > > > > > > > > To: Parthasarathi R (partr); Hutton, Andrew > > > > > > > > Cc: siprec@ietf.org > > > > > > > > Subject: [siprec] Dialog state in the CS block of > > > > > metadata model > > > > > > [was > > > > > > > > RE: Progressing the architecture document] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The architecture document proposes to have > > > > > dialog/session state > > > > > > in > > > > > > > > Metadata model. To achieve this, "session state" > > > > > attribute has to > > > > > be > > > > > > > > added in the CS block of Metadata model. The possible > > > > values for > > > > > > > > session state are > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 1) Trying > > > > > > > > > > > > > > > > 2) Proceeding > > > > > > > > > > > > > > > > 3) Early > > > > > > > > > > > > > > > > 4) Confirmed > > > > > > > > > > > > > > > > 5) Terminated > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Please let me know in case any objection to add > > > > this attribute > > > > > > in > > > > > > > > Metadata model. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > Partha > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > > > > > > > From: Parthasarathi R (partr) > > > > > > > > Sent: Wednesday, March 16, 2011 5:40 AM > > > > > > > > To: Hutton, Andrew > > > > > > > > Cc: Elwell, John; siprec@ietf.org > > > > > > > > Subject: RE: Progressing the architecture document > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: siprec-bounces@ietf.org > > > > > > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of > > > > > Parthasarathi R > > > > > > > > (partr) > > > > > > > > > Sent: 14 March 2011 17:05 > > > > > > > > > To: Elwell, John; siprec@ietf.org > > > > > > > > > Subject: Re: [siprec] Progressing the > > > > architecture document > > > > > > > > > > > > > > > > > > > > > > > > > > Sec 4.3.1 whether 3rd bullet is required? > > > > > > > > > > > > > > > > > > > > > > > > > [AndyH]I assume it is as for example I assume > > it would be > > > > > > necessary > > > > > > > > to record early-media and update the SRS when the > > > > dialog changes > > > > > to > > > > > > > > the confirmed or terminated state. Does not > seem to be in > > the > > > > > > metadata > > > > > > > > draft though. In the end I will either remove > > these bullets > > or > > > > > align > > > > > > > > with the metadata draft. > > > > > > > > It is a good point. Dialog state shall be > > > > > added as one > > > > > > of > > > > > > > > the optional attribute in CS metadata block with > > > > > default value as > > > > > > > > mid-dialog. This helps to differentiate between > > early dialog > > > > > > > > (ringback) vs mid-dialog (normal > > > > > > > > conversation) in recording. In case of no > > objection for this > > > > > > attribute > > > > > > > > in metadata model, we will add it. We will work > > out metadata > > > > > format > > > > > > > > once the consensus occurs for metadata model. > > > > > > > > In case required, we will span separate mail thread to > > > > > close this > > > > > > > > issue > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > siprec mailing list > > > > > > > siprec@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > > > > > From partr@cisco.com Wed Apr 6 02:14:34 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB20728C110 for ; Wed, 6 Apr 2011 02:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.762 X-Spam-Level: X-Spam-Status: No, score=-9.762 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZv0+LdzAcbS for ; Wed, 6 Apr 2011 02:14:33 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id E00F93A68E4 for ; Wed, 6 Apr 2011 02:14:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=9525; q=dns/txt; s=iport; t=1302081377; x=1303290977; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=uXAdbNd4fapjduUvjo0U1HTj24KMAfn1IbrjCryb7EI=; b=D7iMrnc3uCgFrb4jb8CQTrKKtYwq9UW53qsxikJ/2k47RDD2D8gvMl7g tz1UzyGhYrGWzu6jL0PyEasetN4pE01jFpuAVh03bKeZs2bhtINXDnpMs sDLqZ/q9KKYvPqfNqIg7X4bFlkjR1d4HQfYszlDM/85MKI8jWm1guph9g 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtMAADsunE2Q/khMgWdsb2JhbACYLY1KFAEBCwsmJYh5nEycE4VsBIVMi1Y X-IronPort-AV: E=Sophos;i="4.63,309,1299456000"; d="scan'208";a="24621262" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 06 Apr 2011 09:16:16 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p369GFBq014211; Wed, 6 Apr 2011 09:16:15 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Apr 2011 14:46:14 +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: Wed, 6 Apr 2011 14:46:13 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] extensionData in XML Thread-Index: AcvxNFr/P3TGgoIBQ/abk6KeJk2EGwA8rJ/pAINJrbAAAUHXgA== References: From: "Parthasarathi R (partr)" To: "Elwell, John" , "Hadriel Kaplan" X-OriginalArrivalTime: 06 Apr 2011 09:16:14.0356 (UTC) FILETIME=[471D9540:01CBF43B] Cc: siprec@ietf.org, "Jain, Rajnish" , "Peter Saint-Andre \(psaintan\)" Subject: Re: [siprec] extensionData in XML X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2011 09:14:34 -0000 John, Please read inline Thanks Partha=20 -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 Sent: Wednesday, April 06, 2011 2:02 PM To: Parthasarathi R (partr); Hadriel Kaplan Cc: siprec@ietf.org; Jain, Rajnish Subject: RE: [siprec] extensionData in XML I already posted on this topic on the other thread. Partha states below an additional motivation for handling extension data in the way specified in the current I-D. My counter argument is that anyone specifying particular extension data could specify the expected behaviour when extension data is present in an object and then absent when that object is updated. For some types of metadata it could be that absence means it no longer applies, and for other types of metadata it could be that absence means it has not changed.=20 Currently, metadata format draft XML element is written with the basics that "it is no longer applies" in case specific element is absent in the update. The question is how the information of extensiondata absence means "it is no longer applies" or "it has not changed" has to be passed between SRC and SRS. Here, there is a need of common understanding between SRC and SRS or else the information will be misunderstand even though both parties understand the specific extension. The current extensiondata is taken the route of all other metadata block XML element definition. There may be better way to represent in extensiondata XML element apart from creating new metadata block with URN UUID. I'm including Peter for his advise on XML front. =20 The latter approach would avoid the need for repeating large quantities of metadata each time there is a minor change to an object. John (as individual) > -----Original Message----- > From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi R (partr) > Sent: 03 April 2011 19:46 > To: Hadriel Kaplan > Cc: siprec@ietf.org; Jain, Rajnish > Subject: Re: [siprec] extensionData in XML >=20 > Hadriel, > =20 > I guess we have common understaning to the extend that the intention=20 > is to send some extensiondata (Unknown) attribute by SRC which may or=20 > may not understand by SRS and also for the usage of xs:any as the=20 > solution. Few stuff are missing in yours proposal w.r.t partial data=20 > passing of extensiondata: > =20 > The question is whether there is a need to pass the extension data=20 > during every time the corresponding metadata block is passed or=20 > updated. For example, CS metadata block sends extension data specific=20 > to call center data like Agent is remote or local, agent or customer=20 > initiated call (direction) during the CS block creation (INVITE) and=20 > these constant information in extensiondata is not required to be=20 > passed in each update of CS metadata like adding video stream in the=20 > mid-session. > =20 > The current model allows to pass extensiondata only during the initial > CS block creation and there is no need to update or resend while CS=20 > block is getting updated with other CS information. IMO, The current=20 > extensiondata mechanism is required as SIPREC puts lot of call centre=20 > specific attributes proposed during metadata model draft review as=20 > outside the scope of SIPREC and most of the attributes mentioned are=20 > constant within the scope of session. > =20 > Also, it is possible to pass update only extension data within RS=20 > session without impacting parent element. Please let me know your and=20 > others opinion whethter it is fine to continue with the current=20 > extension-data element or to move xs:any element to each of the=20 > metadata block. > =20 > Thanks > Partha > ________________________________ >=20 > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: Sat 4/2/2011 6:19 PM > To: Parthasarathi R (partr) > Cc: Jain, Rajnish; siprec@ietf.org > Subject: Re: [siprec] extensionData in XML >=20 >=20 >=20 > Hi Partha, > I think you're missing my point (or I'm missing yours) - you can do=20 > all of that without specifying an "extensionData" XML element. =20 > Unknown XML elements are simply ignored by the other side, so Cisco=20 > can add a "ciscoPrivateData" XML element wherever it wants and send it > to an Acme; and that private element will be ignored by Acme while=20 > everything else will continue to work. Which I think is the behavior=20 > you want, right? >=20 > -hadriel >=20 >=20 > On Apr 1, 2011, at 10:37 AM, Parthasarathi R (partr) wrote: >=20 > > Hadriel/Raj, > > > > Extensiondata XML is provided as per Metadata model > extensiondata block. > > During the initial discussion of metadata model draft, we > realized that > > lot of attributes specified for recording are call center > specific or > > specific domain related and it is outside the scope of IETF > SIPREC but > > it is required for those specific solution to work.=20 > Extensiondata XML > > element helps to meet those requirement. > > > > Extensiondata is provided with URN UUID to pass or not pass=20 > > independently in partial data. But it is open item whether > extensiondata > > has to be within specific metadatablock or not. > > > > Please read inline for more comments. > > > > Thanks > > Partha > > > > -----Original Message----- > > From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On Behalf > > Of Jain, Rajnish > > Sent: Friday, April 01, 2011 6:41 PM > > To: Hadriel Kaplan; siprec@ietf.org > > Subject: Re: [siprec] extensionData in XML > > > > There may be such motivation from how the CSTA standards > are specified. > > They have an element called privateData for each message. It is a=20 > > placeholder for any non-standardized extensions. This could > be legacy > > and may not mean much for the modern text based protocols. > > > > I really didn't get the reason why is it not > require for modern > > text based protocols. This is more like generic param in > SIP or xs:any > > in XML. RFC 6120 is a new RFC which has the similar usage. > > > > > > That said, I think you're right (this generally applies to any text=20 > > based protocols and is the fundamental basis for forward/backward=20 > > compatibility in such protocols). > > > > Raj > > > > > > ----------------------------------------------------- > > Please consider the environment before printing this email. > > > >> -----Original Message----- > >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > >> Behalf Of Hadriel Kaplan > >> Sent: Thursday, March 31, 2011 8:43 PM > >> To: siprec@ietf.org > >> Subject: [siprec] extensionData in XML > >> > >> Howdy, > >> With regards to the extensionData concept and XML, I have > a few basic > >> questions. I am by no means an XML expert so it could > just be my lack > > > >> of knowledge which makes me confused. If so, just tell me to RTFM. > >> > >> draft-ram-siprec-metadata-04 says in section 4.6: > >> A recording metadata object contains additional data not > specified > >> as > >> part of siprec. This is intended to accommodate future standards > >> track extensions, as well as vendor and user specific extensions. > >> The mechanism MUST provide a means of unambiguously > distinguishing > >> such extension data. > >> > >> What confuses me is I didn't think XML had to do such > machinations to > >> accommodate this need. I thought we could just specify in our RFCs > >> that unknown XML elements and attributes MUST be ignored, so that=20 > >> future RFCs could add them without having to leave > specific "blob" XML > > > >> elements to carry such data. Or at least that's what we've done so > >> far in SIP RFCs with XML bodies, afaik. > >> namespace model that could be used to disambiguate proprietary=20 > >> elements from standard ones. If both of those theories > are correct, > >> why do we need to define an extensionData element? > >> > >> -hadriel > >> > >> _______________________________________________ > >> siprec mailing list > >> siprec@ietf.org > >> https://www.ietf.org/mailman/listinfo/siprec > > > > DISCLAIMER: This e-mail may contain information that is > confidential, > > privileged or otherwise protected from disclosure. If you are not an > > intended recipient of this e-mail, do not duplicate or > redistribute it > > by any means. Please delete it and any attachments and > notify the sender > > that you have received it in error. Unintended recipients > are prohibited > > from taking action on the basis of information in this e-mail.E-mail > > messages may contain computer viruses or other defects, may not be=20 > > accurately replicated on other systems, or may be > intercepted, deleted > > or interfered with without the knowledge of the sender or > the intended > > recipient. If you are not comfortable with the risks associated with > > e-mail messages, you may decide not to use e-mail to > communicate with > > IPC. IPC reserves the right, to the extent and under circumstances=20 > > permitted by applicable law, to retain, monitor and intercept e-mail > > messages to and from its systems. > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec >=20 >=20 >=20 >=20 From rmohanr@cisco.com Wed Apr 6 02:32:04 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6F4D3A69BD for ; Wed, 6 Apr 2011 02:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.428 X-Spam-Level: X-Spam-Status: No, score=-10.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KAT9elqhte0K for ; Wed, 6 Apr 2011 02:32:03 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 4D4163A68E6 for ; Wed, 6 Apr 2011 02:32:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=1550; q=dns/txt; s=iport; t=1302082427; x=1303292027; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=LRwwPfXXbG/dFRhjKSV7Jw4Z06Z4T/SJlC/sYQkWc/E=; b=igy4aas2fy8nScRiirvX2JqzkJPhs7NTzX943XYN3gmkP+4MKyWTm3z4 X0TMqWmAo8C5whLyXzh0209Dt+s3PYKxOR31Wp5H/9wLguUdzmKoGxi3M 4EhuzZmMCHXvZcWSkyN/Ue+arfuuXY4mQeWcib6jopOdXPZHP+z/M5YgS 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtMAACYznE2Q/khLgWdsb2JhbACYLY1KFAEBFiYlpTqcGYVsBIVMi1Y X-IronPort-AV: E=Sophos;i="4.63,309,1299456000"; d="scan'208";a="24624863" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 06 Apr 2011 09:33:45 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p369Wo6i021166; Wed, 6 Apr 2011 09:33:44 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); Wed, 6 Apr 2011 15:03:36 +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: Wed, 6 Apr 2011 15:03:33 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD05EF91D0@XMB-BGL-417.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Changes to metadata model Thread-Index: Acv0Kztn1HsWWdpDSIaKHoqN2B1ZpgAEdVsg References: From: "Ram Mohan R (rmohanr)" To: "Elwell, John" , X-OriginalArrivalTime: 06 Apr 2011 09:33:36.0080 (UTC) FILETIME=[B4080D00:01CBF43D] Subject: Re: [siprec] Changes to metadata model X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2011 09:32:05 -0000 Hi John, Thanks for listing the items that were agreed upon in IETF80.=20 There is one more item about having CS directly associated with RS brought up by Scott in the mailer. See this mail thread http://www.ietf.org/mail-archive/web/siprec/current/msg01701.html I plan to incorporate this also in draft-ietf-siprec-metadata-00 along with the below mentioned points. Please let me know if anyone has issues with the same by end of this week(2011-04-10) Regards, Ram > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Elwell, John > Sent: Wednesday, April 06, 2011 12:51 PM > To: siprec@ietf.org > Subject: [siprec] Changes to metadata model >=20 > During the discussions in Prague on draft-ram-siprec-metadata-04 > (already agreed for adoption by WG) the following agreements were > reached: > - add start/stop time attributes for Communication Session; > - do not include session state attribute for Communication Session; > - the metadata model should include media streams that are not being > delivered to the SRS (e.g., those offered by the SRC but not accepted > by the SRS). >=20 > If there is any counter opinion, please raise it on the list by the end > of this week (2011-04-10). I would like the editors to produce draft- > ietf-siprec-metadata-00 with these changes early next week. >=20 > John > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From mperumal@cisco.com Wed Apr 6 02:45:02 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3862C3A68F8 for ; Wed, 6 Apr 2011 02:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dzk8mhpCS5sf for ; Wed, 6 Apr 2011 02:45:01 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 9EB6F3A68F6 for ; Wed, 6 Apr 2011 02:45:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=3819; q=dns/txt; s=iport; t=1302083204; x=1303292804; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=TQpRdCoizgPBxdE2SjOEel9hGtTAU+2C76oIFqicXks=; b=SvduQOjhYOnyGrnjJMCJALq+leQnNbreZrG1i38ALpVtut6iSgyzY6+z qmDotecEftDJXGtdMx27ZwM+eXXu8b9JIG+H3UNOMY6zF6YPEViCmX6I+ 9/LkAfm8LHjl6O0VySFbY20hVcSByH8kU3AzUnxUijP5H9qBr6SODEuK8 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtMAAPo1nE2Q/khNgWdsb2JhbACYLY1KFAEBFiYlpTKcGYVsBIVMi1Y X-IronPort-AV: E=Sophos;i="4.63,309,1299456000"; d="scan'208";a="82391236" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 06 Apr 2011 09:46:43 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p369k7LU009166; Wed, 6 Apr 2011 09:46:43 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Apr 2011 15:16:21 +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: Wed, 6 Apr 2011 15:16:18 +0530 Message-ID: <1D062974A4845E4D8A343C65380492020523B9E8@XMB-BGL-414.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] RTP model Thread-Index: Acv0MWJQOZvQ2yljS52JVmSTv8qT7gABSzBQ References: From: "Muthu ArulMozhi Perumal (mperumal)" To: "Elwell, John" , X-OriginalArrivalTime: 06 Apr 2011 09:46:21.0128 (UTC) FILETIME=[7C091C80:01CBF43F] Subject: Re: [siprec] RTP model X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2011 09:45:02 -0000 Except for mixing, the translator model doesn't prevent the SRC from transcoding or encrypting or using different encryption keys for the CS and RS. RFC 5117 describes different kinds of translators and this is what it says about media translators: Media Translators (Topo-Media-Translator), in contrast, modify the media stream itself. This process is commonly known as transcoding. The modification of the media stream can be as small as removing parts of the stream, and it can go all the way to a full transcoding (down to the sample level or equivalent) utilizing a different media codec. Media Translators are commonly used to connect entities without a common interoperability point. However, I agree RTCP processing at SRC needs more thought if it were a translator and some of the guidelines are described in section 7.2 of RFC 3550. For e.g, while the SRC may want to forward the SDES information to the SRS for it to correlate it with the participant information delivered in metadata, it may need to modify the SR information like byte count, packet count etc, since what it may send to the SRS might be different from what is may receive from the participants. The general rule specified in RFC 3550 is to do what makes sense for a particular translation. So, we could come up our own guidelines when the SRC is a translator, depending on what makes sense for media recording. Muthu |-----Original Message----- |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John |Sent: Wednesday, April 06, 2011 1:35 PM |To: siprec@ietf.org |Subject: [siprec] RTP model | |There were discussions before and during the Prague meeting about multiplexing media streams from |different participants on to the same port. It became apparent that we need a better understanding of |the RTP model we are using first, before we can answer this. | |The question is whether the SRC acts as a translator or as a mixer or end system. | |A translator is defined in RFC 3550 as: |"An intermediate system that forwards RTP packets | with their synchronization source identifier intact. Examples of | translators include devices that convert encodings without mixing, | replicators from multicast to unicast, and application-level | filters in firewalls." | |A mixer or end system, in contrast, would assign new synchronisation sources to RTP packets. | |The translator model seems to require less processing in the SRC - RTP packets would just be forwarded |unchanged to the SRC (i.e., the UDP packet would change but its RTP payload would be unchanged). | |However, the translator model prevents some capabilities, e.g.: |- the SRC cannot transcode (e.g., if the SRS does not support the codec used in the CS); |- the SRC cannot mix streams from different participants (e.g., to reduce the bandwidth required on |the RS path); |- the SRC cannot encrypt streams on the RS path if unencrypted on the CS path or vice versa; |- the SRC cannot use different encryption keys on the CS path and the RS path. | |Therefore, although the translator model might work in some situations, it probably can't satisfy all |requirements. | |Also with the translator model, we would need to be clear how RTCP would work. Consider an SRC at a |B2BUA. It receives RTP packets from party A, forwards them as a translator to party B, and also |forwards them as a translator to the SRS. The SRC will receive RTCP packets from both party B and the |SRS and needs to send RTCP packets to party A - how does the SRC handle this? | |John (as individual) | | |_______________________________________________ |siprec mailing list |siprec@ietf.org |https://www.ietf.org/mailman/listinfo/siprec From john.elwell@siemens-enterprise.com Wed Apr 6 05:39:55 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CB913A692E for ; Wed, 6 Apr 2011 05:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.236 X-Spam-Level: X-Spam-Status: No, score=-102.236 tagged_above=-999 required=5 tests=[AWL=-0.237, BAYES_00=-2.599, J_CHICKENPOX_25=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iXIV3XIVUp8L for ; Wed, 6 Apr 2011 05:39:54 -0700 (PDT) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id B058D3A692C for ; Wed, 6 Apr 2011 05:39:53 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-4027099; Wed, 6 Apr 2011 14:41:36 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id D21EB23F028E; Wed, 6 Apr 2011 14:41:36 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 6 Apr 2011 14:41:37 +0200 From: "Elwell, John" To: "Charles Eckel (eckelcu)" , "Ram Mohan R (rmohanr)" Date: Wed, 6 Apr 2011 14:41:35 +0200 Thread-Topic: [siprec] comments on draft-ram-siprec-metadata-04 Thread-Index: Acvym8c6ze1biSmuSseX9NIPrqwitABvAG8A Message-ID: References: <35BCE99A477D6A4986FB2216D8CF2CFD05DD8BC3@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD05DD8C2A@XMB-BGL-417.cisco.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] comments on draft-ram-siprec-metadata-04 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2011 12:39:55 -0000 Yes, the wording from siprec-req works for me. John =20 > -----Original Message----- > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com]=20 > Sent: 04 April 2011 08:42 > To: Ram Mohan R (rmohanr) > Cc: Elwell, John; Parthasarathi R (partr); siprec@ietf.org > Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 >=20 > Sure, that wording works for me.=20 >=20 > Thanks, > Charles >=20 >=20 >=20 > On Apr 4, 2011, at 5:42 AM, "Ram Mohan R (rmohanr)"=20 > wrote: >=20 > > Hi Charles, > >=20 > > Please see inline > >=20 > >> -----Original Message----- > >> From: Charles Eckel (eckelcu) > >> Sent: Sunday, April 03, 2011 11:52 PM > >> To: Ram Mohan R (rmohanr); 'Elwell, John'; Parthasarathi R (partr); > >> 'siprec@ietf.org' > >> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > >>=20 > >> Hi Ram, > >>=20 > >> I agree that main point focus of the metadata is the description of > > the > >> communication sessions(s); however, the metadata model contains a > >> recording session element, and the recording element contains > >> attributes specific to the recording session. For that=20 > reason, I think > >> it is misleading to say the metadata describes the communication > >> session. > >> Perhaps you are suggesting the recording session element should be > >> removed from the model, and it may be maintained in an unspecified > >> manner within the SRS? > >=20 > > No I am not suggesting that. I think we need slightly=20 > better wording > > than that. > > Metadata describes the CS but is carried in RS. Metadata=20 > has information > > about CS participants, different transactions of CS(which=20 > are carried in > > RS). Metadata maps CS participants to the recorded media=20 > sent in RS. > > So to summarize Metadata describes the recorded media sent=20 > in RS and its > > relation to CS. > >=20 > > Perhaps we could retain the wordings of the Req draft ? > > The requirement draft has > > Metadata: Information that describes recorded media and the CS to > > which they relate. > >=20 > > Thoughts ? > >=20 > > Ram > >=20 > >>=20 > >> Cheers, > >> Charles > >>=20 > >>> -----Original Message----- > >>> From: Ram Mohan R (rmohanr) > >>> Sent: Saturday, April 02, 2011 11:41 AM > >>> To: Charles Eckel (eckelcu); Elwell, John; Parthasarathi=20 > R (partr); > >> siprec@ietf.org > >>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > >>>=20 > >>> Hi Charles, > >>>=20 > >>> Inline > >>>=20 > >>>> -----Original Message----- > >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >>>> Behalf Of Charles Eckel (eckelcu) > >>>> Sent: Friday, April 01, 2011 6:39 PM > >>>> To: Elwell, John; Parthasarathi R (partr); siprec@ietf.org > >>>> Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 > >>>>=20 > >>>> How about: > >>>>=20 > >>>> OLD: > >>>> Metadata is the data that describes the communication session. > >>>>=20 > >>>> NEW: > >>>> Metadata is the data that describes the recording session, > >> including > >>>> the > >>>> communication sessions it is recording. > >>>=20 > >>> This text seems to create more confusion. Please note=20 > Metadata does > >> not describe anything about RS. > >>> It describes only about CS. > >>>=20 > >>> Ram > >>>=20 > >>>>=20 > >>>> Cheers, > >>>> Charles > >>>>=20 > >>>>> -----Original Message----- > >>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > >>>>> Sent: Thursday, March 31, 2011 6:30 PM > >>>>> To: Charles Eckel (eckelcu); Parthasarathi R (partr); > >> siprec@ietf.org > >>>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > >>>>>=20 > >>>>> Charles, > >>>>>=20 > >>>>> OK, I see how you got there, but really it describes the CSs > > (and > >> CS > >>>> groups) that are being carried in > >>>>> the RS. Any ideas how better to word it? > >>>>>=20 > >>>>> John > >>>>>=20 > >>>>>> -----Original Message----- > >>>>>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > >>>>>> Sent: 31 March 2011 17:11 > >>>>>> To: Elwell, John; Parthasarathi R (partr); siprec@ietf.org > >>>>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > >>>>>>=20 > >>>>>> Hi John, > >>>>>>=20 > >>>>>> Please see inline. > >>>>>>=20 > >>>>>>> -----Original Message----- > >>>>>>> From: Elwell, John [mailto:john.elwell@siemens- > >> enterprise.com] > >>>>>>> Sent: Wednesday, March 30, 2011 11:01 AM > >>>>>>> To: Charles Eckel (eckelcu); Parthasarathi R (partr); > >>>>>> siprec@ietf.org > >>>>>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata- > >> 04 > >>>>>>>=20 > >>>>>>>=20 > >>>>>>>=20 > >>>>>>>> -----Original Message----- > >>>>>>>> From: siprec-bounces@ietf.org > >>>>>>>> [mailto:siprec-bounces@ietf.org] On Behalf Of Charles > > Eckel > >>>>>> (eckelcu) > >>>>>>>> Sent: 29 March 2011 15:38 > >>>>>>>> To: Parthasarathi R (partr); siprec@ietf.org > >>>>>>>> Subject: Re: [siprec] comments on draft-ram-siprec- > >> metadata-04 > >>>>>>>>=20 > >>>>>>>> Hi Partha, > >>>>>>>>=20 > >>>>>>>> Thanks for your response. This addresses all of my > >> concerns. > >>>>>>>> Please see > >>>>>>>> one additional clarification inline. > >>>>>>>>=20 > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: Parthasarathi R (partr) > >>>>>>>>> Sent: Tuesday, March 29, 2011 10:31 AM > >>>>>>>>> To: Charles Eckel (eckelcu); siprec@ietf.org > >>>>>>>>> Subject: RE: [siprec] comments on draft-ram-siprec- > >> metadata- > >>>> 04 > >>>>>>>>>=20 > >>>>>>>>> Charles, > >>>>>>>>>=20 > >>>>>>>>> Thanks for review the document. Please read inline. > >>>>>>>>>=20 > >>>>>>>>> Thanks > >>>>>>>>> Partha > >>>>>>>>>=20 > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: siprec-bounces@ietf.org > >>>>>> [mailto:siprec-bounces@ietf.org] On > >>>>>>>> Behalf Of Charles Eckel (eckelcu) > >>>>>>>>> Sent: Sunday, March 27, 2011 12:35 AM > >>>>>>>>> To: siprec@ietf.org > >>>>>>>>> Subject: [siprec] comments on draft-ram-siprec-metadata- > >> 04 > >>>>>>>>>=20 > >>>>>>>>> I gave the draft and read and have the following > >> comments. > >>>>>>>>>=20 > >>>>>>>>> Section 3. Think the metadata describes the recording > >>>>>>>> session, not the > >>>>>>>> communication session. Replace > >>>>>>>>> "metamodel" with "metadata model", and "MAY be conveyed > >> in > >>>>>> Recording > >>>>>>>> Session" with "MAY be conveyed > >>>>>>>>> within the Recording Session", and "time a change > >> occurred by > >>>> be > >>>>>>>> assumed" with "time a change occurred > >>>>>>>>> may be assumed". > >>>>>>> [JRE] I am not sure exactly what text Charles was commenting > >> on, > >>>> but > >>>>>> in my opinion metadata describes > >>>>>>> a CS (and how media streams in the RS relate to that CS), > >>>>>> rather than > >>>>>> describing the RS. > >>>>>>>=20 > >>>>>>> John (as individual) > >>>>>>=20 > >>>>>> The metadata model is anchored by an element for the RS. This > >>>>>> recording > >>>>>> session contains 0 or more CS group each with 1 or more CS. > >>>>>> This is what > >>>>>> led to my comment that the metadata model describes an RS > >>>>>> rather than a > >>>>>> CS. > >>>>>>=20 > >>>>>> Cheers, > >>>>>> Charles > >>>>>>=20 > >>>>>>>=20 > >>>>>>>=20 > >>>>>>>>>=20 > >>>>>>>>> Section 4, suggest rewording as, "The section describes > >> each > >>>>>> element > >>>>>>>> of the metadata model, and the > >>>>>>>>> attributes of each element. This section also describes > >> how > >>>> the > >>>>>>>> different elements are associated." > >>>>>>>>>=20 > >>>>>>>>> Section 4.1, RecordingRequestorID is not really an ID, > > it > >>>>>>>> is more of a > >>>>>>>> type. I think > >>>>>>>>> RecordingRequestor is more appropriate. > >>>>>>>>>=20 > >>>>>>>>>=20 > >>>>>>>>> Agreed. We will update in the next revision > >> > >>>>>>>>>=20 > >>>>>>>>> That said, I think you also need a unique ID for the > >>>> Recording > >>>>>>>> Session, right? > >>>>>>>>> Please clarify whether you are interested in > >> AOR of > >>>> RS > >>>>>> or > >>>>>>>> just ID. In the model, Recording > >>>>>>>>> (1..*) is related to CSG (0..*) and there is no need of > >>>> separate > >>>>>>>> attribute for unique id. In the > >>>>>>>>> metadata format, URN UUID in CSG (group) & recording > >> exist > >>>>>>>> which helps > >>>>>>>> to visualize the association > >>>>>>>>> > >>>>>>>>=20 > >>>>>>>> I am assuming there is a need to distinguish one RS from > >>>>>>>> another RS, and > >>>>>>>> that is the reason I was recommending adding a unique ID. > >>>>>>>> This ID would > >>>>>>>> not be the RS AOR as that may not be unique. > >>>>>>>>=20 > >>>>>>>> Cheers, > >>>>>>>> Charles > >>>>>>>>=20 > >>>>>>>>> Section 4.2.1, replace "SRC (or MAY be SRS)" with "SRC > > or > >>>> SRS". > >>>>>>>>> Agreed. We will update in the next revision > >> > >>>>>>>>>=20 > >>>>>>>>> Section 4.3.2, why does a CS need two participants or > >> more? > >>>>>>>> What about > >>>>>>>> studio mode recording? > >>>>>>>>>=20 > >>>>>>>>> Section 4.4.1, what is participant type and what is its > >> use, > >>>> or > >>>>>> why > >>>>>>>> needed? > >>>>>>>>> This attribute has to be removed as per the > >>>>>> last interim > >>>>>>>> meeting. We will update in the next > >>>>>>>>> revision. > >>>>>>>>>=20 > >>>>>>>>> Section 4.5, I think Media Stream requires a unique ID > >>>> attribute > >>>>>> as > >>>>>>>> well. > >>>>>>>>> As mentioned above in the model draft, the > >>>> association > >>>>>>>> between CS and participant is shown. > >>>>>>>>> In terms of format draft, it is represented by URN UUID > >>>>>> > >>>>>>>>> Is the "Media Stream Reference" the SDP label attribute? > >>>>>>>>> Your understanding is correct > >>>>>>>>>=20 > >>>>>>>>>=20 > >>>>>>>>> Thanks, > >>>>>>>>> Charles > >>>>>>>>>=20 > >>>>>>>>>=20 > >>>>>>>>>=20 > >>>>>>>>> _______________________________________________ > >>>>>>>>> siprec mailing list > >>>>>>>>> siprec@ietf.org > >>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec > >>>>>>>> _______________________________________________ > >>>>>>>> siprec mailing list > >>>>>>>> siprec@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/siprec > >>>>>>>>=20 > >>>>>>=20 > >>>> _______________________________________________ > >>>> siprec mailing list > >>>> siprec@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/siprec > = From john.elwell@siemens-enterprise.com Wed Apr 6 05:44:02 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D34253A693E for ; Wed, 6 Apr 2011 05:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZgDPlReq0Kd for ; Wed, 6 Apr 2011 05:44:01 -0700 (PDT) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id D4E983A692E for ; Wed, 6 Apr 2011 05:44:00 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-4035506; Wed, 6 Apr 2011 14:45:43 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id D0E6823F0296; Wed, 6 Apr 2011 14:45:43 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 6 Apr 2011 14:45:43 +0200 From: "Elwell, John" To: "Ram Mohan R (rmohanr)" , Scott Orton , "Charles Eckel (eckelcu)" , "Parthasarathi R (partr)" , "siprec@ietf.org" Date: Wed, 6 Apr 2011 14:45:42 +0200 Thread-Topic: [siprec] comments on draft-ram-siprec-metadata-04 Thread-Index: Acvr6KoPYFMcjPlASk+pOtN532GUhgBO/qTgAD5pH0AAJpm4YABBRncAAAC5KqAAABl2UAAAlZ6wAAOH8AAAVJiJUADNFEeg Message-ID: References: <21866C7FE177A4449B9136B5B24B1B130BC011290A@EXMBXCLUS01.citservers.local> <21866C7FE177A4449B9136B5B24B1B130BC011294A@EXMBXCLUS01.citservers.local> <35BCE99A477D6A4986FB2216D8CF2CFD05DD8C0C@XMB-BGL-417.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD05DD8C0C@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] comments on draft-ram-siprec-metadata-04 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2011 12:44:02 -0000 I am OK in principle, but I wonder whether there really needs to be a relat= ionship between CSG and RS. Isn't that relationship an indirect relationshi= p via CS? John (as individual) =20 > -----Original Message----- > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com]=20 > Sent: 03 April 2011 18:13 > To: Scott Orton; Elwell, John; Charles Eckel (eckelcu);=20 > Parthasarathi R (partr); siprec@ietf.org > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 >=20 > Scott, >=20 > I am ok to make this change to the model. I would like to hear from > others if they have any issues in incorporating this change in the > model.=20 >=20 > The updated portion of the model will look like >=20 >=20 > +-------------------------------+ 1 > | Recording Session (RS) |---------------+ > +-------------------------------+ | > | 1..* |1..* | > | | | > | 0..* |0..* | > +--------------+ +-----------------+ | > |Communication | | Communication | 1 |=20 > | Session (CS) |----------| Session (CS) |---| > | Group |0..1 1..*| | | 0..* +----------+ > +--------------+ +-----------------+ |------|Extension | > 1| | 0..* |1..* | | Data | >=20 > | | 2..* |0..* | +----------+ >=20 > 0..*| > +---------+ > |Extension| =20 > | Data | > +---------+ >=20 > The only change in the association is : > A CS MUST be associated with zero or one CS-Group >=20 > Rest of the associations remain same. Further the association=20 > between CS > and RS remains same as what is between CS-Group and RS. >=20 > Comments ? >=20 > Regards, > Ram >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Scott Orton > > Sent: Friday, April 01, 2011 12:18 AM > > To: Elwell, John; Charles Eckel (eckelcu); Parthasarathi R (partr); > > siprec@ietf.org > > Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 > >=20 > > John, > > Thanks for the information. > >=20 > > In that case I would like to see the CS group be made optional. > > Rather than the CS pointing to the CS Group, I would like to suggest > > that the CS point to the RS and have the CS group stand=20 > alone where it > > would just have its own ID and then a list of CS ids that belong to > the > > group. > >=20 > > Scott > >=20 > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Thursday, March 31, 2011 11:50 AM > > To: Scott Orton; Charles Eckel (eckelcu); Parthasarathi R (partr); > > siprec@ietf.org > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > >=20 > > Scott, > >=20 > > Some folks wanted to be able to group related CSs together=20 > (e.g., a CS > > between a customer and an agent and a second CS resulting from the > > customer being transferred to a second agent). I will leave it to > those > > folks to add to this. > >=20 > > John (chair hat on) > >=20 > >=20 > > > -----Original Message----- > > > From: Scott Orton [mailto:sorton@broadsoft.com] > > > Sent: 31 March 2011 17:43 > > > To: Elwell, John; Charles Eckel (eckelcu); Parthasarathi R > > > (partr); siprec@ietf.org > > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > > > > > John, Charles, Partha, > > > I have a question. What is the purpose of the CS Group? I > > > do not see it adding anything to the metadata. To me it seems > > > that the whole purpose of the metadata is to describe the > > > recording session to the SRS. Looking at the requirements I > > > see 3 relationships that the spec is attempting to describe: > > > > > > A one to one relationship - one communication session to one > > > recording session > > > A one to many relationship - one communication session with > > > multiple Recording sessions > > > - one Recording session made up of > > > multiple communications sessions > > > > > > The current metadata format allows all of these and I do not > > > see what the group is adding. > > > > > > Regards, > > > Scott > > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > > > Sent: Thursday, March 31, 2011 11:30 AM > > > To: Charles Eckel (eckelcu); Parthasarathi R (partr); > siprec@ietf.org > > > Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 > > > > > > Charles, > > > > > > OK, I see how you got there, but really it describes the CSs > > > (and CS groups) that are being carried in the RS. Any ideas > > > how better to word it? > > > > > > John > > > > > > > -----Original Message----- > > > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > > Sent: 31 March 2011 17:11 > > > > To: Elwell, John; Parthasarathi R (partr); siprec@ietf.org > > > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > > > > > > > Hi John, > > > > > > > > Please see inline. > > > > > > > > > -----Original Message----- > > > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > > Sent: Wednesday, March 30, 2011 11:01 AM > > > > > To: Charles Eckel (eckelcu); Parthasarathi R (partr); > > > > siprec@ietf.org > > > > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: siprec-bounces@ietf.org > > > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Charles Eckel > > > > (eckelcu) > > > > > > Sent: 29 March 2011 15:38 > > > > > > To: Parthasarathi R (partr); siprec@ietf.org > > > > > > Subject: Re: [siprec] comments on=20 > draft-ram-siprec-metadata-04 > > > > > > > > > > > > Hi Partha, > > > > > > > > > > > > Thanks for your response. This addresses all of my concerns. > > > > > > Please see > > > > > > one additional clarification inline. > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Parthasarathi R (partr) > > > > > > > Sent: Tuesday, March 29, 2011 10:31 AM > > > > > > > To: Charles Eckel (eckelcu); siprec@ietf.org > > > > > > > Subject: RE: [siprec] comments on=20 > draft-ram-siprec-metadata- > > 04 > > > > > > > > > > > > > > Charles, > > > > > > > > > > > > > > Thanks for review the document. Please read inline. > > > > > > > > > > > > > > Thanks > > > > > > > Partha > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: siprec-bounces@ietf.org > > > > [mailto:siprec-bounces@ietf.org] On > > > > > > Behalf Of Charles Eckel (eckelcu) > > > > > > > Sent: Sunday, March 27, 2011 12:35 AM > > > > > > > To: siprec@ietf.org > > > > > > > Subject: [siprec] comments on draft-ram-siprec-metadata-04 > > > > > > > > > > > > > > I gave the draft and read and have the following comments. > > > > > > > > > > > > > > Section 3. Think the metadata describes the recording > > > > > > session, not the > > > > > > communication session. Replace > > > > > > > "metamodel" with "metadata model", and "MAY be conveyed in > > > > Recording > > > > > > Session" with "MAY be conveyed > > > > > > > within the Recording Session", and "time a change > > > occurred by be > > > > > > assumed" with "time a change occurred > > > > > > > may be assumed". > > > > > [JRE] I am not sure exactly what text Charles was > > > commenting on, but > > > > in my opinion metadata describes > > > > > a CS (and how media streams in the RS relate to that CS), > > > > rather than > > > > describing the RS. > > > > > > > > > > John (as individual) > > > > > > > > The metadata model is anchored by an element for the RS. This > > > > recording > > > > session contains 0 or more CS group each with 1 or more CS. > > > > This is what > > > > led to my comment that the metadata model describes an RS > > > > rather than a > > > > CS. > > > > > > > > Cheers, > > > > Charles > > > > > > > > > > > > > > > > > > > > > > > > > > > > Section 4, suggest rewording as, "The section=20 > describes each > > > > element > > > > > > of the metadata model, and the > > > > > > > attributes of each element. This section also > > > describes how the > > > > > > different elements are associated." > > > > > > > > > > > > > > Section 4.1, RecordingRequestorID is not really an ID, it > > > > > > is more of a > > > > > > type. I think > > > > > > > RecordingRequestor is more appropriate. > > > > > > > > > > > > > > > > > > > > > Agreed. We will update in the next revision > > > > > > > > > > > > > > > That said, I think you also need a unique ID for the > > > Recording > > > > > > Session, right? > > > > > > > Please clarify whether you are interested > > > in AOR of RS > > > > or > > > > > > just ID. In the model, Recording > > > > > > > (1..*) is related to CSG (0..*) and there is no need > > > of separate > > > > > > attribute for unique id. In the > > > > > > > metadata format, URN UUID in CSG (group) & recording exist > > > > > > which helps > > > > > > to visualize the association > > > > > > > > > > > > > > > > > > > I am assuming there is a need to distinguish one RS from > > > > > > another RS, and > > > > > > that is the reason I was recommending adding a unique ID. > > > > > > This ID would > > > > > > not be the RS AOR as that may not be unique. > > > > > > > > > > > > Cheers, > > > > > > Charles > > > > > > > > > > > > > Section 4.2.1, replace "SRC (or MAY be SRS)" with > > > "SRC or SRS". > > > > > > > Agreed. We will update in the next revision > > > > > > > > > > > > > > > Section 4.3.2, why does a CS need two=20 > participants or more? > > > > > > What about > > > > > > studio mode recording? > > > > > > > > > > > > > > Section 4.4.1, what is participant type and what is > > > its use, or > > > > why > > > > > > needed? > > > > > > > This attribute has to be removed as per the > > > > last interim > > > > > > meeting. We will update in the next > > > > > > > revision. > > > > > > > > > > > > > > Section 4.5, I think Media Stream requires a unique > > > ID attribute > > > > as > > > > > > well. > > > > > > > As mentioned above in the model draft, the > > > association > > > > > > between CS and participant is shown. > > > > > > > In terms of format draft, it is represented by URN UUID > > > > > > > > > > > Is the "Media Stream Reference" the SDP label attribute? > > > > > > > Your understanding is correct > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > Charles > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > siprec mailing list > > > > > > > siprec@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > _______________________________________________ > > > > > > siprec mailing list > > > > > > siprec@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > > > > > > _______________________________________________ > > > siprec mailing 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 Apr 6 05:48:03 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF7563A6935 for ; Wed, 6 Apr 2011 05:48:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LoJm8xrY1GPw for ; Wed, 6 Apr 2011 05:48:01 -0700 (PDT) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 8936A3A67A1 for ; Wed, 6 Apr 2011 05:48:00 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-4035572; Wed, 6 Apr 2011 14:49:43 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id DC7591EB82B5; Wed, 6 Apr 2011 14:49:43 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 6 Apr 2011 14:49:43 +0200 From: "Elwell, John" To: "Parthasarathi R (partr)" , Leon Portman , "Charles Eckel (eckelcu)" , "Hutton, Andrew" , "Ram Mohan R (rmohanr)" Date: Wed, 6 Apr 2011 14:49:41 +0200 Thread-Topic: [siprec] Dialog state in the CS block of metadatamodel[wasRE:Progressing the architecture document] Thread-Index: AcvY+qyFanmfNOL5Qlq3osURZ2w4qAJbzb1IACUhGWAAGstGAwFGdfdAAAXbWKAAA+XmQAAAGhNQABG/CmwAHSHXEAAZDuOFABzjR+AAVixTcAAUeoQQAAAj4EAAHgihsAAClqhQAAXOdEAADtUDkAAjidVAAABgrFAAAo/hIAAdpARgAAc8P9ABkDDsUAACY20AAAipdrA= Message-ID: References: <101C6067BEC68246B0C3F6843BCCC1E30B61DB3370@MCHP058A.global-ad.net><07465C1D981ABC41A344374066AE1A2C38A960C8F0@TLVMBX01.nice.com><101C6067BEC68246B0C3F6843BCCC1E30B61E96D11@MCHP058A.global-ad.net><07465C1D981ABC41A344374066AE1A2C38A960C9CA@TLVMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD05CC9E38@XMB-BGL-417.cisco.com> <07465C1D981ABC41A344374066AE1A2C38AB466335@TLVMBX01.nice.com> <07465C1D981ABC41A344374066AE1A2C38AB46639F@TLVMBX01.nice.com> <07465C1D981ABC41A344374066AE1A2C38AB466603@TLVMBX01.nice.com> <101C6067BEC68246B0C3F6843BCCC1E30B6D1ED8E0@MCHP058A.global-ad.net> <07465C1D981ABC41A344374066AE1A2C38AB466C1B@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] Dialog state in the CS block of metadatamodel[wasRE:Progressing the architecture document] X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2011 12:48:03 -0000 Partha, I don't see the connection between the discussion on session state and the = discussion on early versus regular media. It seems to me that if we want to= tag media as coming from an automaton, this would be an attribute of the p= articipant object, not the session object. However, I am not arguing in favour of adding this attribute - just pointin= g out what it would mean. John (as individual) > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > Sent: 06 April 2011 10:02 > To: Elwell, John; Leon Portman; Charles Eckel (eckelcu); > Hutton, Andrew; Ram Mohan R (rmohanr) > Cc: siprec@ietf.org > Subject: RE: [siprec] Dialog state in the CS block of > metadatamodel[wasRE:Progressing the architecture document] > > John, > > As we agreed upon on IETF-80 SIPREC meeting, session state attribute > will not be included as part of the metadata model & format. > In case any > requires this attribute, Let them speak for it. > > I really don't very sure whether it is required to pass feature tag in > SIPREC Metadata. > > Thanks > Partha > > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Wednesday, April 06, 2011 1:06 PM > To: Parthasarathi R (partr); Leon Portman; Charles Eckel (eckelcu); > Hutton, Andrew; Ram Mohan R (rmohanr) > Cc: siprec@ietf.org > Subject: RE: [siprec] Dialog state in the CS block of > metadatamodel[wasRE:Progressing the architecture document] > > So you are saying we might want to distinguish between media generated > automatically and media generated by a human? I guess the only SIP > mechanism for determining this is that "Automata" media feature tag in > RFC 3840, but I don't know how widely implemented it is. > > John > > > -----Original Message----- > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > Sent: 29 March 2011 09:50 > > To: Elwell, John; Leon Portman; Charles Eckel (eckelcu); Hutton, > > Andrew; Ram Mohan R (rmohanr) > > Cc: siprec@ietf.org > > Subject: RE: [siprec] Dialog state in the CS block of > > metadatamodel[wasRE:Progressing the architecture document] > > > > John, > > > > I agree with you in case of media server participant sends > "ringback" > > media stream during the early dialog and later stage, the callee > > participant sends actual stream of the session using another > > offer/answer exchange. It is also possible that callee sends > > "ringback" > > media stream wherein there is no difference between early > or regular > > media in terms of metadata information. > > > > Having said that, it "may" or "may not" be matter whether > the devices > > of the participant automatically creates the media stream or > > participant actually creates media stream. > > > > Thanks > > Partha > > > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Tuesday, March 29, 2011 10:39 AM > > To: Parthasarathi R (partr); Leon Portman; Charles Eckel (eckelcu); > > Hutton, Andrew; Ram Mohan R (rmohanr) > > Cc: siprec@ietf.org > > Subject: RE: [siprec] Dialog state in the CS block of > > metadatamodel[wasRE:Progressing the architecture document] > > > > Partha, > > > > I think the real distinction you wish to make is between > media coming > > from a particular participant (associated with the UAS) and media > > coming from some other entity (e.g., media server). In my view the > > latter case, if we choose to record it, comes from a different > > "participant". It has nothing to do with whether it is > deemed early or > > > regular from a SIP dialog perspective. > > > > John (as individual) > > > > > > > -----Original Message----- > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > Sent: 28 March 2011 17:53 > > > To: Leon Portman; Charles Eckel (eckelcu); Hutton, > Andrew; Elwell, > > > John; Ram Mohan R (rmohanr) > > > Cc: siprec@ietf.org > > > Subject: RE: [siprec] Dialog state in the CS block of > > > metadatamodel[wasRE:Progressing the architecture document] > > > > > > > > > The question of "session" state is raised in my mind mainly to > > > distinguish between early media (Media before session > > establishment) > > > from normal media. Without the information in SIPREC > metadata, the > > > early media will be associated with UAS participant's > media stream. > > > I'm interested in knowing whether SIPREC solution has to > > differentiate > > > > > between early media from normal media. > > > > > > As per John below mail, there is no need to differentiate > > as per the > > > current requirement. If most of the folks feel so, I'm fine > > with not > > > including "session state" in metadata. > > > > > > Thanks > > > Partha > > > > > > -----Original Message----- > > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > > Sent: Monday, March 28, 2011 7:16 PM > > > To: Charles Eckel (eckelcu); Hutton, Andrew; Elwell, John; > > > Parthasarathi R (partr); Ram Mohan R (rmohanr) > > > Cc: siprec@ietf.org > > > Subject: RE: [siprec] Dialog state in the CS block of > > > metadatamodel[wasRE:Progressing the architecture document] > > > > > > Charles Hi > > > > > > Just to make clear, I don't think SRS should receive dialog level > > > state events about all CS dialogs. I think that we should > > to support > > > reporting high level session events. > > > I understand the complexity of that and Ok to keep it > open or next > > > phase extensions > > > > > > Leon > > > > > > -----Original Message----- > > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > Sent: Monday, March 28, 2011 3:35 PM > > > To: Hutton, Andrew; Elwell, John; Leon Portman; Parthasarathi R > > > (partr); Ram Mohan R (rmohanr) > > > Cc: siprec@ietf.org > > > Subject: RE: [siprec] Dialog state in the CS block of > > > metadatamodel[wasRE:Progressing the architecture document] > > > > > > I agree with this approach. Hopefully Leon and others > that saw the > > > need for this state information can confirm if it works for them. > > > > > > Cheers, > > > Charles > > > > > > > -----Original Message----- > > > > From: Hutton, Andrew > [mailto:andrew.hutton@siemens-enterprise.com] > > > > Sent: Monday, March 28, 2011 9:13 AM > > > > To: Elwell, John; Leon Portman; Charles Eckel (eckelcu); > > > Parthasarathi > > > R (partr); Ram Mohan R > > > > (rmohanr) > > > > Cc: siprec@ietf.org > > > > Subject: RE: [siprec] Dialog state in the CS block of > > > metadatamodel[wasRE:Progressing the architecture > > > > document] > > > > > > > > Hi, > > > > > > > > The draft-ietf-siprec-architecture has from the very > > > beginning listed > > > dialog state as an example of > > > > what would be included in metadata which is why I raised > > > the question. > > > > > > > > However it is true to say this was put in the > > architecture document > > > before we had firmed up the > > > > requirements or starting any indepth work on metadata so I could > > > accept that the architecture draft > > > > simply got this wrong from the start and it maybe should > > be removed. > > > We could of course take the view > > > > that if dialog events are important then the SRS could > > subscribe to > > > the dialog event package at the > > > > SRC and SIPREC does not need to touch this. > > > > > > > > I don't think we can allow SIPREC metadata to extend as far as > > > reporting everything that happens to > > > > the CS including how it is linked to other CS's and what > > > services are > > > used on the CS (E.g. types of > > > > transfer etc.). This would quickly get very difficult to > > > define and we > > > would probably fail. > > > > > > > > I would prefer to not report this state information in > > metadata than > > > open up the possibility of adding > > > > lots of complexity. > > > > > > > > Regards > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Elwell, John > > > > > Sent: 27 March 2011 14:50 > > > > > To: Leon Portman; Charles Eckel (eckelcu); Parthasarathi > > > R (partr); > > > > > Ram Mohan R (rmohanr); Hutton, Andrew > > > > > Cc: siprec@ietf.org > > > > > Subject: RE: [siprec] Dialog state in the CS block of > > > > > metadatamodel[wasRE:Progressing the architecture document] > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > > > > > Sent: 27 March 2011 11:48 > > > > > > To: Charles Eckel (eckelcu); Elwell, John; Parthasarathi R > > > > > > (partr); Ram Mohan R (rmohanr); Hutton, Andrew > > > > > > Cc: siprec@ietf.org > > > > > > Subject: RE: [siprec] Dialog state in the CS block of > > > > > > metadatamodel[wasRE:Progressing the architecture document] > > > > > > > > > > > > Charles Hi > > > > > > > > > > > > Yes, it will be good to discuss it face to face. > > > > > > > > > > > > Just little background for such requirements. Today, > > especially > > > > > > for contact centers, it is important for SRS to capture the > > > > > > information how long customer was waiting for agent to > > > answer the > > > > > > call, which party hang up, how long was the hold time, > > > if it was > > > > > > blind transfer or consultation transfer. This information > > > > > > important both from quality management point of view > > > and customer > > > > > > experience point of view. > > > > > [JRE] (as chair) I think the group needs to consider > > > whether this is > > > > > > > > within scope. Looking at the requirements, we have: > > > > > "REQ-012 The mechanism MUST provide the SRS with metadata > > > describing > > > > > CSs that are being recorded, including the media > > being used and > > > the > > > > > identities of parties involved." > > > > > If we are not recording the session while the caller is > > > waiting to > > > > > be answered, it seems we perhaps don't have a requirement for > > > > > metadata about that. This seems to be more about call detail > > > > > recording (CDR) rather than session recording. We can by > > > all means > > > > > have this discussion, but I am concerned about scope creep. > > > > > > > > > > > It is important also from compliance point of view to > > detect if > > > > > > somebody actually received the media stream or still was in > > > > > > pending state or media stream was disconnected. > > > > > [JRE] (as individual) I agree we should show a participant as > > > > > receiving media only if the SRC believes media is > > actually being > > > > > sent to that participant (even then, there can be no > > > guarantee it is > > > > > > > > received, e.g., because NAT or firewall traversal isn't > > > functioning > > > > > properly, severe packet loss, speaker volume is muted, > > > etc..). But I > > > > > > > > have doubts whether it is necessarily to try to account > > > for periods > > > > > when the SRC knows a participant is not receiving media > > > by saying it > > > > > > > > is because of alerting, hold or whatever. > > > > > > > > > > John > > > > > > > > > > > > > > > > > > > > > > Leon > > > > > > > > > > > > -----Original Message----- > > > > > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > > > > Sent: Sunday, March 27, 2011 11:35 AM > > > > > > To: Leon Portman; Elwell, John; Parthasarathi R > > > (partr); Ram Mohan > > > > > > > > > R (rmohanr); Hutton, Andrew > > > > > > Cc: siprec@ietf.org > > > > > > Subject: RE: [siprec] Dialog state in the CS block of > > > > > > metadatamodel[wasRE:Progressing the architecture document] > > > > > > > > > > > > Hi Leon, > > > > > > > > > > > > Thank you for your patience in trying to explain > this to me; > > > > > > however, I still am not able to understand why the SRS > > > might need > > > > > > to know this information, or what it would do with it. > > > > > > Is it that you need to know when a given participant > > > was receiving > > > > > > > > > the recorded media and when it was not? If so, I do > not think > > > > > > dialog state is sufficient. Is there some other > > requirement or > > > > > > functionality addressed by the SRS having such information? > > > > > > Perhaps it is easier to discuss in person at the > > > breakfast meeting > > > > > > > > > Wednesday or during the working group session. > > > > > > > > > > > > Cheers, > > > > > > Charles > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > > > > > > Sent: Saturday, March 26, 2011 8:15 PM > > > > > > > To: Charles Eckel (eckelcu); Elwell, John; Parthasarathi > > > > > R (partr); > > > > > > Ram Mohan R (rmohanr); Hutton, > > > > > > > Andrew > > > > > > > Cc: siprec@ietf.org > > > > > > > Subject: RE: [siprec] Dialog state in the CS block of > > > > > > metadatamodel[wasRE:Progressing the architecture > > > > > > > document] > > > > > > > > > > > > > > Charles Hi > > > > > > > > > > > > > > Without participant session state, SRS will know only when > > > > > > participant > > > > > > is part of the session and will > > > > > > > not know about intermediate states like ringing, > > retrying etc. > > > > > > > I know that we have media stream information per > > > > > participant but not > > > > > > sure that it is enough. > > > > > > > > > > > > > > Leon > > > > > > > -----Original Message----- > > > > > > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > > > > > Sent: Saturday, March 26, 2011 9:07 PM > > > > > > > To: Leon Portman; Elwell, John; Parthasarathi R (partr); > > > > > Ram Mohan R > > > > > > (rmohanr); Hutton, Andrew > > > > > > > Cc: siprec@ietf.org > > > > > > > Subject: RE: [siprec] Dialog state in the CS block of > > > > > metadatamodel > > > > > > [wasRE:Progressing the > > > > > > > architecture document] > > > > > > > > > > > > > > Hi Leon, > > > > > > > > > > > > > > I am still having a hard time understanding why we need > > > > > the session > > > > > > state information per CS > > > > > > > participant? Why is this required, who uses it, and how? > > > > > > > > > > > > > > Thanks, > > > > > > > Charles > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: siprec-bounces@ietf.org > > > > > [mailto:siprec-bounces@ietf.org] On > > > > > > > Behalf Of Leon Portman > > > > > > > > Sent: Saturday, March 26, 2011 10:31 AM > > > > > > > > To: Elwell, John; Parthasarathi R (partr); Ram Mohan R > > > > > (rmohanr); > > > > > > > Hutton, Andrew > > > > > > > > Cc: siprec@ietf.org > > > > > > > > Subject: Re: [siprec] Dialog state in the CS block of > > > > > > metadatamodel > > > > > > > [wasRE:Progressing the > > > > > > > > architecture document] > > > > > > > > > > > > > > > > John Hello > > > > > > > > > > > > > > > > I agree that SRS (and its application clients) > interested > > > > > > in SESSION > > > > > > > level events and not underlying > > > > > > > > DIALOG events. However we do need to support reporting > > > > > > session state > > > > > > > information per CS participant > > > > > > > > that sometimes equals to dialog level and sometimes not. > > > > > > > > > > > > > > > > We could have define more application level state > > > events like > > > > > > instead > > > > > > > of TRYING - > RINGING etc. > > > > > > > > However they could be domain specific. > > > > > > > > > > > > > > > > Leon > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Elwell, John > > > [mailto:john.elwell@siemens-enterprise.com] > > > > > > > > Sent: Thursday, March 24, 2011 6:34 PM > > > > > > > > To: Parthasarathi R (partr); Ram Mohan R (rmohanr); > > > > > Leon Portman; > > > > > > > Hutton, Andrew > > > > > > > > Cc: siprec@ietf.org > > > > > > > > Subject: RE: [siprec] Dialog state in the CS block of > > > > > > metadata model > > > > > > > [wasRE:Progressing the > > > > > > > > architecture document] > > > > > > > > > > > > > > > > This discussion gives me some concerns, echoing to some > > > > > > extent what > > > > > > > Ram is saying. > > > > > > > > > > > > > > > > SIPREC is about session recording, where a > session is the > > > > > > information > > > > > > > exchanged between participants > > > > > > > > in a CS (the media streams) plus metadata. The > > > metadata should > > > > > > provide > > > > > > > additional information about > > > > > > > > the CS. This means information about the communication > > > > > > SESSION, not > > > > > > > about the SIP dialog that is used > > > > > > > > to control that session. With this in mind, consider > > > > > the following > > > > > > > points, some of which have already > > > > > > > > been raised: > > > > > > > > > > > > > > > > 1. There may be more than one SIP dialog involved if the > > > > > > SRC is at a > > > > > > > B2BUA or conference focus. > > > > > > > > > > > > > > > > 2. Does the CS necessarily need to be controlled > > by SIP? For > > > > > > example, > > > > > > > it could be a PSTN call, an RTC- > > > > > > > > Web call or a Jingle call. None of these preclude using > > > > > > SIP for the > > > > > > RS > > > > > > > (that is what the charter of > > > > > > > > SIPREC is all about - a SIP-based RS). > > > > > > > > > > > > > > > > 3. Somebody retrieving and playing back a recorded > > > CS will be > > > > > > > interested in session-related events > > > > > > > > like participants leaving and joining > (including the first > > > > > > > participants joining at the start of the CS > > > > > > > > and the last participants leaving a the end of the > > > CS), media > > > > > > streams > > > > > > > starting and ending and > > > > > > > > participants starting or stopping receipt of a > > media stream. > > > In > > > > > > other > > > > > > > words, changes of SESSION state, > > > > > > > > not dialog state. > > > > > > > > > > > > > > > > 4. Some of the SIP dialog states just don't seem > > > relevant. The > > > > > > > distinction between early dialog and > > > > > > > > full dialog in SIP does not necessarily > > corresponding to any > > > > > > > meaningful state change of the session. > > > > > > > > For example, A makes a call to B and B answers and > > > > > starts sending > > > > > > > media. A receives and renders media > > > > > > > > (perhaps it has already received SDP answer, allowing > > > > > it to verify > > > > > > the > > > > > > > source of the media). Then A > > > > > > > > receives the 200 OK (transitioning from an early dialog > > > > > to a full > > > > > > > dialog) and continues to receive > > > > > > > > media. So although there is a dialog state > > change, there is > > > not > > > > > > really > > > > > > > a session state change. > > > > > > > > > > > > > > > > The bit about dialog state in the architecture > > > draft is, in my > > > > > > > opinion, a legacy from some earlier > > > > > > > > discussions, before we started having the metadata > > > > > discussions. I > > > > > > > think the metadata discussions have > > > > > > > > taken us in the right direction. > > > > > > > > > > > > > > > > John (as individual) > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: siprec-bounces@ietf.org > > > > > > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of > > > Parthasarathi > > > R > > > > > > > (partr) > > > > > > > > > Sent: 24 March 2011 02:36 > > > > > > > > > To: Ram Mohan R (rmohanr); Leon Portman; > Hutton, Andrew > > > > > > > > > Cc: siprec@ietf.org > > > > > > > > > Subject: Re: [siprec] Dialog state in the CS block of > > > metadata > > > > > > model > > > > > > > > > [wasRE:Progressing the architecture document] > > > > > > > > > > > > > > > > > > Ram, > > > > > > > > > > > > > > > > > > Please read inline. > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > Partha > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > > > > > > > > > From: Ram Mohan R (rmohanr) > > > > > > > > > Sent: Wed 3/23/2011 7:59 PM > > > > > > > > > To: Parthasarathi R (partr); Leon Portman; > > Hutton, Andrew > > > > > > > > > Cc: siprec@ietf.org > > > > > > > > > Subject: RE: [siprec] Dialog state in the CS block of > > > metadata > > > > > > model > > > > > > > > > [wasRE:Progressing the architecture document] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I am still trying to understand what is the > > > > > significance of this > > > > > > > > > attribute w.r.t CS. Are we saying the attribute > > represents > > > the > > > > > > state > > > > > > > > > of CS ? > > > > > > > > > > > > > > > > > > Note that CS need not be one dialog. > > > > > > > > > > > > > > > > > > The attribute is to show the state of CS > > > > > > only. As it is > > > > > > > not > > > > > > > > > single dialog, I have mentioned as session > > state attribute > > > > > > > > > > > > > > > > > > > > > > > > For cases like Conference where there may be different > > > > > > participants, > > > > > > > > > if SRC happens to be Focus how do you derive/what is > > > "session > > > > > > state" > > > > > > > ? > > > > > > > > > > > > > > > > > > I really don't know whether it is generic. My > > > thought > > > > > > > > > processing of session state for conference is > > as follows: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 1) First participant of conference early media (ivr > > > > > play) may be > > > > > > > > > considered as "early" state of session. > > > > > > > > > > > > > > > > > > 2) The session state is chaged to confirmed > in case any > > > > > > one of the > > > > > > > > > participant joined in the conference. > > > > > > > > > > > > > > > > > > 3) The session state is move to terminated > when the last > > > > > > participant > > > > > > > > > moved out of the conference. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Please let me know in case other way to represent the > > > session > > > > > > state > > > > > > > of > > > > > > > > > conference > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > For cases where B2BUA acts as SRC what is > > > "session state" ? > > > > > > > > > > > > > > > > > > It looks straight forward for me. In > > B2BUA case , > > > > > > > > > > > > > > > > > > 1) The stage where in two party is not > connected, it is > > > > > > considered > > > > > > > as > > > > > > > > > early state. > > > > > > > > > > > > > > > > > > 2) when both are connected, it is confirmed state > > > > > > > > > > > > > > > > > > 3) In case of BYE received from any one of the party, > > > > > then CS is > > > > > > > > > considered as terminated state > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Please note that this is applicable for 3PCC as well. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ram > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: siprec-bounces@ietf.org > > > > > > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of > > > Parthasarathi > > > R > > > > > > > (partr) > > > > > > > > > Sent: Wednesday, March 23, 2011 6:13 AM > > > > > > > > > To: Leon Portman; Hutton, Andrew > > > > > > > > > Cc: siprec@ietf.org > > > > > > > > > Subject: Re: [siprec] Dialog state in the CS block of > > > metadata > > > > > > model > > > > > > > > > [wasRE:Progressing the architecture document] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Leon, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Shall we have optional "event" attribute to > indicate the > > > state > > > > > > > change > > > > > > > > > which is similar to "event" attribute in RFC 4235. > > > > > The "event" > > > > > > will > > > > > > > > > include the following: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 1) cancelled > > > > > > > > > > > > > > > > > > 2) rejected > > > > > > > > > > > > > > > > > > 3) replaced > > > > > > > > > > > > > > > > > > 4) bye > > > > > > > > > > > > > > > > > > 5) error > > > > > > > > > > > > > > > > > > 6) timeout > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > Partha > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > > > > > > > > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > > > > > > > > Sent: Tue 3/22/2011 9:37 PM > > > > > > > > > To: Hutton, Andrew; Parthasarathi R (partr) > > > > > > > > > Cc: siprec@ietf.org > > > > > > > > > Subject: RE: Dialog state in the CS block of metadata > > > > > model [was > > > > > > > > > RE:Progressing the architecture document] > > > > > > > > > > > > > > > > > > It can be either application level error or dialog > > > > > > level errors - > > > > > > > like > > > > > > > > > timeout or failures. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Leon > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: Hutton, Andrew > > > > > > [mailto:andrew.hutton@siemens-enterprise.com] > > > > > > > > > Sent: Tuesday, March 22, 2011 6:02 PM > > > > > > > > > To: Leon Portman; Parthasarathi R (partr) > > > > > > > > > Cc: siprec@ietf.org > > > > > > > > > Subject: RE: Dialog state in the CS block of metadata > > > > > model [was > > > > > > RE: > > > > > > > > > Progressing the architecture document] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > What would it be used for? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > > > > > > > > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > > > > > > > > Sent: 22 March 2011 14:11 > > > > > > > > > To: Parthasarathi R (partr); Hutton, Andrew > > > > > > > > > Cc: siprec@ietf.org > > > > > > > > > Subject: RE: Dialog state in the CS block > of metadata > > > > > > model [was > > > > > > > RE: > > > > > > > > > Progressing the architecture document] > > > > > > > > > > > > > > > > > > Should we have error state as well? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Leon > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: siprec-bounces@ietf.org > > > > > > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of > > > Parthasarathi > > > R > > > > > > > (partr) > > > > > > > > > Sent: Tuesday, March 22, 2011 3:33 PM > > > > > > > > > To: Parthasarathi R (partr); Hutton, Andrew > > > > > > > > > Cc: siprec@ietf.org > > > > > > > > > Subject: [siprec] Dialog state in the CS block of > > > > > > metadata model > > > > > > > [was > > > > > > > > > RE: Progressing the architecture document] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The architecture document proposes to have > > > > > > dialog/session state > > > > > > > in > > > > > > > > > Metadata model. To achieve this, "session state" > > > > > > attribute has to > > > > > > be > > > > > > > > > added in the CS block of Metadata model. The possible > > > > > values for > > > > > > > > > session state are > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 1) Trying > > > > > > > > > > > > > > > > > > 2) Proceeding > > > > > > > > > > > > > > > > > > 3) Early > > > > > > > > > > > > > > > > > > 4) Confirmed > > > > > > > > > > > > > > > > > > 5) Terminated > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Please let me know in case any objection to add > > > > > this attribute > > > > > > > in > > > > > > > > > Metadata model. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > Partha > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > > > > > > > > > From: Parthasarathi R (partr) > > > > > > > > > Sent: Wednesday, March 16, 2011 5:40 AM > > > > > > > > > To: Hutton, Andrew > > > > > > > > > Cc: Elwell, John; siprec@ietf.org > > > > > > > > > Subject: RE: Progressing the architecture document > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: siprec-bounces@ietf.org > > > > > > > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of > > > > > > Parthasarathi R > > > > > > > > > (partr) > > > > > > > > > > Sent: 14 March 2011 17:05 > > > > > > > > > > To: Elwell, John; siprec@ietf.org > > > > > > > > > > Subject: Re: [siprec] Progressing the > > > > > architecture document > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Sec 4.3.1 whether 3rd bullet is required? > > > > > > > > > > > > > > > > > > > > > > > > > > > > [AndyH]I assume it is as for example I assume > > > it would be > > > > > > > necessary > > > > > > > > > to record early-media and update the SRS when the > > > > > dialog changes > > > > > > to > > > > > > > > > the confirmed or terminated state. Does not > > seem to be in > > > the > > > > > > > metadata > > > > > > > > > draft though. In the end I will either remove > > > these bullets > > > or > > > > > > align > > > > > > > > > with the metadata draft. > > > > > > > > > It is a good point. Dialog state shall be > > > > > > added as one > > > > > > > of > > > > > > > > > the optional attribute in CS metadata block with > > > > > > default value as > > > > > > > > > mid-dialog. This helps to differentiate between > > > early dialog > > > > > > > > > (ringback) vs mid-dialog (normal > > > > > > > > > conversation) in recording. In case of no > > > objection for this > > > > > > > attribute > > > > > > > > > in metadata model, we will add it. We will work > > > out metadata > > > > > > format > > > > > > > > > once the consensus occurs for metadata model. > > > > > > > > > In case required, we will span separate mail thread to > > > > > > close this > > > > > > > > > issue > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > siprec mailing list > > > > > > > > siprec@ietf.org > > > > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > > > > > > > > > > From iesg-secretary@ietf.org Wed Apr 6 05:50:24 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01F2F3A6932; Wed, 6 Apr 2011 05:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6+bXoCr3OJhl; Wed, 6 Apr 2011 05:50:21 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07D3E3A67A1; Wed, 6 Apr 2011 05:50:21 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.14 Message-ID: <20110406125020.17538.70016.idtracker@localhost> Date: Wed, 06 Apr 2011 05:50:20 -0700 Cc: siprec@ietf.org Subject: [siprec] Last Call: (Use Cases and Requirements for SIP-based Media Recording (SIPREC)) to Informational RFC X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 12:50:24 -0000 The IESG has received a request from the SIP Recording WG (siprec) to consider the following document: - 'Use Cases and Requirements for SIP-based Media Recording (SIPREC)' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-04-20. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-siprec-req/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-siprec-req/ No IPR declarations have been submitted directly on this I-D. From john.elwell@siemens-enterprise.com Wed Apr 6 05:55:53 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88C0D28C106 for ; Wed, 6 Apr 2011 05:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.235 X-Spam-Level: X-Spam-Status: No, score=-102.235 tagged_above=-999 required=5 tests=[AWL=-0.236, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W9udtO0Ipz5J for ; Wed, 6 Apr 2011 05:55:52 -0700 (PDT) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id BC08B28C0FC for ; Wed, 6 Apr 2011 05:55:51 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-4035734; Wed, 6 Apr 2011 14:57:34 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id E02081EB82B4; Wed, 6 Apr 2011 14:57:34 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 6 Apr 2011 14:57:34 +0200 From: "Elwell, John" To: "Parthasarathi R (partr)" , Hadriel Kaplan Date: Wed, 6 Apr 2011 14:57:33 +0200 Thread-Topic: [siprec] extensionData in XML Thread-Index: AcvxNFr/P3TGgoIBQ/abk6KeJk2EGwA8rJ/pAINJrbAAAUHXgAAIDMJQ 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 Cc: "siprec@ietf.org" , "Jain, Rajnish" , "Peter Saint-Andre \(psaintan\)" Subject: Re: [siprec] extensionData in XML X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2011 12:55:53 -0000 Yes, I would be keen to hear Peter's or other opinions, but one other point= . One of the properties of XML is that it is human-readable. Having extensi= on data as a child element of the element representing the object to which = it applies seems, in my opinion, to make it more readable. Having extension= data as a separate element, with a link to the element to which it applies= , seems hard for a human reader, particularly if the link is a long, random= string. John (as individual) =20 > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com]=20 > Sent: 06 April 2011 10:16 > To: Elwell, John; Hadriel Kaplan > Cc: siprec@ietf.org; Jain, Rajnish; Peter Saint-Andre (psaintan) > Subject: RE: [siprec] extensionData in XML >=20 > John, >=20 > Please read inline >=20 > Thanks > Partha=20 >=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > Sent: Wednesday, April 06, 2011 2:02 PM > To: Parthasarathi R (partr); Hadriel Kaplan > Cc: siprec@ietf.org; Jain, Rajnish > Subject: RE: [siprec] extensionData in XML >=20 > I already posted on this topic on the other thread. Partha=20 > states below > an additional motivation for handling extension data in the way > specified in the current I-D. My counter argument is that anyone > specifying particular extension data could specify the expected > behaviour when extension data is present in an object and then absent > when that object is updated. For some types of metadata it=20 > could be that > absence means it no longer applies, and for other types of metadata it > could be that absence means it has not changed.=20 >=20 > Currently, metadata format draft XML element is written with > the basics that "it is no longer applies" in case specific element is > absent in the update. The question is how the information of > extensiondata absence means "it is no longer applies" or "it has not > changed" has to be passed between SRC and SRS. Here, there is=20 > a need of > common understanding between SRC and SRS or else the=20 > information will be > misunderstand even though both parties understand the specific > extension. >=20 > The current extensiondata is taken the route of all other=20 > metadata block > XML element definition. There may be better way to represent in > extensiondata XML element apart from creating new metadata block with > URN UUID. I'm including Peter for his advise on XML front. =20 >=20 > The latter approach would avoid the need for repeating large=20 > quantities > of metadata each time there is a minor change to an object. >=20 > John (as individual) >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi=20 > R (partr) > > Sent: 03 April 2011 19:46 > > To: Hadriel Kaplan > > Cc: siprec@ietf.org; Jain, Rajnish > > Subject: Re: [siprec] extensionData in XML > >=20 > > Hadriel, > > =20 > > I guess we have common understaning to the extend that the=20 > intention=20 > > is to send some extensiondata (Unknown) attribute by SRC=20 > which may or=20 > > may not understand by SRS and also for the usage of xs:any as the=20 > > solution. Few stuff are missing in yours proposal w.r.t=20 > partial data=20 > > passing of extensiondata: > > =20 > > The question is whether there is a need to pass the extension data=20 > > during every time the corresponding metadata block is passed or=20 > > updated. For example, CS metadata block sends extension=20 > data specific=20 > > to call center data like Agent is remote or local, agent or=20 > customer=20 > > initiated call (direction) during the CS block creation=20 > (INVITE) and=20 > > these constant information in extensiondata is not required to be=20 > > passed in each update of CS metadata like adding video=20 > stream in the=20 > > mid-session. > > =20 > > The current model allows to pass extensiondata only during=20 > the initial >=20 > > CS block creation and there is no need to update or resend while CS=20 > > block is getting updated with other CS information. IMO,=20 > The current=20 > > extensiondata mechanism is required as SIPREC puts lot of=20 > call centre=20 > > specific attributes proposed during metadata model draft review as=20 > > outside the scope of SIPREC and most of the attributes=20 > mentioned are=20 > > constant within the scope of session. > > =20 > > Also, it is possible to pass update only extension data within RS=20 > > session without impacting parent element. Please let me=20 > know your and=20 > > others opinion whethter it is fine to continue with the current=20 > > extension-data element or to move xs:any element to each of the=20 > > metadata block. > > =20 > > Thanks > > Partha > > ________________________________ > >=20 > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > Sent: Sat 4/2/2011 6:19 PM > > To: Parthasarathi R (partr) > > Cc: Jain, Rajnish; siprec@ietf.org > > Subject: Re: [siprec] extensionData in XML > >=20 > >=20 > >=20 > > Hi Partha, > > I think you're missing my point (or I'm missing yours) - you can do=20 > > all of that without specifying an "extensionData" XML element. =20 > > Unknown XML elements are simply ignored by the other side, so Cisco=20 > > can add a "ciscoPrivateData" XML element wherever it wants=20 > and send it >=20 > > to an Acme; and that private element will be ignored by Acme while=20 > > everything else will continue to work. Which I think is=20 > the behavior=20 > > you want, right? > >=20 > > -hadriel > >=20 > >=20 > > On Apr 1, 2011, at 10:37 AM, Parthasarathi R (partr) wrote: > >=20 > > > Hadriel/Raj, > > > > > > Extensiondata XML is provided as per Metadata model > > extensiondata block. > > > During the initial discussion of metadata model draft, we > > realized that > > > lot of attributes specified for recording are call center > > specific or > > > specific domain related and it is outside the scope of IETF > > SIPREC but > > > it is required for those specific solution to work.=20 > > Extensiondata XML > > > element helps to meet those requirement. > > > > > > Extensiondata is provided with URN UUID to pass or not pass=20 > > > independently in partial data. But it is open item whether > > extensiondata > > > has to be within specific metadatablock or not. > > > > > > Please read inline for more comments. > > > > > > Thanks > > > Partha > > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf > > > Of Jain, Rajnish > > > Sent: Friday, April 01, 2011 6:41 PM > > > To: Hadriel Kaplan; siprec@ietf.org > > > Subject: Re: [siprec] extensionData in XML > > > > > > There may be such motivation from how the CSTA standards > > are specified. > > > They have an element called privateData for each message. It is a=20 > > > placeholder for any non-standardized extensions. This could > > be legacy > > > and may not mean much for the modern text based protocols. > > > > > > I really didn't get the reason why is it not > > require for modern > > > text based protocols. This is more like generic param in > > SIP or xs:any > > > in XML. RFC 6120 is a new RFC which has the similar usage. > > > > > > > > > That said, I think you're right (this generally applies=20 > to any text=20 > > > based protocols and is the fundamental basis for forward/backward=20 > > > compatibility in such protocols). > > > > > > Raj > > > > > > > > > ----------------------------------------------------- > > > Please consider the environment before printing this email. > > > > > >> -----Original Message----- > > >> From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On=20 > > >> Behalf Of Hadriel Kaplan > > >> Sent: Thursday, March 31, 2011 8:43 PM > > >> To: siprec@ietf.org > > >> Subject: [siprec] extensionData in XML > > >> > > >> Howdy, > > >> With regards to the extensionData concept and XML, I have > > a few basic > > >> questions. I am by no means an XML expert so it could > > just be my lack > > > > > >> of knowledge which makes me confused. If so, just tell=20 > me to RTFM. > > >> > > >> draft-ram-siprec-metadata-04 says in section 4.6: > > >> A recording metadata object contains additional data not > > specified > > >> as > > >> part of siprec. This is intended to accommodate=20 > future standards > > >> track extensions, as well as vendor and user specific=20 > extensions. > > >> The mechanism MUST provide a means of unambiguously > > distinguishing > > >> such extension data. > > >> > > >> What confuses me is I didn't think XML had to do such > > machinations to > > >> accommodate this need. I thought we could just specify=20 > in our RFCs >=20 > > >> that unknown XML elements and attributes MUST be=20 > ignored, so that=20 > > >> future RFCs could add them without having to leave > > specific "blob" XML > > > > > >> elements to carry such data. Or at least that's what=20 > we've done so >=20 > > >> far in SIP RFCs with XML bodies, afaik. > > >> namespace model that could be used to disambiguate proprietary=20 > > >> elements from standard ones. If both of those theories > > are correct, > > >> why do we need to define an extensionData element? > > >> > > >> -hadriel > > >> > > >> _______________________________________________ > > >> siprec mailing list > > >> siprec@ietf.org > > >> https://www.ietf.org/mailman/listinfo/siprec > > > > > > DISCLAIMER: This e-mail may contain information that is > > confidential, > > > privileged or otherwise protected from disclosure. If you=20 > are not an >=20 > > > intended recipient of this e-mail, do not duplicate or > > redistribute it > > > by any means. Please delete it and any attachments and > > notify the sender > > > that you have received it in error. Unintended recipients > > are prohibited > > > from taking action on the basis of information in this=20 > e-mail.E-mail >=20 > > > messages may contain computer viruses or other defects,=20 > may not be=20 > > > accurately replicated on other systems, or may be > > intercepted, deleted > > > or interfered with without the knowledge of the sender or > > the intended > > > recipient. If you are not comfortable with the risks=20 > associated with >=20 > > > e-mail messages, you may decide not to use e-mail to > > communicate with > > > IPC. IPC reserves the right, to the extent and under=20 > circumstances=20 > > > permitted by applicable law, to retain, monitor and=20 > intercept e-mail >=20 > > > messages to and from its systems. > > > _______________________________________________ > > > siprec mailing list > > > siprec@ietf.org > > > https://www.ietf.org/mailman/listinfo/siprec > >=20 > >=20 > >=20 > >=20 > = From br@brianrosen.net Wed Apr 6 05:56:04 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A44D028C0FC for ; Wed, 6 Apr 2011 05:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.64 X-Spam-Level: X-Spam-Status: No, score=-101.64 tagged_above=-999 required=5 tests=[AWL=-0.841, BAYES_00=-2.599, J_CHICKENPOX_210=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_29=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74zTK18kKogX for ; Wed, 6 Apr 2011 05:56:03 -0700 (PDT) Received: from barmail5.idig.net (barmail5.idig.net [64.34.111.236]) by core3.amsl.com (Postfix) with ESMTP id 6F58728C0EA for ; Wed, 6 Apr 2011 05:56:03 -0700 (PDT) X-ASG-Debug-ID: 1302094666-00f27e0aa11892b0001-sFFYAS Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail5.idig.net with ESMTP id N1cbjohvdI3h3Yxf; Wed, 06 Apr 2011 05:57:46 -0700 (PDT) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=kyeg-lt510.cis.neustar.com) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Q7SIl-0002pf-JI; Wed, 06 Apr 2011 05:57:46 -0700 Mime-Version: 1.0 (Apple Message framework v1084) X-ASG-Orig-Subj: Re: [siprec] Extension data (was RE: draft-ram-siprec-metadata-format-01) Content-Type: text/plain; charset=us-ascii From: Brian Rosen In-Reply-To: Date: Wed, 6 Apr 2011 08:57:35 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D93ADCB.2050106@stpeter.im> <4D94416E.7070102@cisco.com><4D944429.10607@stpeter.im> <4D94714B.8010102@cisco.com> <21866C7FE177A4449B9136B5B24B1B130BC01128BC@EXMBXCLUS01.citservers.local> <21866C7FE177A4449B9136B5B24B1B130BC01128FB@EXMBXCLUS01.citservers.local> To: "Elwell, John" X-Mailer: Apple Mail (2.1084) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1302094666 X-Barracuda-URL: http://64.34.111.236:8000/cgi-mod/mark.cgi X-Barracuda-Spam-Score: 0.12 X-Barracuda-Spam-Status: No, SCORE=0.12 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests=CN_BODY_332 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.60069 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.12 CN_BODY_332 BODY: CN_BODY_332 Cc: "siprec@ietf.org" Subject: Re: [siprec] Extension data (was RE: draft-ram-siprec-metadata-format-01) X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2011 12:56:04 -0000 We can provide an extension point in each object that allows a new = namespace. Then you can define the extension in a new namespace and = you get backwards compatibility without redefining the object. I'm actually not a fan of that idea for extensions that are seen to have = wide applicability. I'd rather redefine the object. Brian On Apr 6, 2011, at 4:21 AM, Elwell, John wrote: > I tend to agree with Scott that it would be easier to send extension = data as part of the object to which it relates, rather than as a = separate object. >=20 > Advantages: > 1. There is no need for an identifier on the extension data, since it = is always sent as part of the object. > 2. When sending an updated object, it is clear by the presence or = absence of extension data whether previous extension data still applies. >=20 > Disadvantages: > 1. It is not possible to update the extension data without updating = the entire object. >=20 > I believe the advantages outweigh the disadvantage. >=20 > John (as individual) >=20 >=20 >> -----Original Message----- >> From: siprec-bounces@ietf.org=20 >> [mailto:siprec-bounces@ietf.org] On Behalf Of Scott Orton >> Sent: 31 March 2011 17:21 >> To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); Peter=20 >> Saint-Andre >> Cc: siprec@ietf.org >> Subject: Re: [siprec] draft-ram-siprec-metadata-format-01 >>=20 >> Inline comments. >>=20 >> -----Original Message----- >> From: Parthasarathi R (partr) [mailto:partr@cisco.com]=20 >> Sent: Thursday, March 31, 2011 10:42 AM >> To: Scott Orton; Paul Kyzivat (pkyzivat); Peter Saint-Andre >> Cc: siprec@ietf.org >> Subject: RE: [siprec] draft-ram-siprec-metadata-format-01 >>=20 >> Scott, >>=20 >> Thanks for the feedback. >>=20 >> Thanks >> Partha >>=20 >> -----Original Message----- >> From: siprec-bounces@ietf.org=20 >> [mailto:siprec-bounces@ietf.org] On Behalf >> Of Scott Orton >> Sent: Thursday, March 31, 2011 8:59 PM >> To: Paul Kyzivat (pkyzivat); Peter Saint-Andre >> Cc: siprec@ietf.org >> Subject: Re: [siprec] draft-ram-siprec-metadata-format-01 >>=20 >> Here is some feedback on draft-ram-siprec-metadata-format-01.=20 >>=20 >> In the xml schema, the group is not listed as an element in=20 >> the sequence >> for the recording-metadata, which conflicts with the example in 5.1. >>=20 >> Agreed. I'll update in the next revision >>=20 >> In addition, I found it confusing that the extension data is=20 >> included in >> the participant type but not included in any of the other defined >> elements in the recording-metadata. I think it might be good idea to >> include the extension data as last element in the sequences for the >> group, session, etc. As that would eliminate the need for the parent >> attribute in the extension data assuming it stays close to its = current >> format. >>=20 >> It purely depend on whether extension-data has to be=20 >> partially >> passed across separately or not. Currently mechanism allows to pass >> extension data partially within RS whereas in case it is an element >> within any of the metadata block element like participant, stream = then >> it has to be passed across with any change in that particular = metadata >> block element. >>=20 >>=20 >> I see the advantages of it being separate for the=20 >> partial update. I would just like it to be consistent. Either=20 >> in each element or in none of the elements. I think the key=20 >> to deciding where to include the extension data is how a=20 >> partial update should treat the data. If for example in the=20 >> initial metadata you send to the SRS there is extensiondata=20 >> associated with the participant. Then in an UPDATE the=20 >> partial metadata for the participant update the stop-time,=20 >> but does not include the extensiondata. How is the SRS=20 >> expected to handle the lack of extensiondata? Should it treat=20 >> it as the extensiondata is no longer relevant and delete it=20 >> or should it assume it is not changed. If it should treat it=20 >> as unchanged then how do you delete the extension data if it=20 >> is no longer relevant. Since the definition of the extension=20 >> data requires at least one string there is no way to remove=20 >> it. All this leads me to believe that the extension data=20 >> should be part of each element and there s >> hould be no generic extensiondata element in the=20 >> recording-metadata. >>=20 >> In case everyone feels that there is no need to pass extensiondata >> explicitly, it realy simply the solution as there is no need another >> open item like parent id within extensiondata >>=20 >>=20 >> Regards, >> Scott >>=20 >>=20 >> -----Original Message----- >> From: siprec-bounces@ietf.org=20 >> [mailto:siprec-bounces@ietf.org] On Behalf >> Of Paul Kyzivat >> Sent: Thursday, March 31, 2011 7:19 AM >> To: Peter Saint-Andre >> Cc: siprec@ietf.org >> Subject: Re: [siprec] draft-ram-siprec-metadata-format-01 >>=20 >>=20 >>=20 >> On 3/31/2011 5:06 AM, Peter Saint-Andre wrote: >>> I am booked through 11 PM tonight. >>>=20 >>> Tomorrow I have the following windows of time: >>>=20 >>> 07:00-07:30 >>> 15:15-16:00 >>>=20 >>> Naturally that time might get filled if issues come up in=20 >> some of my=20 >>> working groups. :) >>=20 >> But you also have 11-12pm tonite? :-) >> (That is much better for me than the others.) >>=20 >> Maybe its just too late in the week to hope for this. >> We can take it to the list. >>=20 >> Thanks, >> Paul >>=20 >>> On 3/31/11 10:55 AM, Paul Kyzivat wrote: >>>> Peter/Joe, >>>>=20 >>>> Do either of you have any time in the remainder of the=20 >> week when some >>=20 >>>> of us could sit and try to sort out the right way to do=20 >> the extension >> data? >>>> I doubt it would take very long. >>>>=20 >>>> Thanks, >>>> Paul >>>>=20 >>>> On 3/30/2011 6:25 PM, Peter Saint-Andre wrote: >>>>> Here is some quick feedback on=20 >> draft-ram-siprec-metadata-format-01.=20 >>>>> I hope to review it more fully soon. >>>>>=20 >>>>> 1. I would change application/recording to=20 >> application/recording+xml >>=20 >>>>> in accordance with RFC 3023 (many specs illustrate the use of XML=20= >>>>> media types -- see for example RFC 4287). >>>>>=20 >>>>> 2. The large number of elements is a=20 >> bit confusing >> in >>>>> the examples. >>>>>=20 >>>>> 3. In Section 5.1, the example has one element >>>>> qualified by the 'urn:ietf:params:xml:ns:siprec'=20 >> namespace (no other >>>>> namespace is defined) and then multiple elements >>>>> qualified by other namespaces ('http://example.com/groupapp',=20 >>>>> 'http://example.com/sessionapp', etc.). Although those other=20 >>>>> namespaces are certainly *allowed* to use "extensiondata" as an=20 >>>>> element name (that's the beauty of namespaces), it is confusing in >> this document. >>>>> Perhaps you even meant to have elements=20 >> qualified >> by >>>>> the 'urn:ietf:params:xml:ns:siprec' and then child elements=20 >>>>> qualified by other namespaces (in accordance with the schema).=20 >>>>> However, that is not clear in the spec. >>>>>=20 >>>>> 4. There is no built-in datatype for xs:urnuuid, xs:streamMode,=20 >>>>> xs:requester, and so on. See W3C XML Schema Part 2: >>>>>=20 >>>>> http://www.w3.org/TR/xmlschema-2/#built-in-datatypes >>>>>=20 >>>>> 5. The data in the elements with xml:lang=3D"it" really >> should be >>>>> Giulietta Capuleti and Romeo Montecchi. ;-) >>>>>=20 >>>>> Peter >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> siprec mailing list >>>>> siprec@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/siprec >>>> _______________________________________________ >>>> siprec mailing list >>>> siprec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/siprec >>>=20 >>>=20 >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >>=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From john.elwell@siemens-enterprise.com Wed Apr 6 06:20:46 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B086228C0F6 for ; Wed, 6 Apr 2011 06:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxynpwGOG9as for ; Wed, 6 Apr 2011 06:20:45 -0700 (PDT) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id E211528C0F5 for ; Wed, 6 Apr 2011 06:20:44 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-4043577 for siprec@ietf.org; Wed, 6 Apr 2011 15:22:28 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 2495D23F0290 for ; Wed, 6 Apr 2011 15:22:28 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 6 Apr 2011 15:22:28 +0200 From: "Elwell, John" To: "siprec@ietf.org" Date: Wed, 6 Apr 2011 15:22:26 +0200 Thread-Topic: Doodle: Link for poll "SIPREC virtual interim" Thread-Index: Acv0XM0zNUOYNxbUQh+UouIMTh5WBwAADoow 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: Doodle: Link for poll "SIPREC virtual interim" X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2011 13:20:46 -0000 In Prague it was suggested we hold a virtual interim meeting in May. Below = is the link to the Doodle poll - please vote by 2011-04-13. The time range = is deliberately restricted because we have participants from 3 continents. John=20 > -----Original Message----- > From: Doodle [mailto:mailer@doodle.com]=20 > Sent: 06 April 2011 14:16 > To: Elwell, John > Subject: Doodle: Link for poll "SIPREC virtual interim" >=20 > You have initiated a poll "SIPREC virtual interim" at Doodle.=20 > The link to your poll is: >=20 > http://doodle.com/2s7w4dpgd5i9x6zc >=20 > Share this link with all those who should cast their votes.=20 > Do not forget to cast your vote, too. > (If you did not initiate this poll, somebody must=20 > accidentally have used your e-mail address; simply ignore=20 > this e-mail, please.) >=20 >=20 > = From pkyzivat@cisco.com Wed Apr 6 06:55:02 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B9983A69D1 for ; Wed, 6 Apr 2011 06:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XrI5blUnz5ix for ; Wed, 6 Apr 2011 06:55:01 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 0FEB23A69D0 for ; Wed, 6 Apr 2011 06:55:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=2498; q=dns/txt; s=iport; t=1302098205; x=1303307805; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=j7tKc/2TT+BRJtRn02Zh+oZVX2l49MTWv8UDa5tP4mk=; b=TeQRlrWSvksirNwDSR6S1EtNVIveZ4B4gRA6c37nf51hWFR5IvtVujw9 3PeAsse3qcKyHEWKuKVdf8HfHHUs9ARcInZDhFOzgNx1t2T+w3mbhmVV/ fYwwjqSaVU9SvX5h1TlLDvYHcFDuoCOGLJ7SLFfZsT2OtdHq6fLAcQzJ1 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIIAFlwnE2tJV2Y/2dsb2JhbACYbI0Md6U1nDCFbASNPINj X-IronPort-AV: E=Sophos;i="4.63,310,1299456000"; d="scan'208";a="676635249" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by sj-iport-6.cisco.com with ESMTP; 06 Apr 2011 13:56:44 +0000 Received: from [10.86.240.127] (che-vpn-cluster-1-127.cisco.com [10.86.240.127]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p36Dui3Z010679 for ; Wed, 6 Apr 2011 13:56:44 GMT Message-ID: <4D9C711B.6070205@cisco.com> Date: Wed, 06 Apr 2011 09:56:43 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 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] RTP model X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2011 13:55:02 -0000 I am definitely not an expert on this subject, but ISTM that making a choice about one of these models would inordinately limit implementation choices for the SRC. IMO we want to provide a lot of latitude for SRC implementation, even if it means complicating life for the SRS. Thanks, Paul On 4/6/2011 4:05 AM, Elwell, John wrote: > There were discussions before and during the Prague meeting about multiplexing media streams from different participants on to the same port. It became apparent that we need a better understanding of the RTP model we are using first, before we can answer this. > > The question is whether the SRC acts as a translator or as a mixer or end system. > > A translator is defined in RFC 3550 as: > "An intermediate system that forwards RTP packets > with their synchronization source identifier intact. Examples of > translators include devices that convert encodings without mixing, > replicators from multicast to unicast, and application-level > filters in firewalls." > > A mixer or end system, in contrast, would assign new synchronisation sources to RTP packets. > > The translator model seems to require less processing in the SRC - RTP packets would just be forwarded unchanged to the SRC (i.e., the UDP packet would change but its RTP payload would be unchanged). > > However, the translator model prevents some capabilities, e.g.: > - the SRC cannot transcode (e.g., if the SRS does not support the codec used in the CS); > - the SRC cannot mix streams from different participants (e.g., to reduce the bandwidth required on the RS path); > - the SRC cannot encrypt streams on the RS path if unencrypted on the CS path or vice versa; > - the SRC cannot use different encryption keys on the CS path and the RS path. > > Therefore, although the translator model might work in some situations, it probably can't satisfy all requirements. > > Also with the translator model, we would need to be clear how RTCP would work. Consider an SRC at a B2BUA. It receives RTP packets from party A, forwards them as a translator to party B, and also forwards them as a translator to the SRS. The SRC will receive RTCP packets from both party B and the SRS and needs to send RTCP packets to party A - how does the SRC handle this? > > John (as individual) > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From john.elwell@siemens-enterprise.com Wed Apr 6 07:22:48 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 970B928C0EA for ; Wed, 6 Apr 2011 07:22:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q34G40kSmBmY for ; Wed, 6 Apr 2011 07:22:47 -0700 (PDT) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 4563128C0D0 for ; Wed, 6 Apr 2011 07:22:46 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-4037740 for siprec@ietf.org; Wed, 6 Apr 2011 16:24:30 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 29F8223F028E for ; Wed, 6 Apr 2011 16:24:30 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 6 Apr 2011 16:24:30 +0200 From: "Elwell, John" To: "siprec@ietf.org" Date: Wed, 6 Apr 2011 16:24:28 +0200 Thread-Topic: Partial updates and identifiers Thread-Index: Acv0ZlaJqo+qb+G5S0+adRrxMzRN0g== 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] Partial updates and identifiers X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2011 14:22:48 -0000 Much of the discussion on draft-ram-metadata-format in Prague concerned the= mechanism for performing partial updates and the use of identifiers. The d= raft permits partial updates by allowing individual objects (e.g., CS, part= icipant, media stream) to be sent with updated content, without having to s= end again other objects that have not changed. So, for example, in a large = conference, it would be possible to add or modify an individual participant= object without having to send all the other participant objects again. I d= o not recall any opposition to this basic principle. However, to achieve this, every object requires an identifier, and it was a= sserted that these identifiers need to be globally unique for all time. Alt= hough this might be efficient for updating an individual object, when sendi= ng many objects (e.g., at the start of a CS or when refreshing the entire m= etadata), this can make the metadata very bulky. It depends, of course, on = the format of the identifiers, and it was stated that there could be altern= atives to UUID. Nevertheless, some people had concerns. These concerns also= extended to the impact on the database where metadata is stored, since it = might not be feasible to convert to a database-friendly mechanism for linki= ng objects together. One alternative proposal during the meeting was to have a single unique ide= ntifier at the top level (for the RS) and use local identifiers for other o= bjects. Thus when updating a single object, it would be necessary to includ= e the top level identifier as well as one or more local identifiers. Howeve= r, there were also concerns this might not fulfil actual or perceived futur= e requirements. Please continue discussion on this. John (as chair) From rmohanr@cisco.com Wed Apr 6 07:50:37 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0506828C0D8 for ; Wed, 6 Apr 2011 07:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.437 X-Spam-Level: X-Spam-Status: No, score=-10.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9dO+68FjO4p for ; Wed, 6 Apr 2011 07:50:33 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 069173A693D for ; Wed, 6 Apr 2011 07:50:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=5548; q=dns/txt; s=iport; t=1302101537; x=1303311137; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=SsfiXfFyUgFyonTc6jKGV+Z2GZiPCDlKRPBBpeU4vPc=; b=E7Qe/+Er+u6PWcfMNyx8eEOZMGV/9efUMmtlrTw0lWWdJ8mZwYJUuGkN K/xgamAkZGM6ZbApTXgH3GAJkJTMnrhAONtRQm2ZanO57Sz1bU935Lre3 VYkxOFQxLKenzsI9xdEexOdXoBqRg7bkJbiLp0sjakLinweuYBWPP8juC M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As0AAAJ9nE2Q/khMgWdsb2JhbACYK41LFAEBFiYlpTOcOoVsBIVMi1k X-IronPort-AV: E=Sophos;i="4.63,310,1299456000"; d="scan'208";a="24676386" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 06 Apr 2011 14:52:16 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p36Eq97o029030; Wed, 6 Apr 2011 14:52:15 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); Wed, 6 Apr 2011 20:22:13 +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: Wed, 6 Apr 2011 20:22:11 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD05EF92EF@XMB-BGL-417.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] comments on draft-ram-siprec-metadata-04 Thread-Index: Acvr6KoPYFMcjPlASk+pOtN532GUhgBO/qTgAD5pH0AAJpm4YABBRncAAAC5KqAAABl2UAAAlZ6wAAOH8AAAVJiJUADNFEegAAQ3wAA= References: <21866C7FE177A4449B9136B5B24B1B130BC011290A@EXMBXCLUS01.citservers.local> <21866C7FE177A4449B9136B5B24B1B130BC011294A@EXMBXCLUS01.citservers.local> <35BCE99A477D6A4986FB2216D8CF2CFD05DD8C0C@XMB-BGL-417.cisco.com> From: "Ram Mohan R (rmohanr)" To: "Elwell, John" , "Scott Orton" , "Charles Eckel (eckelcu)" , "Parthasarathi R (partr)" , X-OriginalArrivalTime: 06 Apr 2011 14:52:13.0792 (UTC) FILETIME=[37136600:01CBF46A] Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2011 14:50:37 -0000 Hi John, Yes We have an indirect relationship in the current model. However in the current model it is REQUIRED to have a CSG as CS is connected to RS through CSG. However not all use cases would need CSG, IOW CSG has to be optional and there should be direct association from CS to RS even when CSG is absent. With the below associations we will have: - An instance of RS can have Zero or more CSG blocks. - An instance of RS can have Zero or more CS blocks. - If a CSG is present it will have 1 or more CS. - Each CS can be associated with Zero or 1 CSG. Let me know if you have any concerns. Regards, Ram > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Wednesday, April 06, 2011 6:16 PM > To: Ram Mohan R (rmohanr); Scott Orton; Charles Eckel (eckelcu); > Parthasarathi R (partr); siprec@ietf.org > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 >=20 > I am OK in principle, but I wonder whether there really needs to be a > relationship between CSG and RS. Isn't that relationship an indirect > relationship via CS? >=20 > John (as individual) >=20 >=20 > > -----Original Message----- > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > Sent: 03 April 2011 18:13 > > To: Scott Orton; Elwell, John; Charles Eckel (eckelcu); > > Parthasarathi R (partr); siprec@ietf.org > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > > > Scott, > > > > I am ok to make this change to the model. I would like to hear from > > others if they have any issues in incorporating this change in the > > model. > > > > The updated portion of the model will look like > > > > > > +-------------------------------+ 1 > > | Recording Session (RS) |---------------+ > > +-------------------------------+ | > > | 1..* |1..* | > > | | | > > | 0..* |0..* | > > +--------------+ +-----------------+ | > > |Communication | | Communication | 1 | > > | Session (CS) |----------| Session (CS) |---| > > | Group |0..1 1..*| | | 0..* +----------+ > > +--------------+ +-----------------+ |------|Extension | > > 1| | 0..* |1..* | | Data | > > | | 2..* |0..* | +----------+ > > 0..*| > > +---------+ > > |Extension| > > | Data | > > +---------+ > > > > The only change in the association is : > > A CS MUST be associated with zero or one CS-Group > > > > Rest of the associations remain same. Further the association > > between CS > > and RS remains same as what is between CS-Group and RS. > > > > Comments ? > > > > Regards, > > Ram > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > > Behalf Of Scott Orton > > > Sent: Friday, April 01, 2011 12:18 AM > > > To: Elwell, John; Charles Eckel (eckelcu); Parthasarathi R (partr); > > > siprec@ietf.org > > > Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 > > > > > > John, > > > Thanks for the information. > > > > > > In that case I would like to see the CS group be made optional. > > > Rather than the CS pointing to the CS Group, I would like to > suggest > > > that the CS point to the RS and have the CS group stand > > alone where it > > > would just have its own ID and then a list of CS ids that belong to > > the > > > group. > > > > > > Scott > > > > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > Sent: Thursday, March 31, 2011 11:50 AM > > > To: Scott Orton; Charles Eckel (eckelcu); Parthasarathi R (partr); > > > siprec@ietf.org > > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > > > > > Scott, > > > > > > Some folks wanted to be able to group related CSs together > > (e.g., a CS > > > between a customer and an agent and a second CS resulting from the > > > customer being transferred to a second agent). I will leave it to > > those > > > folks to add to this. > > > > > > John (chair hat on) > > > > > > > > > > -----Original Message----- > > > > From: Scott Orton [mailto:sorton@broadsoft.com] > > > > Sent: 31 March 2011 17:43 > > > > To: Elwell, John; Charles Eckel (eckelcu); Parthasarathi R > > > > (partr); siprec@ietf.org > > > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > > > > > > > John, Charles, Partha, > > > > I have a question. What is the purpose of the CS Group? I > > > > do not see it adding anything to the metadata. To me it seems > > > > that the whole purpose of the metadata is to describe the > > > > recording session to the SRS. Looking at the requirements I > > > > see 3 relationships that the spec is attempting to describe: > > > > > > > > A one to one relationship - one communication session to one > > > > recording session > > > > A one to many relationship - one communication session with > > > > multiple Recording sessions > > > > - one Recording session made up of > > > > multiple communications sessions > > > > > > > > The current metadata format allows all of these and I do not > > > > see what the group is adding. > > > > > > > > Regards, > > > > Scott > > > > From mperumal@cisco.com Wed Apr 6 07:55:40 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFD5328C0DB for ; Wed, 6 Apr 2011 07:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.572 X-Spam-Level: X-Spam-Status: No, score=-10.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id keGM03elnrz5 for ; Wed, 6 Apr 2011 07:55:39 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 2C7D13A693C for ; Wed, 6 Apr 2011 07:55:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=3446; q=dns/txt; s=iport; t=1302101843; x=1303311443; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=XTZEHGotMBbLPT5HzDUrg+TlM3bNDgsxUDXm6MY0PFg=; b=ESmWaM2eCz0lgRkAYP4rkmm3CfkQ6Mf8zh72+Zp/XnpxU98kx/1RdLQ5 6HtLwWs8Zqtf0iCFVKGdQNyIvs/8O4/2SCd9hiibxkUDNWpiM9aRdagtr u/tCZw4PdZ0a5SDNF7SkRKX8eLGQQejFxQh/S7R9XGAHpjEjj8Xl2Rxrh E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As0AAC9+nE2Q/khNgWdsb2JhbACYK41LFAEBFiYlpTmcPoVsBIVMi1k X-IronPort-AV: E=Sophos;i="4.63,310,1299456000"; d="scan'208";a="24677112" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 06 Apr 2011 14:57:22 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p36EvKYG012647 for ; Wed, 6 Apr 2011 14:57:21 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Apr 2011 20:27:20 +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: Wed, 6 Apr 2011 20:27:19 +0530 Message-ID: <1D062974A4845E4D8A343C65380492020523BAF6@XMB-BGL-414.cisco.com> In-Reply-To: <4D9C711B.6070205@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] RTP model Thread-Index: Acv0YoGAhhSaIHFhRX236UO0308ZWAABuq2A References: <4D9C711B.6070205@cisco.com> From: "Muthu ArulMozhi Perumal (mperumal)" To: "Paul Kyzivat (pkyzivat)" , X-OriginalArrivalTime: 06 Apr 2011 14:57:20.0184 (UTC) FILETIME=[EDB31B80:01CBF46A] Subject: Re: [siprec] RTP model X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2011 14:55:40 -0000 I agree we should keep the models open to cater to different use-cases. However, for the most common ones we anticipate, I think we should have clear guidelines/recommendations on how it must/should/may work to achieve basic interop among implementations of that model. For e.g, the translator model for SRC looks a simple one that would cater to a large number of cases and we might want to have clear guidelines/recommendations on how RTP and RTCP should be handled for it. thanks, Muthu |-----Original Message----- |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat (pkyzivat) |Sent: Wednesday, April 06, 2011 7:27 PM |To: siprec@ietf.org |Subject: Re: [siprec] RTP model | |I am definitely not an expert on this subject, but ISTM that making a |choice about one of these models would inordinately limit implementation |choices for the SRC. IMO we want to provide a lot of latitude for SRC |implementation, even if it means complicating life for the SRS. | | Thanks, | Paul | |On 4/6/2011 4:05 AM, Elwell, John wrote: |> There were discussions before and during the Prague meeting about multiplexing media streams from |different participants on to the same port. It became apparent that we need a better understanding of |the RTP model we are using first, before we can answer this. |> |> The question is whether the SRC acts as a translator or as a mixer or end system. |> |> A translator is defined in RFC 3550 as: |> "An intermediate system that forwards RTP packets |> with their synchronization source identifier intact. Examples of |> translators include devices that convert encodings without mixing, |> replicators from multicast to unicast, and application-level |> filters in firewalls." |> |> A mixer or end system, in contrast, would assign new synchronisation sources to RTP packets. |> |> The translator model seems to require less processing in the SRC - RTP packets would just be |forwarded unchanged to the SRC (i.e., the UDP packet would change but its RTP payload would be |unchanged). |> |> However, the translator model prevents some capabilities, e.g.: |> - the SRC cannot transcode (e.g., if the SRS does not support the codec used in the CS); |> - the SRC cannot mix streams from different participants (e.g., to reduce the bandwidth required on |the RS path); |> - the SRC cannot encrypt streams on the RS path if unencrypted on the CS path or vice versa; |> - the SRC cannot use different encryption keys on the CS path and the RS path. |> |> Therefore, although the translator model might work in some situations, it probably can't satisfy |all requirements. |> |> Also with the translator model, we would need to be clear how RTCP would work. Consider an SRC at a |B2BUA. It receives RTP packets from party A, forwards them as a translator to party B, and also |forwards them as a translator to the SRS. The SRC will receive RTCP packets from both party B and the |SRS and needs to send RTCP packets to party A - how does the SRC handle this? |> |> John (as individual) |> |> |> _______________________________________________ |> siprec mailing 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 Apr 6 07:55:52 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 613493A69BB for ; Wed, 6 Apr 2011 07:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k7qiOCuQnmqQ for ; Wed, 6 Apr 2011 07:55:51 -0700 (PDT) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 740173A693C for ; Wed, 6 Apr 2011 07:55:51 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-4030107 for siprec@ietf.org; Wed, 6 Apr 2011 16:55:13 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id B9D3E23F028E for ; Wed, 6 Apr 2011 16:55:13 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 6 Apr 2011 16:55:13 +0200 From: "Elwell, John" To: "siprec@ietf.org" Date: Wed, 6 Apr 2011 16:55:12 +0200 Thread-Topic: Recording awareness indication Thread-Index: Acv0aqGL7/Usl7zCTq2EbdgbYBuKcg== 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] Recording awareness indication X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2011 14:55:52 -0000 There was an inconclusive discussion in Prague on the recording awareness s= ignalling indication in draft-portman-siprec-protocol (slide 6 / section 6.= 1 of draft). If I understand correctly, it indicates that a UA involved in = the CS supports the SIPREC extensions relevant to the CS. In particular, it= indicates that the UA would be able to understand SIP/SDP recording indica= tions (slide 7 / section 6.2 of draft). It seems the recording awareness in= dication means that the SRC can rely on the recording indications in SIP/SD= P to advise the user that recording is in progress, thereby avoiding the ne= ed for the SRC to provide suitable indications through non-SIP means (e.g.,= in-band audio announcements). Please continue this discussion. John (as chair) From john.elwell@siemens-enterprise.com Wed Apr 6 08:06:26 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA6643A693C for ; Wed, 6 Apr 2011 08:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9ppezoVWc6G for ; Wed, 6 Apr 2011 08:06:25 -0700 (PDT) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 918403A69C2 for ; Wed, 6 Apr 2011 08:06:25 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-4038562 for siprec@ietf.org; Wed, 6 Apr 2011 17:08:08 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id CE4E31EB82B6 for ; Wed, 6 Apr 2011 17:08:08 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 6 Apr 2011 17:08:08 +0200 From: "Elwell, John" To: "Elwell, John" , "siprec@ietf.org" Date: Wed, 6 Apr 2011 17:08:07 +0200 Thread-Topic: Recording awareness indication Thread-Index: Acv0aqGL7/Usl7zCTq2EbdgbYBuKcgAAHpyQ 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] Recording awareness indication X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2011 15:06:26 -0000 My own thoughts on this are that the SIP/SDP indication that recording is i= n progress, even if sent to a UA known to be recording-aware, should not be= used as a substitute for other non-SIP/SDP means of notification that migh= t otherwise be needed (e.g., an in-band audio announcement). I think record= ing indicators should be used to complement other means. For example, an in= -band audio announcement would be able to reach all users (although might b= e problematic for hearing-impaired users or for users speaking a different = language). Despite such limitations, an in-band announcement is often suffi= cient to satisfy legal requirements. On the other hand, a SIP/SDP indicatio= n that recording is in progress could be rendered in different ways and in = different languages at the user interface of a recording-aware UA. For this reason, I don't see a need for the recording-aware indication in S= IP/SDP. Recording indications can be sent without knowing whether they will= be understood by the receiving UA - if they are understood the user might = get an enhanced indication - if not they will be discarded and the user wil= l get only the basic (non-SIP/SDP) indication. John (as individual) > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > Sent: 06 April 2011 15:55 > To: siprec@ietf.org > Subject: [siprec] Recording awareness indication >=20 > There was an inconclusive discussion in Prague on the=20 > recording awareness signalling indication in=20 > draft-portman-siprec-protocol (slide 6 / section 6.1 of=20 > draft). If I understand correctly, it indicates that a UA=20 > involved in the CS supports the SIPREC extensions relevant to=20 > the CS. In particular, it indicates that the UA would be able=20 > to understand SIP/SDP recording indications (slide 7 /=20 > section 6.2 of draft). It seems the recording awareness=20 > indication means that the SRC can rely on the recording=20 > indications in SIP/SDP to advise the user that recording is=20 > in progress, thereby avoiding the need for the SRC to provide=20 > suitable indications through non-SIP means (e.g., in-band=20 > audio announcements). >=20 > Please continue this discussion. >=20 > John (as chair) > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > = From Henry.Lum@alcatel-lucent.com Wed Apr 6 08:21:49 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF46F3A67E7 for ; Wed, 6 Apr 2011 08:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.367 X-Spam-Level: X-Spam-Status: No, score=-6.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WntFUs2A6JLN for ; Wed, 6 Apr 2011 08:21:47 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id C84823A680A for ; Wed, 6 Apr 2011 08:21:47 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p36FNVVi016199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 6 Apr 2011 10:23:31 -0500 (CDT) Received: from relay-out2.dc (relay-out2.dc.genesyslab.com [172.22.68.188]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p36FNTmY029172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 6 Apr 2011 10:23:31 -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 p36FNTUt010206; Wed, 6 Apr 2011 08:23:29 -0700 (PDT) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.93]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Apr 2011 08:23:29 -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, 6 Apr 2011 08:23:18 -0700 Message-ID: <059AF07365DC474393A19A3AF187DF7406E6721C@NAHALD.us.int.genesyslab.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Recording awareness indication Thread-Index: Acv0aqGL7/Usl7zCTq2EbdgbYBuKcgAAHpyQAABgUXA= References: From: "Henry Lum" To: "Elwell, John" , X-OriginalArrivalTime: 06 Apr 2011 15:23:29.0033 (UTC) FILETIME=[94CE7790:01CBF46E] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: Re: [siprec] Recording awareness indication X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2011 15:21:50 -0000 If the awareness is not revealed to the SRC, then this means that the SRC will have to assume that it will deliver both the basic (non-SIP/SDP) indication as well as the enhanced indication (in SIP/SDP) to ensure it meets any legal requirements. This may sound redundant to me to render both indications at the same time, however, the requirements REQ-018 and REQ-019 does not preclude both types of indication to be used together.=20 Henry > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Elwell, John > Sent: Wednesday, April 06, 2011 11:08 AM > To: Elwell, John; siprec@ietf.org > Subject: Re: [siprec] Recording awareness indication >=20 > My own thoughts on this are that the SIP/SDP indication that recording > is in progress, even if sent to a UA known to be recording-aware, > should not be used as a substitute for other non-SIP/SDP means of > notification that might otherwise be needed (e.g., an in-band audio > announcement). I think recording indicators should be used to > complement other means. For example, an in-band audio announcement > would be able to reach all users (although might be problematic for > hearing-impaired users or for users speaking a different language). > Despite such limitations, an in-band announcement is often sufficient > to satisfy legal requirements. On the other hand, a SIP/SDP indication > that recording is in progress could be rendered in different ways and > in different languages at the user interface of a recording-aware UA. >=20 > For this reason, I don't see a need for the recording-aware indication > in SIP/SDP. Recording indications can be sent without knowing whether > they will be understood by the receiving UA - if they are understood > the user might get an enhanced indication - if not they will be > discarded and the user will get only the basic (non-SIP/SDP) > indication. >=20 > John (as individual) >=20 >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > > Sent: 06 April 2011 15:55 > > To: siprec@ietf.org > > Subject: [siprec] Recording awareness indication > > > > There was an inconclusive discussion in Prague on the > > recording awareness signalling indication in > > draft-portman-siprec-protocol (slide 6 / section 6.1 of > > draft). If I understand correctly, it indicates that a UA > > involved in the CS supports the SIPREC extensions relevant to > > the CS. In particular, it indicates that the UA would be able > > to understand SIP/SDP recording indications (slide 7 / > > section 6.2 of draft). It seems the recording awareness > > indication means that the SRC can rely on the recording > > indications in SIP/SDP to advise the user that recording is > > in progress, thereby avoiding the need for the SRC to provide > > suitable indications through non-SIP means (e.g., in-band > > audio announcements). > > > > Please continue this discussion. > > > > John (as chair) > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec =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 trac+siprec@trac.tools.ietf.org Wed Apr 6 08:22:39 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E22533A67E7 for ; Wed, 6 Apr 2011 08:22:39 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucWQ74F1Edm5 for ; Wed, 6 Apr 2011 08:22:39 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 3B4CC3A680A for ; Wed, 6 Apr 2011 08:22:39 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q7Uaj-00063p-CU; Wed, 06 Apr 2011 08:24:21 -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, john.elwell@siemens-enterprise.com X-Trac-Project: siprec Date: Wed, 06 Apr 2011 15:24:21 -0000 X-URL: http://tools.ietf.org/siprec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/siprec/trac/ticket/68 Message-ID: <075.db8ff04b7cbf099d401d476dc3008b5f@trac.tools.ietf.org> X-Trac-Ticket-ID: 68 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rmohanr@cisco.com, john.elwell@siemens-enterprise.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: [siprec] #68: Start/stop time for Recording Session X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 15:22:40 -0000 #68: Start/stop time for Recording Session From Prague minutes: "Slide 5: Open item: Optional start/stop time attribute for Recording Session to be added? There was considerable discussion on this, with points being raised about how to determine that the RS has really ended, the impact of persistent recording sessions, metadata updates continuing after the SIP session has finished, etc.. To be taken to the list." -- ------------------------------------------------+--------------------------- Reporter: john.elwell@… | Owner: rmohanr@… Type: defect | Status: new Priority: minor | Milestone: Component: Metadata Model | Version: Severity: Active WG Document | Keywords: ------------------------------------------------+--------------------------- Ticket URL: siprec From trac+siprec@trac.tools.ietf.org Wed Apr 6 08:23:52 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EA623A680A for ; Wed, 6 Apr 2011 08:23:52 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2MZHsuFk0Tnb for ; Wed, 6 Apr 2011 08:23:50 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id D03163A67E7 for ; Wed, 6 Apr 2011 08:23:50 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q7Ubu-0008ON-Iw; Wed, 06 Apr 2011 08:25:34 -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, john.elwell@siemens-enterprise.com X-Trac-Project: siprec Date: Wed, 06 Apr 2011 15:25:34 -0000 X-URL: http://tools.ietf.org/siprec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/siprec/trac/ticket/69 Message-ID: <075.8754a9eea7fed1cd5e29b863a48378ef@trac.tools.ietf.org> X-Trac-Ticket-ID: 69 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rmohanr@cisco.com, john.elwell@siemens-enterprise.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: [siprec] #69: Start/stop time for CS Group X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 15:23:52 -0000 #69: Start/stop time for CS Group This is related to the corresponding issue on Recording Session -- ------------------------------------------------+--------------------------- Reporter: john.elwell@… | Owner: rmohanr@… Type: defect | Status: new Priority: minor | Milestone: Component: Metadata Model | Version: Severity: Active WG Document | Keywords: ------------------------------------------------+--------------------------- Ticket URL: siprec From trac+siprec@trac.tools.ietf.org Wed Apr 6 08:25:03 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9780C3A6878 for ; Wed, 6 Apr 2011 08:25:03 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kDc6JihIDpxj for ; Wed, 6 Apr 2011 08:25:02 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id C7A583A680A for ; Wed, 6 Apr 2011 08:25:01 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q7Ud3-00029r-Iw; Wed, 06 Apr 2011 08:26:45 -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, john.elwell@siemens-enterprise.com X-Trac-Project: siprec Date: Wed, 06 Apr 2011 15:26:44 -0000 X-URL: http://tools.ietf.org/siprec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/siprec/trac/ticket/70 Message-ID: <075.74cbc88524d04555f4a1b6c21412aa47@trac.tools.ietf.org> X-Trac-Ticket-ID: 70 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rmohanr@cisco.com, john.elwell@siemens-enterprise.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: [siprec] #70: Start/stop time for paraticipant X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 15:25:03 -0000 #70: Start/stop time for paraticipant From Prague minutes: "Slide 8: Open item: Optional start/stop time attribute for Participant to be added? There seemed to be a feeling in the room that this is needed, but it was not clear exactly what it means and how it relates to things like a participant starting/stopping involvement in a CS and a participant starting/stopping involvement in a media stream. More discussion is needed to clarify this." -- ------------------------------------------------+--------------------------- Reporter: john.elwell@… | Owner: rmohanr@… Type: defect | Status: new Priority: minor | Milestone: Component: Metadata Model | Version: Severity: Active WG Document | Keywords: ------------------------------------------------+--------------------------- Ticket URL: siprec From trac+siprec@trac.tools.ietf.org Wed Apr 6 08:26:42 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2E1D3A67E7 for ; Wed, 6 Apr 2011 08:26:41 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id efzCTNoZVnWw for ; Wed, 6 Apr 2011 08:26:38 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id EC4DD28C123 for ; Wed, 6 Apr 2011 08:26:37 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q7Ueb-0005gw-VU; Wed, 06 Apr 2011 08:28:21 -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, john.elwell@siemens-enterprise.com X-Trac-Project: siprec Date: Wed, 06 Apr 2011 15:28:21 -0000 X-URL: http://tools.ietf.org/siprec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/siprec/trac/ticket/71 Message-ID: <075.7b3e219c15a294040b4f56d6c75e934e@trac.tools.ietf.org> X-Trac-Ticket-ID: 71 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rmohanr@cisco.com, john.elwell@siemens-enterprise.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: [siprec] #71: Media Stream / codec params X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 15:26:42 -0000 #71: Media Stream / codec params From Prague minutes: "Slide 9: Open item: Media stream: Codec params text change. Although there wasn't any objection to changing codec params text to refer to RS SDP (as opposed to CS SDP), it was not clear to everyone why this was needed at all. Therefore it will be taken to the mailing list." -- ------------------------------------------------+--------------------------- Reporter: john.elwell@… | Owner: rmohanr@… Type: defect | Status: new Priority: minor | Milestone: Component: Metadata Model | Version: Severity: Active WG Document | Keywords: ------------------------------------------------+--------------------------- Ticket URL: siprec From john.elwell@siemens-enterprise.com Wed Apr 6 08:30:31 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76CD83A6878 for ; Wed, 6 Apr 2011 08:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9wyyl-lpLbu for ; Wed, 6 Apr 2011 08:30:31 -0700 (PDT) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id AAE113A67E7 for ; Wed, 6 Apr 2011 08:30:30 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-4046262; Wed, 6 Apr 2011 17:32:13 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id EC69123F028E; Wed, 6 Apr 2011 17:32:13 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 6 Apr 2011 17:32:14 +0200 From: "Elwell, John" To: "siprec@ietf.org" , "Ram Mohan R (rmohanr)" , "Parthasarathi R (partr)" , "Paul Kyzivat (pkyzivat)" Date: Wed, 6 Apr 2011 17:32:12 +0200 Thread-Topic: Metadata model issues Thread-Index: Acv0b80T2Hzp9g2oRTSFQj21Mmjx4g== 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] Metadata model issues X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2011 15:30:31 -0000 I have added issues from the metadata model discussion in Prague to the iss= ue tracker. Now that this is a WG document, we need to keep track of issues= . Would the editors please add any further issues they know of, and of cour= se close any issues when they consider them resolved. I have named Ram as t= he owner of this "component" on the tracker - if you want that changed, jus= t say. John = From john.elwell@siemens-enterprise.com Wed Apr 6 08:45:27 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D90328C11A for ; Wed, 6 Apr 2011 08:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ew1HzMOzkT3V for ; Wed, 6 Apr 2011 08:45:26 -0700 (PDT) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 2804528C123 for ; Wed, 6 Apr 2011 08:45:25 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-4040031; Wed, 6 Apr 2011 17:47:09 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 545611EB82B8; Wed, 6 Apr 2011 17:47:09 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 6 Apr 2011 17:47:09 +0200 From: "Elwell, John" To: "Ram Mohan R (rmohanr)" , Scott Orton , "Charles Eckel (eckelcu)" , "Parthasarathi R (partr)" , "siprec@ietf.org" Date: Wed, 6 Apr 2011 17:47:08 +0200 Thread-Topic: [siprec] comments on draft-ram-siprec-metadata-04 Thread-Index: Acvr6KoPYFMcjPlASk+pOtN532GUhgBO/qTgAD5pH0AAJpm4YABBRncAAAC5KqAAABl2UAAAlZ6wAAOH8AAAVJiJUADNFEegAAQ3wAAAAh9dwA== Message-ID: References: <21866C7FE177A4449B9136B5B24B1B130BC011290A@EXMBXCLUS01.citservers.local> <21866C7FE177A4449B9136B5B24B1B130BC011294A@EXMBXCLUS01.citservers.local> <35BCE99A477D6A4986FB2216D8CF2CFD05DD8C0C@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD05EF92EF@XMB-BGL-417.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD05EF92EF@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] comments on draft-ram-siprec-metadata-04 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2011 15:45:27 -0000 Ram, I am not sure this answers my question. In the model you drew below, a CSG = has both a direct relationship with an RS and an indirect relationship (via= a CS). I was questioning whether we could remove the direct relationship, = on the basis that the indirect relationship is sufficient. John (as individual) =20 > -----Original Message----- > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com]=20 > Sent: 06 April 2011 15:52 > To: Elwell, John; Scott Orton; Charles Eckel (eckelcu);=20 > Parthasarathi R (partr); siprec@ietf.org > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 >=20 > Hi John, >=20 > Yes We have an indirect relationship in the current model. However in > the current model it is REQUIRED to have a CSG as CS is=20 > connected to RS > through CSG. However not all use cases would need CSG, IOW=20 > CSG has to be > optional and there should be direct association from CS to RS=20 > even when > CSG is absent. >=20 > With the below associations we will have: > - An instance of RS can have Zero or more CSG blocks. > - An instance of RS can have Zero or more CS blocks. > - If a CSG is present it will have 1 or more CS. > - Each CS can be associated with Zero or 1 CSG. >=20 > Let me know if you have any concerns. >=20 > Regards, > Ram >=20 > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Wednesday, April 06, 2011 6:16 PM > > To: Ram Mohan R (rmohanr); Scott Orton; Charles Eckel (eckelcu); > > Parthasarathi R (partr); siprec@ietf.org > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > >=20 > > I am OK in principle, but I wonder whether there really=20 > needs to be a > > relationship between CSG and RS. Isn't that relationship an indirect > > relationship via CS? > >=20 > > John (as individual) > >=20 > >=20 > > > -----Original Message----- > > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > > Sent: 03 April 2011 18:13 > > > To: Scott Orton; Elwell, John; Charles Eckel (eckelcu); > > > Parthasarathi R (partr); siprec@ietf.org > > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > > > > > Scott, > > > > > > I am ok to make this change to the model. I would like to=20 > hear from > > > others if they have any issues in incorporating this change in the > > > model. > > > > > > The updated portion of the model will look like > > > > > > > > > +-------------------------------+ 1 > > > | Recording Session (RS) |---------------+ > > > +-------------------------------+ | > > > | 1..* |1..* | > > > | | | > > > | 0..* |0..* | > > > +--------------+ +-----------------+ | > > > |Communication | | Communication | 1 | > > > | Session (CS) |----------| Session (CS) |---| > > > | Group |0..1 1..*| | | 0..* > +----------+ > > > +--------------+ +-----------------+ =20 > |------|Extension > | > > > 1| | 0..* |1..* | | Data > | > > > | | 2..* |0..* | > +----------+ > > > 0..*| > > > +---------+ > > > |Extension| > > > | Data | > > > +---------+ > > > > > > The only change in the association is : > > > A CS MUST be associated with zero or one CS-Group > > > > > > Rest of the associations remain same. Further the association > > > between CS > > > and RS remains same as what is between CS-Group and RS. > > > > > > Comments ? > > > > > > Regards, > > > Ram > > > > > > > -----Original Message----- > > > > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On > > > > Behalf Of Scott Orton > > > > Sent: Friday, April 01, 2011 12:18 AM > > > > To: Elwell, John; Charles Eckel (eckelcu); Parthasarathi R > (partr); > > > > siprec@ietf.org > > > > Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 > > > > > > > > John, > > > > Thanks for the information. > > > > > > > > In that case I would like to see the CS group be=20 > made optional. > > > > Rather than the CS pointing to the CS Group, I would like to > > suggest > > > > that the CS point to the RS and have the CS group stand > > > alone where it > > > > would just have its own ID and then a list of CS ids that belong > to > > > the > > > > group. > > > > > > > > Scott > > > > > > > > -----Original Message----- > > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > Sent: Thursday, March 31, 2011 11:50 AM > > > > To: Scott Orton; Charles Eckel (eckelcu); Parthasarathi=20 > R (partr); > > > > siprec@ietf.org > > > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > > > > > > > Scott, > > > > > > > > Some folks wanted to be able to group related CSs together > > > (e.g., a CS > > > > between a customer and an agent and a second CS=20 > resulting from the > > > > customer being transferred to a second agent). I will=20 > leave it to > > > those > > > > folks to add to this. > > > > > > > > John (chair hat on) > > > > > > > > > > > > > -----Original Message----- > > > > > From: Scott Orton [mailto:sorton@broadsoft.com] > > > > > Sent: 31 March 2011 17:43 > > > > > To: Elwell, John; Charles Eckel (eckelcu); Parthasarathi R > > > > > (partr); siprec@ietf.org > > > > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > > > > > > > > > John, Charles, Partha, > > > > > I have a question. What is the purpose of the CS Group? I > > > > > do not see it adding anything to the metadata. To me it seems > > > > > that the whole purpose of the metadata is to describe the > > > > > recording session to the SRS. Looking at the requirements I > > > > > see 3 relationships that the spec is attempting to describe: > > > > > > > > > > A one to one relationship - one communication session to one > > > > > recording session > > > > > A one to many relationship - one communication session with > > > > > multiple Recording sessions > > > > > - one Recording session made up of > > > > > multiple communications sessions > > > > > > > > > > The current metadata format allows all of these and I do not > > > > > see what the group is adding. > > > > > > > > > > Regards, > > > > > Scott > > > > > > = From rmohanr@cisco.com Wed Apr 6 09:51:47 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9182E28C150 for ; Wed, 6 Apr 2011 09:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.446 X-Spam-Level: X-Spam-Status: No, score=-10.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hWE8yrhvR5eo for ; Wed, 6 Apr 2011 09:49:37 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 217A028C14C for ; Wed, 6 Apr 2011 09:48:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=8199; q=dns/txt; s=iport; t=1302108617; x=1303318217; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=AHR7iiGAfDjtjT6JwooAt0S5VxpluSy3/oJhT6u+07E=; b=N5SZ1Akfn9Dj2SIzsL2UMWdDcrGyOcR4LjAWChJh9wlgThHtMB3aXd8D Tf9yp44F9+IUsP3HWnY9mHxII9CL7WgvawGWvRfs8LT1EoL792OU5oIEL 1Am3HTZ2I20QR5zDsqIaHWdx/x7mIysAym1ql20Jn7WL3cBNFgx5BlFrw 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQBABmZnE2Q/khNgWdsb2JhbACYLo1LFAEBFiYliHmdFJxHhWwEhUyLWQ X-IronPort-AV: E=Sophos;i="4.63,311,1299456000"; d="scan'208";a="24693855" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 06 Apr 2011 16:49:07 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p36GmiJ7013931; Wed, 6 Apr 2011 16:49:06 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); Wed, 6 Apr 2011 22:18:15 +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: Wed, 6 Apr 2011 22:18:13 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD05EF9357@XMB-BGL-417.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] comments on draft-ram-siprec-metadata-04 Thread-Index: Acvr6KoPYFMcjPlASk+pOtN532GUhgBO/qTgAD5pH0AAJpm4YABBRncAAAC5KqAAABl2UAAAlZ6wAAOH8AAAVJiJUADNFEegAAQ3wAAAAh9dwAACCc/A References: <21866C7FE177A4449B9136B5B24B1B130BC011290A@EXMBXCLUS01.citservers.local> <21866C7FE177A4449B9136B5B24B1B130BC011294A@EXMBXCLUS01.citservers.local> <35BCE99A477D6A4986FB2216D8CF2CFD05DD8C0C@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD05EF92EF@XMB-BGL-417.cisco.com> From: "Ram Mohan R (rmohanr)" To: "Elwell, John" , "Scott Orton" , "Charles Eckel (eckelcu)" , "Parthasarathi R (partr)" , X-OriginalArrivalTime: 06 Apr 2011 16:48:15.0891 (UTC) FILETIME=[6CCF6630:01CBF47A] Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2011 16:51:48 -0000 Ok. I got your point. I am fine with this. The updated portion will look like below +-------------------------------+ 1 | Recording Session (RS) |---------------+ +-------------------------------+ | |1..* | | | |0..* | +--------------+ +-----------------+ | |Communication | | Communication | 1 |=20 | Session (CS) |----------| Session (CS) |---| | Group |0..1 1..*| | | 0..* +----------+ +--------------+ +-----------------+ |------|Extension | 1| | 0..* |1..* | | Data | | | 2..* |0..* | +----------+ 0..*| +---------+ |Extension| =20 | Data | +---------+ CSG can use the indirect relationship (via a CS). Ram > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Wednesday, April 06, 2011 9:17 PM > To: Ram Mohan R (rmohanr); Scott Orton; Charles Eckel (eckelcu); > Parthasarathi R (partr); siprec@ietf.org > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 >=20 > Ram, >=20 > I am not sure this answers my question. In the model you drew below, a > CSG has both a direct relationship with an RS and an indirect > relationship (via a CS). I was questioning whether we could remove the > direct relationship, on the basis that the indirect relationship is > sufficient. >=20 > John (as individual) >=20 >=20 > > -----Original Message----- > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > Sent: 06 April 2011 15:52 > > To: Elwell, John; Scott Orton; Charles Eckel (eckelcu); > > Parthasarathi R (partr); siprec@ietf.org > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > > > Hi John, > > > > Yes We have an indirect relationship in the current model. However in > > the current model it is REQUIRED to have a CSG as CS is > > connected to RS > > through CSG. However not all use cases would need CSG, IOW > > CSG has to be > > optional and there should be direct association from CS to RS > > even when > > CSG is absent. > > > > With the below associations we will have: > > - An instance of RS can have Zero or more CSG blocks. > > - An instance of RS can have Zero or more CS blocks. > > - If a CSG is present it will have 1 or more CS. > > - Each CS can be associated with Zero or 1 CSG. > > > > Let me know if you have any concerns. > > > > Regards, > > Ram > > > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > Sent: Wednesday, April 06, 2011 6:16 PM > > > To: Ram Mohan R (rmohanr); Scott Orton; Charles Eckel (eckelcu); > > > Parthasarathi R (partr); siprec@ietf.org > > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > > > > > I am OK in principle, but I wonder whether there really > > needs to be a > > > relationship between CSG and RS. Isn't that relationship an > indirect > > > relationship via CS? > > > > > > John (as individual) > > > > > > > > > > -----Original Message----- > > > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > > > Sent: 03 April 2011 18:13 > > > > To: Scott Orton; Elwell, John; Charles Eckel (eckelcu); > > > > Parthasarathi R (partr); siprec@ietf.org > > > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > > > > > > > Scott, > > > > > > > > I am ok to make this change to the model. I would like to > > hear from > > > > others if they have any issues in incorporating this change in > the > > > > model. > > > > > > > > The updated portion of the model will look like > > > > > > > > > > > > +-------------------------------+ 1 > > > > | Recording Session (RS) |---------------+ > > > > +-------------------------------+ | > > > > | 1..* |1..* | > > > > | | | > > > > | 0..* |0..* | > > > > +--------------+ +-----------------+ | > > > > |Communication | | Communication | 1 | > > > > | Session (CS) |----------| Session (CS) |---| > > > > | Group |0..1 1..*| | | 0..* > > +----------+ > > > > +--------------+ +-----------------+ > > |------|Extension > > | > > > > 1| | 0..* |1..* | | Data > > | > > > > | | 2..* |0..* | > > +----------+ > > > > 0..*| > > > > +---------+ > > > > |Extension| > > > > | Data | > > > > +---------+ > > > > > > > > The only change in the association is : > > > > A CS MUST be associated with zero or one CS-Group > > > > > > > > Rest of the associations remain same. Further the association > > > > between CS > > > > and RS remains same as what is between CS-Group and RS. > > > > > > > > Comments ? > > > > > > > > Regards, > > > > Ram > > > > > > > > > -----Original Message----- > > > > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On > > > > > Behalf Of Scott Orton > > > > > Sent: Friday, April 01, 2011 12:18 AM > > > > > To: Elwell, John; Charles Eckel (eckelcu); Parthasarathi R > > (partr); > > > > > siprec@ietf.org > > > > > Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 > > > > > > > > > > John, > > > > > Thanks for the information. > > > > > > > > > > In that case I would like to see the CS group be > > made optional. > > > > > Rather than the CS pointing to the CS Group, I would like to > > > suggest > > > > > that the CS point to the RS and have the CS group stand > > > > alone where it > > > > > would just have its own ID and then a list of CS ids that > belong > > to > > > > the > > > > > group. > > > > > > > > > > Scott > > > > > > > > > > -----Original Message----- > > > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > > Sent: Thursday, March 31, 2011 11:50 AM > > > > > To: Scott Orton; Charles Eckel (eckelcu); Parthasarathi > > R (partr); > > > > > siprec@ietf.org > > > > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > > > > > > > > > Scott, > > > > > > > > > > Some folks wanted to be able to group related CSs together > > > > (e.g., a CS > > > > > between a customer and an agent and a second CS > > resulting from the > > > > > customer being transferred to a second agent). I will > > leave it to > > > > those > > > > > folks to add to this. > > > > > > > > > > John (chair hat on) > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Scott Orton [mailto:sorton@broadsoft.com] > > > > > > Sent: 31 March 2011 17:43 > > > > > > To: Elwell, John; Charles Eckel (eckelcu); Parthasarathi R > > > > > > (partr); siprec@ietf.org > > > > > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata- > 04 > > > > > > > > > > > > John, Charles, Partha, > > > > > > I have a question. What is the purpose of the CS Group? I > > > > > > do not see it adding anything to the metadata. To me it seems > > > > > > that the whole purpose of the metadata is to describe the > > > > > > recording session to the SRS. Looking at the requirements I > > > > > > see 3 relationships that the spec is attempting to describe: > > > > > > > > > > > > A one to one relationship - one communication session to one > > > > > > recording session > > > > > > A one to many relationship - one communication session with > > > > > > multiple Recording sessions > > > > > > - one Recording session made up of > > > > > > multiple communications sessions > > > > > > > > > > > > The current metadata format allows all of these and I do not > > > > > > see what the group is adding. > > > > > > > > > > > > Regards, > > > > > > Scott > > > > > > > > From pkyzivat@cisco.com Wed Apr 6 12:01:29 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8082A3A69A6 for ; Wed, 6 Apr 2011 12:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id goOvpU3LCQv6 for ; Wed, 6 Apr 2011 12:01:28 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id DC2413A69C3 for ; Wed, 6 Apr 2011 12:01:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=3077; q=dns/txt; s=iport; t=1302116592; x=1303326192; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=1bRdMfgUfXm3cuBGO3YIAwBB3dkecV/ZiQcnAXT4Xoo=; b=aK57XLOfA+xXkpTqzcAapOt2zrIf4N/eGe+qNsH81pl8q/44OdePm4J1 NiBJIMgf0+aUITX1hlcndmTt9WpoRMCZMIsGMklQ/TbPoEmM7uscT7lCW gD86ir7e0+FJf3OWvQF00Noo3rcgTvC9H2jkDGVzZJwM9G0OpGOv697wJ c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAM24nE2rRDoH/2dsb2JhbAClfXenUpxFhWwEjTyDYw X-IronPort-AV: E=Sophos;i="4.63,311,1299456000"; d="scan'208";a="425062750" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-1.cisco.com with ESMTP; 06 Apr 2011 19:02:58 +0000 Received: from [10.86.240.127] (che-vpn-cluster-1-127.cisco.com [10.86.240.127]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p36J2vPr014900 for ; Wed, 6 Apr 2011 19:02:57 GMT Message-ID: <4D9CB8E1.7030402@cisco.com> Date: Wed, 06 Apr 2011 15:02:57 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 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] Partial updates and identifiers X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2011 19:01:29 -0000 John, For the moment we have proposed that the ids be conveyed in the form of URIs that are globally unique, and specifically that they be UUID URNs. There is no dependency on the particular form of the URI, but specifying they must be UUID URNs makes it possible to perform some internal optimizations for storage. The UUID URN is a pretty inefficient encoding. A UUID can be expressed in 32 bits, so we could consider retaining UUIDs but alter the encoding if its really an issue. However I am far from convinced that the size of the IDs is going to be a major issue in the overall size of messages, so I think its probably premature to worry about it. Because the ids can be expressed in 32 bits, the SRC and SRS can store them internally that way, thus reducing the runtime cost of maintaining the data. The use of unique ids is a significant part of the overall approach to formatting updates. If somebody has a different concept in mind it could be useful to have an alternative proposal for the format. If we had two worked out approaches we could compare the tradeoffs in each. Thanks, Paul On 4/6/2011 10:24 AM, Elwell, John wrote: > Much of the discussion on draft-ram-metadata-format in Prague concerned the mechanism for performing partial updates and the use of identifiers. The draft permits partial updates by allowing individual objects (e.g., CS, participant, media stream) to be sent with updated content, without having to send again other objects that have not changed. So, for example, in a large conference, it would be possible to add or modify an individual participant object without having to send all the other participant objects again. I do not recall any opposition to this basic principle. > > However, to achieve this, every object requires an identifier, and it was asserted that these identifiers need to be globally unique for all time. Although this might be efficient for updating an individual object, when sending many objects (e.g., at the start of a CS or when refreshing the entire metadata), this can make the metadata very bulky. It depends, of course, on the format of the identifiers, and it was stated that there could be alternatives to UUID. Nevertheless, some people had concerns. These concerns also extended to the impact on the database where metadata is stored, since it might not be feasible to convert to a database-friendly mechanism for linking objects together. > > One alternative proposal during the meeting was to have a single unique identifier at the top level (for the RS) and use local identifiers for other objects. Thus when updating a single object, it would be necessary to include the top level identifier as well as one or more local identifiers. However, there were also concerns this might not fulfil actual or perceived future requirements. > > Please continue discussion on this. > > John (as chair) > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From pkyzivat@cisco.com Wed Apr 6 12:12:42 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BAD53A6973 for ; Wed, 6 Apr 2011 12:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-tCAEAkU8vE for ; Wed, 6 Apr 2011 12:12:40 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id CFFA53A68DF for ; Wed, 6 Apr 2011 12:12:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=3328; q=dns/txt; s=iport; t=1302117265; x=1303326865; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=2RAspFDO+mf1XtMCwUihlLGa1aL/cAVyGbJsBnrt0uE=; b=e40ibkzNUQcqCjNdZqsNtkV0chh8IOQvND8j5LzXrcy9HVgPTRy5hTNV essZWGiEY8lS9c5XtCUUDX7j6KlaZrpW0G4Ocv9833Aoi/fhAmu5mC5E9 2hiTW+Adn7+y+u6s7Erlb9pdQIpreaeb2WDs9u2xwSTvZ9gQl8mLcM4sq Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMC6nE2rRDoG/2dsb2JhbAClfXenQpxEhWwEjTyDYw X-IronPort-AV: E=Sophos;i="4.63,311,1299456000"; d="scan'208";a="290701317" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-3.cisco.com with ESMTP; 06 Apr 2011 19:14:25 +0000 Received: from [10.86.240.127] (che-vpn-cluster-1-127.cisco.com [10.86.240.127]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p36JENPk000800 for ; Wed, 6 Apr 2011 19:14:24 GMT Message-ID: <4D9CBB90.4080804@cisco.com> Date: Wed, 06 Apr 2011 15:14:24 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 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] Recording awareness indication X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2011 19:12:42 -0000 I liked this concept of an overt "opt-out" of the in-band indication. ISTM that if the UA has a "better" way of doing the indication it may not want the default mechanism. (E.g. The UA may want to apply its own in-band indication. But that won't work well if a different one has already been applied.) If we can agree on the *concept* of opt-out, then we can determine the exact form as a subsequent step. I suppose some SRCs may feel they are obliged to do their own indication even if a participant desires to opt-out, and we ought to allow that too. In that case there should probably be some indication that the opt-out has been ignored, so that the UA can behave accordingly. Thanks, Paul On 4/6/2011 11:08 AM, Elwell, John wrote: > My own thoughts on this are that the SIP/SDP indication that recording is in progress, even if sent to a UA known to be recording-aware, should not be used as a substitute for other non-SIP/SDP means of notification that might otherwise be needed (e.g., an in-band audio announcement). I think recording indicators should be used to complement other means. For example, an in-band audio announcement would be able to reach all users (although might be problematic for hearing-impaired users or for users speaking a different language). Despite such limitations, an in-band announcement is often sufficient to satisfy legal requirements. On the other hand, a SIP/SDP indication that recording is in progress could be rendered in different ways and in different languages at the user interface of a recording-aware UA. > > For this reason, I don't see a need for the recording-aware indication in SIP/SDP. Recording indications can be sent without knowing whether they will be understood by the receiving UA - if they are understood the user might get an enhanced indication - if not they will be discarded and the user will get only the basic (non-SIP/SDP) indication. > > John (as individual) > > >> -----Original Message----- >> From: siprec-bounces@ietf.org >> [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John >> Sent: 06 April 2011 15:55 >> To: siprec@ietf.org >> Subject: [siprec] Recording awareness indication >> >> There was an inconclusive discussion in Prague on the >> recording awareness signalling indication in >> draft-portman-siprec-protocol (slide 6 / section 6.1 of >> draft). If I understand correctly, it indicates that a UA >> involved in the CS supports the SIPREC extensions relevant to >> the CS. In particular, it indicates that the UA would be able >> to understand SIP/SDP recording indications (slide 7 / >> section 6.2 of draft). It seems the recording awareness >> indication means that the SRC can rely on the recording >> indications in SIP/SDP to advise the user that recording is >> in progress, thereby avoiding the need for the SRC to provide >> suitable indications through non-SIP means (e.g., in-band >> audio announcements). >> >> Please continue this discussion. >> >> John (as chair) >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >> > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From pkyzivat@cisco.com Wed Apr 6 12:21:14 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14DE13A6405 for ; Wed, 6 Apr 2011 12:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWAgetx+Nidy for ; Wed, 6 Apr 2011 12:21:10 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 51AFC3A63EB for ; Wed, 6 Apr 2011 12:21:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=7162; q=dns/txt; s=iport; t=1302117773; x=1303327373; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=ZoKVNP58EuaKEDApahKaCJjh/pDL3a4pSvJe+vYsYUQ=; b=HKUp/M1oWfbTtOkX4170NF/9ZIp+chY8r9LvZFu9ZJO+hEpcpACcEXzD 0oUJzsmqTwA5UC9xpyFlCL6M7e5YcPUNmR7iGM+MVOYVCoDR5zfFLSfom xUBqPmEvncxYkkqYKoVnZ0QjFfNVrrwi29j75UmTk+BN8QlpRItsz2/eH 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUBAHq8nE2rRDoG/2dsb2JhbACYMY1Md6c5nESFbASNPINj X-IronPort-AV: E=Sophos;i="4.63,311,1299456000"; d="scan'208";a="331962923" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-2.cisco.com with ESMTP; 06 Apr 2011 19:22:53 +0000 Received: from [10.86.240.127] (che-vpn-cluster-1-127.cisco.com [10.86.240.127]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p36JMqGZ009418 for ; Wed, 6 Apr 2011 19:22:52 GMT Message-ID: <4D9CBD8C.4010901@cisco.com> Date: Wed, 06 Apr 2011 15:22:52 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: siprec@ietf.org References: <21866C7FE177A4449B9136B5B24B1B130BC011290A@EXMBXCLUS01.citservers.local> <21866C7FE177A4449B9136B5B24B1B130BC011294A@EXMBXCLUS01.citservers.local> <35BCE99A477D6A4986FB2216D8CF2CFD05DD8C0C@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD05EF92EF@XMB-BGL-417.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2011 19:21:14 -0000 John, I've been thinking about how everything relates to the RS, and that maybe we should make some more major changes. What I'm thinking is that none of the elements have a direct relationship to RS. Rather, each element is ultimately constructed as a time series of values delivered in updates. Its the updates that have a relationship to a RS - the one they are delivered in. That allows the possibility that not all the updates come from the same RS. I haven't drawn a model diagram here because the concept is still fuzzy. Its a trial balloon - to see what others think. Thanks, Paul On 4/6/2011 11:47 AM, Elwell, John wrote: > Ram, > > I am not sure this answers my question. In the model you drew below, a CSG has both a direct relationship with an RS and an indirect relationship (via a CS). I was questioning whether we could remove the direct relationship, on the basis that the indirect relationship is sufficient. > > John (as individual) > > >> -----Original Message----- >> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] >> Sent: 06 April 2011 15:52 >> To: Elwell, John; Scott Orton; Charles Eckel (eckelcu); >> Parthasarathi R (partr); siprec@ietf.org >> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 >> >> Hi John, >> >> Yes We have an indirect relationship in the current model. However in >> the current model it is REQUIRED to have a CSG as CS is >> connected to RS >> through CSG. However not all use cases would need CSG, IOW >> CSG has to be >> optional and there should be direct association from CS to RS >> even when >> CSG is absent. >> >> With the below associations we will have: >> - An instance of RS can have Zero or more CSG blocks. >> - An instance of RS can have Zero or more CS blocks. >> - If a CSG is present it will have 1 or more CS. >> - Each CS can be associated with Zero or 1 CSG. >> >> Let me know if you have any concerns. >> >> Regards, >> Ram >> >>> -----Original Message----- >>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>> Sent: Wednesday, April 06, 2011 6:16 PM >>> To: Ram Mohan R (rmohanr); Scott Orton; Charles Eckel (eckelcu); >>> Parthasarathi R (partr); siprec@ietf.org >>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 >>> >>> I am OK in principle, but I wonder whether there really >> needs to be a >>> relationship between CSG and RS. Isn't that relationship an indirect >>> relationship via CS? >>> >>> John (as individual) >>> >>> >>>> -----Original Message----- >>>> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] >>>> Sent: 03 April 2011 18:13 >>>> To: Scott Orton; Elwell, John; Charles Eckel (eckelcu); >>>> Parthasarathi R (partr); siprec@ietf.org >>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 >>>> >>>> Scott, >>>> >>>> I am ok to make this change to the model. I would like to >> hear from >>>> others if they have any issues in incorporating this change in the >>>> model. >>>> >>>> The updated portion of the model will look like >>>> >>>> >>>> +-------------------------------+ 1 >>>> | Recording Session (RS) |---------------+ >>>> +-------------------------------+ | >>>> | 1..* |1..* | >>>> | | | >>>> | 0..* |0..* | >>>> +--------------+ +-----------------+ | >>>> |Communication | | Communication | 1 | >>>> | Session (CS) |----------| Session (CS) |---| >>>> | Group |0..1 1..*| | | 0..* >> +----------+ >>>> +--------------+ +-----------------+ >> |------|Extension >> | >>>> 1| | 0..* |1..* | | Data >> | >>>> | | 2..* |0..* | >> +----------+ >>>> 0..*| >>>> +---------+ >>>> |Extension| >>>> | Data | >>>> +---------+ >>>> >>>> The only change in the association is : >>>> A CS MUST be associated with zero or one CS-Group >>>> >>>> Rest of the associations remain same. Further the association >>>> between CS >>>> and RS remains same as what is between CS-Group and RS. >>>> >>>> Comments ? >>>> >>>> Regards, >>>> Ram >>>> >>>>> -----Original Message----- >>>>> From: siprec-bounces@ietf.org >> [mailto:siprec-bounces@ietf.org] On >>>>> Behalf Of Scott Orton >>>>> Sent: Friday, April 01, 2011 12:18 AM >>>>> To: Elwell, John; Charles Eckel (eckelcu); Parthasarathi R >> (partr); >>>>> siprec@ietf.org >>>>> Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 >>>>> >>>>> John, >>>>> Thanks for the information. >>>>> >>>>> In that case I would like to see the CS group be >> made optional. >>>>> Rather than the CS pointing to the CS Group, I would like to >>> suggest >>>>> that the CS point to the RS and have the CS group stand >>>> alone where it >>>>> would just have its own ID and then a list of CS ids that belong >> to >>>> the >>>>> group. >>>>> >>>>> Scott >>>>> >>>>> -----Original Message----- >>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>>>> Sent: Thursday, March 31, 2011 11:50 AM >>>>> To: Scott Orton; Charles Eckel (eckelcu); Parthasarathi >> R (partr); >>>>> siprec@ietf.org >>>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 >>>>> >>>>> Scott, >>>>> >>>>> Some folks wanted to be able to group related CSs together >>>> (e.g., a CS >>>>> between a customer and an agent and a second CS >> resulting from the >>>>> customer being transferred to a second agent). I will >> leave it to >>>> those >>>>> folks to add to this. >>>>> >>>>> John (chair hat on) >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Scott Orton [mailto:sorton@broadsoft.com] >>>>>> Sent: 31 March 2011 17:43 >>>>>> To: Elwell, John; Charles Eckel (eckelcu); Parthasarathi R >>>>>> (partr); siprec@ietf.org >>>>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 >>>>>> >>>>>> John, Charles, Partha, >>>>>> I have a question. What is the purpose of the CS Group? I >>>>>> do not see it adding anything to the metadata. To me it seems >>>>>> that the whole purpose of the metadata is to describe the >>>>>> recording session to the SRS. Looking at the requirements I >>>>>> see 3 relationships that the spec is attempting to describe: >>>>>> >>>>>> A one to one relationship - one communication session to one >>>>>> recording session >>>>>> A one to many relationship - one communication session with >>>>>> multiple Recording sessions >>>>>> - one Recording session made up of >>>>>> multiple communications sessions >>>>>> >>>>>> The current metadata format allows all of these and I do not >>>>>> see what the group is adding. >>>>>> >>>>>> Regards, >>>>>> Scott >>>>>> >> > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From john.elwell@siemens-enterprise.com Wed Apr 6 13:09:01 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30E0B28C106 for ; Wed, 6 Apr 2011 13:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hoJ3tEGMkF5J for ; Wed, 6 Apr 2011 13:08:55 -0700 (PDT) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 6D53128C116 for ; Wed, 6 Apr 2011 13:08:54 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-4034297; Wed, 6 Apr 2011 22:10:30 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 23A8C1EB82B4; Wed, 6 Apr 2011 22:10:30 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 6 Apr 2011 22:10:30 +0200 From: "Elwell, John" To: "Ram Mohan R (rmohanr)" , Scott Orton , "Charles Eckel (eckelcu)" , "Parthasarathi R (partr)" , "siprec@ietf.org" Date: Wed, 6 Apr 2011 22:10:35 +0200 Thread-Topic: [siprec] comments on draft-ram-siprec-metadata-04 Thread-Index: Acvr6KoPYFMcjPlASk+pOtN532GUhgBO/qTgAD5pH0AAJpm4YABBRncAAAC5KqAAABl2UAAAlZ6wAAOH8AAAVJiJUADNFEegAAQ3wAAAAh9dwAACCc/AAAcuO1A= Message-ID: References: <21866C7FE177A4449B9136B5B24B1B130BC011290A@EXMBXCLUS01.citservers.local> <21866C7FE177A4449B9136B5B24B1B130BC011294A@EXMBXCLUS01.citservers.local> <35BCE99A477D6A4986FB2216D8CF2CFD05DD8C0C@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD05EF92EF@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD05EF9357@XMB-BGL-417.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD05EF9357@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] comments on draft-ram-siprec-metadata-04 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2011 20:09:01 -0000 Yes, that is what I meant, but I see Paul has in mind some more major chang= es. John=20 > -----Original Message----- > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com]=20 > Sent: 06 April 2011 17:48 > To: Elwell, John; Scott Orton; Charles Eckel (eckelcu);=20 > Parthasarathi R (partr); siprec@ietf.org > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 >=20 > Ok. I got your point. I am fine with this. The updated portion will > look like below >=20 > +-------------------------------+ 1 > | Recording Session (RS) |---------------+ > +-------------------------------+ | > |1..* | > | | > |0..* | > +--------------+ +-----------------+ | > |Communication | | Communication | 1 |=20 > | Session (CS) |----------| Session (CS) |---| > | Group |0..1 1..*| | | 0..* +----------+ > +--------------+ +-----------------+ |------|Extension | > 1| | 0..* |1..* | | Data | > | | 2..* |0..* | +----------+ > 0..*| > +---------+ > |Extension| =20 > | Data | > +---------+ >=20 > CSG can use the indirect relationship (via a CS). >=20 > Ram >=20 >=20 > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Wednesday, April 06, 2011 9:17 PM > > To: Ram Mohan R (rmohanr); Scott Orton; Charles Eckel (eckelcu); > > Parthasarathi R (partr); siprec@ietf.org > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > >=20 > > Ram, > >=20 > > I am not sure this answers my question. In the model you=20 > drew below, a > > CSG has both a direct relationship with an RS and an indirect > > relationship (via a CS). I was questioning whether we could=20 > remove the > > direct relationship, on the basis that the indirect relationship is > > sufficient. > >=20 > > John (as individual) > >=20 > >=20 > > > -----Original Message----- > > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > > Sent: 06 April 2011 15:52 > > > To: Elwell, John; Scott Orton; Charles Eckel (eckelcu); > > > Parthasarathi R (partr); siprec@ietf.org > > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > > > > > Hi John, > > > > > > Yes We have an indirect relationship in the current model. However > in > > > the current model it is REQUIRED to have a CSG as CS is > > > connected to RS > > > through CSG. However not all use cases would need CSG, IOW > > > CSG has to be > > > optional and there should be direct association from CS to RS > > > even when > > > CSG is absent. > > > > > > With the below associations we will have: > > > - An instance of RS can have Zero or more CSG blocks. > > > - An instance of RS can have Zero or more CS blocks. > > > - If a CSG is present it will have 1 or more CS. > > > - Each CS can be associated with Zero or 1 CSG. > > > > > > Let me know if you have any concerns. > > > > > > Regards, > > > Ram > > > > > > > -----Original Message----- > > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > Sent: Wednesday, April 06, 2011 6:16 PM > > > > To: Ram Mohan R (rmohanr); Scott Orton; Charles Eckel (eckelcu); > > > > Parthasarathi R (partr); siprec@ietf.org > > > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > > > > > > > I am OK in principle, but I wonder whether there really > > > needs to be a > > > > relationship between CSG and RS. Isn't that relationship an > > indirect > > > > relationship via CS? > > > > > > > > John (as individual) > > > > > > > > > > > > > -----Original Message----- > > > > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > > > > Sent: 03 April 2011 18:13 > > > > > To: Scott Orton; Elwell, John; Charles Eckel (eckelcu); > > > > > Parthasarathi R (partr); siprec@ietf.org > > > > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > > > > > > > > > Scott, > > > > > > > > > > I am ok to make this change to the model. I would like to > > > hear from > > > > > others if they have any issues in incorporating this change in > > the > > > > > model. > > > > > > > > > > The updated portion of the model will look like > > > > > > > > > > > > > > > +-------------------------------+ 1 > > > > > | Recording Session (RS) |---------------+ > > > > > +-------------------------------+ | > > > > > | 1..* |1..* | > > > > > | | | > > > > > | 0..* |0..* | > > > > > +--------------+ +-----------------+ | > > > > > |Communication | | Communication | 1 | > > > > > | Session (CS) |----------| Session (CS) |---| > > > > > | Group |0..1 1..*| | | 0..* > > > +----------+ > > > > > +--------------+ +-----------------+ > > > |------|Extension > > > | > > > > > 1| | 0..* |1..* | =20 > | Data > > > | > > > > > | | 2..* |0..* | > > > +----------+ > > > > > 0..*| > > > > > +---------+ > > > > > |Extension| > > > > > | Data | > > > > > +---------+ > > > > > > > > > > The only change in the association is : > > > > > A CS MUST be associated with zero or one CS-Group > > > > > > > > > > Rest of the associations remain same. Further the association > > > > > between CS > > > > > and RS remains same as what is between CS-Group and RS. > > > > > > > > > > Comments ? > > > > > > > > > > Regards, > > > > > Ram > > > > > > > > > > > -----Original Message----- > > > > > > From: siprec-bounces@ietf.org > > > [mailto:siprec-bounces@ietf.org] On > > > > > > Behalf Of Scott Orton > > > > > > Sent: Friday, April 01, 2011 12:18 AM > > > > > > To: Elwell, John; Charles Eckel (eckelcu); Parthasarathi R > > > (partr); > > > > > > siprec@ietf.org > > > > > > Subject: Re: [siprec] comments on=20 > draft-ram-siprec-metadata-04 > > > > > > > > > > > > John, > > > > > > Thanks for the information. > > > > > > > > > > > > In that case I would like to see the CS group be > > > made optional. > > > > > > Rather than the CS pointing to the CS Group, I would like to > > > > suggest > > > > > > that the CS point to the RS and have the CS group stand > > > > > alone where it > > > > > > would just have its own ID and then a list of CS ids that > > belong > > > to > > > > > the > > > > > > group. > > > > > > > > > > > > Scott > > > > > > > > > > > > -----Original Message----- > > > > > > From: Elwell, John=20 > [mailto:john.elwell@siemens-enterprise.com] > > > > > > Sent: Thursday, March 31, 2011 11:50 AM > > > > > > To: Scott Orton; Charles Eckel (eckelcu); Parthasarathi > > > R (partr); > > > > > > siprec@ietf.org > > > > > > Subject: RE: [siprec] comments on=20 > draft-ram-siprec-metadata-04 > > > > > > > > > > > > Scott, > > > > > > > > > > > > Some folks wanted to be able to group related CSs together > > > > > (e.g., a CS > > > > > > between a customer and an agent and a second CS > > > resulting from the > > > > > > customer being transferred to a second agent). I will > > > leave it to > > > > > those > > > > > > folks to add to this. > > > > > > > > > > > > John (chair hat on) > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Scott Orton [mailto:sorton@broadsoft.com] > > > > > > > Sent: 31 March 2011 17:43 > > > > > > > To: Elwell, John; Charles Eckel (eckelcu); Parthasarathi R > > > > > > > (partr); siprec@ietf.org > > > > > > > Subject: RE: [siprec] comments on=20 > draft-ram-siprec-metadata- > > 04 > > > > > > > > > > > > > > John, Charles, Partha, > > > > > > > I have a question. What is the purpose of the=20 > CS Group? I > > > > > > > do not see it adding anything to the metadata. To me it > seems > > > > > > > that the whole purpose of the metadata is to describe the > > > > > > > recording session to the SRS. Looking at the=20 > requirements I > > > > > > > see 3 relationships that the spec is attempting=20 > to describe: > > > > > > > > > > > > > > A one to one relationship - one communication=20 > session to one > > > > > > > recording session > > > > > > > A one to many relationship - one communication=20 > session with > > > > > > > multiple Recording sessions > > > > > > > - one Recording session made up > of > > > > > > > multiple communications sessions > > > > > > > > > > > > > > The current metadata format allows all of these=20 > and I do not > > > > > > > see what the group is adding. > > > > > > > > > > > > > > Regards, > > > > > > > Scott > > > > > > > > > > > = From pkyzivat@cisco.com Wed Apr 6 14:26:16 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1A1B3A69B9 for ; Wed, 6 Apr 2011 14:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jlHnyCDt8Gip for ; Wed, 6 Apr 2011 14:26:15 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 6B9A63A6956 for ; Wed, 6 Apr 2011 14:26:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=4849; q=dns/txt; s=iport; t=1302125280; x=1303334880; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=PiOzmkaCsPN3k/jQj/v/CeSkPpLvVFSxjQHAjtluAhc=; b=kdGnpYJRvn4ltIri+/EeC6t9qVj2SVHg66Y97fqrKaqET0tWlEyDo/0v rY5S2tHFs3V6MkVIJtsv9fYwjsWK1fxrgCoBjVxJlYwy0Elelr3IT56UJ il2vt+x8a9tbxZLo+findhJtI++ZhaI/P0vKcDxeqresudIK7ARxmyRo9 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAM7ZnE2tJV2c/2dsb2JhbAClfnenKZxZhWwEjTyDYw X-IronPort-AV: E=Sophos;i="4.63,312,1299456000"; d="scan'208";a="228920101" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-1.cisco.com with ESMTP; 06 Apr 2011 21:27:59 +0000 Received: from [10.86.240.127] (che-vpn-cluster-1-127.cisco.com [10.86.240.127]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p36LRwJ8021308 for ; Wed, 6 Apr 2011 21:27:58 GMT Message-ID: <4D9CDADD.1020403@cisco.com> Date: Wed, 06 Apr 2011 17:27:57 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "siprec@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [siprec] start/stop times & the metamodel X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2011 21:26:16 -0000 In Prague, one of the open issues was around start/stop times. The format draft floated the possibility of having explicit start/stop times signaled for each of the metatdata elements. But then we asked for feedback on which make sense. IMO explicit start/stop times make more sense for some things than others. One place where we potentially have explicit times to report with the dialogs that constitute a CS. Each such dialog presumably has a start and stop time observable by the SRC, which might differ, at least a bit, from the corresponding signaling on the RS. We might want to report those times. Or, since we abstract the CS away from the dialog, we might want to report the start time of the first dialog in the CS as the CS start time, and the stop time of the last dialog in the CS as the CS stop time. Similarly, we have abstracted media streams away from the media streams in the sip dialogs that make up the CS. We might want to report the start time of a media stream as the time (according to the CS) of the first participant to a new media stream, and the stop time as the time that the last participant leaves the media stream. There are several things that complicate this: - Do we consider the case of a stream that starts with recvonly or inactive participants, and only later gets a sender? If so, is the start time of the stream when the first participant arrived, or when the first sender arrived? - How do we get the clock times for the media streams? IIUC the correct ones are in the RTP/RTCP, but the reporting of these events is driven by the signaling, and we don't have good sync between those. (E.g. media could start flowing before the corresponding signaling, and we would like to include that if we can figure it out.) So, even if the clocks used for media and signaling are in sync, we might see media packets arrive with a timestamp prior to the timestamp for the signaling that indicates the send state of the participant. This could cause trouble in playback. - There isn't any guarantee that the clock used for signaling messages is synchronized with the clock used in RTP/RTCP. - There isn't any guarantee that there will be any RTCP at all, to provide correlation of the RTP to clocktime. The best I can see to deal with all of this is: - All the metadata messages should be timestamped by the SRC using its local clock. This is easily achieved by the Date header in the sip message. - Changes to a CS, including changes of participants, should be explicitly tagged with the time they occurred in the CS signaling, according to the SRC's clock. (If that is unavailable for some reason, then use the time the SRC became aware of it.) - We could provide a metadata update element to indicate end of a CS, but I suggest this just be shorthand for indicating removal of all participants from it. (While its possible to mark that the CS is truly ended, that simply introduces an error case if added metadata about it is subsequently sent.) The actual start/stop time would be determined by the SRS based on the timestamps of first and last data about it. - Changes to media streams should similarly be tagged with the time they occurred in the CS signaling. Each participant relationship change (send, receive, inactive,) will be there. The actual start/stop time of the media stream again would be derived by the SRS. - CS-Groups can simply be tagged by the timestamps of the updates that put CSs into them. Explicit start/stop times don't seem useful. If desired, the SRS can derive start/stop times from the start/stop times of the contained stuff. - I now think that CS-Groups should not be "contained" within a recording. This just seems to introduce unnecessary error conditions, and limitations on future enhancements. The lifetime of CS-Groups will probably be naturally limited by the ability of the SRC to remember the IDs of old ones. For instance, if a CS-G is created during one Recording, and then another CS is added to it from a different recording session, would we prefer to fail that, or just allow it? (I think allow.) - Rather, I think every update transmitted during a recording session can be tagged with a link to the metadata of the recording session it came from. This need not be explicit - the SRS can do it automatically. The recording session entity itself will also have a start/stop time which is the start/ stop of the RS dialog as observed by the SRS. (Note the above doesn't solve the problem of getting correct clock times for RTP media. If anyone has a suggestion for this I'm all ears.) Thanks, Paul From pkyzivat@cisco.com Wed Apr 6 14:40:46 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8FC93A67E9 for ; Wed, 6 Apr 2011 14:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lfm9yR7W+QYX for ; Wed, 6 Apr 2011 14:40:45 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 81AE43A67A8 for ; Wed, 6 Apr 2011 14:40:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=4615; q=dns/txt; s=iport; t=1302126149; x=1303335749; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=1xx91YZYLk0wBU7LK4YL88RRfvvYtJgm3GOCVPoL0no=; b=hmYQ0Sp3VO/1VcaAEzJ3LCDb9XbbVbhGwZqulwmldahb0XgCIK+SqjBM biefYLLUNDuSUQN41KmLnzehaRuRgKMIuyxizO0MXiZCYccf8o6M8yMNy ZUlj8cXrsXQQtxDAol233bNVTpfXMGpnaBSkftXhOMbeMsYj4IU94/QfT 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUBABbdnE2rRDoH/2dsb2JhbACYM41Md6cVnF+FbASNPINj X-IronPort-AV: E=Sophos;i="4.63,312,1299456000"; d="scan'208";a="425169644" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-1.cisco.com with ESMTP; 06 Apr 2011 21:42:29 +0000 Received: from [10.86.240.127] (che-vpn-cluster-1-127.cisco.com [10.86.240.127]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p36LgSRZ012834 for ; Wed, 6 Apr 2011 21:42:29 GMT Message-ID: <4D9CDE43.4040909@cisco.com> Date: Wed, 06 Apr 2011 17:42:27 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: siprec@ietf.org References: <4D89D801.8040308@ericsson.com> <07465C1D981ABC41A344374066AE1A2C38AB466348@TLVMBX01.nice.com> <07465C1D981ABC41A344374066AE1A2C38AB4669F4@TLVMBX01.nice.com> In-Reply-To: <07465C1D981ABC41A344374066AE1A2C38AB4669F4@TLVMBX01.nice.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] AD review: draft-ietf-siprec-req-08 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2011 21:40:46 -0000 Just to be clear - do you consider mandatory to implement distinct from mandatory to *use*? (IOW, that an administrator deploying siprec compliant products might configure them to not use some of these features.) IMO: - most things are mandatory to implement in the SRS. Which are used is determined mostly by behavior of the SRC. We aren't defining the form or content of the actual recorded data/metadata, so the only definition of compliance we have will be based on how it interacts with an SRC. - the basic mechanisms are probably mandatory to implement in the SRC, but there should be a lot of latitude. There are many ways to hook an SRC into CSs, so there can be a lot of special purpose SRCs that focus on a particular way of fitting in. Some of them will have more access to metadata than others. If they can't discover a certain sort of metadata then they will not be delivering it, and so don't need support for doing so. - an SRC implementation may provide ways for an administrator to turn off a variety of things so that they aren't used. But we will have to draw a line somewhere - at some point if you have turned too much off it will cease to be identifiable as an SRC. Thanks, Paul On 3/28/2011 4:42 AM, Leon Portman wrote: > Hi, > > Following AD comments, I am proposing to indicate that following requirements are mandatory to implement, in contrast for other requirements that are mandatory for the protocol to support but optional for implementation depending use cases: > > 1. REQ-001 - implement SIP based protocol > 2. REQ-012 - metadata reporting support > 3. REQ-013 - map between participant and media > 4. REQ-022 - wall clock reporting for media synchronization > 5. REQ-023 - wall clock, assuming pause/resume is used > 6. REQ 27-30 are mandatory security requirements > > Leon > > -----Original Message----- > From: Leon Portman > Sent: Monday, March 28, 2011 10:39 AM > To: 'Elwell, John'; Gonzalo Camarillo; siprec@ietf.org; Ken Rehor (krehor) (krehor@cisco.com) > Subject: RE: [siprec] AD review: draft-ietf-siprec-req-08 > >> -----Original Message----- >> From: siprec-bounces@ietf.org >> [mailto:siprec-bounces@ietf.org] On Behalf Of Gonzalo Camarillo >> Sent: Wednesday, March 23, 2011 1:23 PM >> To: siprec@ietf.org >> Subject: [siprec] AD review: draft-ietf-siprec-req-08 >> >> Hi, >> >> the SIPREC WG requested the publication of the following draft a few >> days ago. Please, find below my AD review. >> >> https://datatracker.ietf.org/doc/draft-ietf-siprec-req/ >> >> Given that the draft contains both requirements and use cases, you may >> want to edit the title so that it reads "Use Cases and Requirements >> for ..." >> >> Typically, Section 1 contains the Introduction and Section 2 the >> terminology. You may want to swap both sections. >> >> Most of the requirements are phrased so that they describe >> capabilities that need to be supported by the system (e.g., the >> mechanism MUST provide the SRS with the means to ...) but that do not >> need to be necessarily used (e.g., a particular use case may not make >> use of that functionality). However, some requirements are phrased so >> that the functionality needs to be used (e.g., the mechanism MUST >> provide the SRS the wall clock time ...). Requirements 12, 22, 23, 27, >> 28, and 29 seem to fall into the latter category. Could you please >> check whether that was the intention with all those requirements? >> >> A few requirements relate to the security and privacy related >> properties of the SRC-SRS interface (e.g., requirements 24 and 29). >> However, the draft does not discuss how the security and privacy of >> that interface relate to the security and privacy level used for the >> CS being recorded. >> For example, can the confidentiality level of the media going from the >> SRC and the SRS be lower than that of the media flowing between the >> actual participants of the CS? If you decide there should not be a >> requirement on this area, you need to at least discuss this issue >> (probably in Sections 6 or 7). >> >> Once you address these comments, I will request the IETF-wide last >> call for this draft. >> >> Thanks, >> >> Gonzalo >> >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >> > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From pkyzivat@cisco.com Wed Apr 6 14:47:09 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51FCF3A67D7 for ; Wed, 6 Apr 2011 14:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GwjeoISUe57C for ; Wed, 6 Apr 2011 14:47:07 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 4D3823A67A8 for ; Wed, 6 Apr 2011 14:47:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=11477; q=dns/txt; s=iport; t=1302126531; x=1303336131; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=5mkM6q3QEPA04OziJjYuHVBwq8ZEDDMIGWjEpAsxsYQ=; b=D8hsUP8PUItgIsm8mGlh+urcFPQ0zdJR8BKZpHbsGN5a5ootgmRdVoPJ 6R2I9hnoEMSZMXp0gcJ/Lht+CDgNeBhm9krAMs4bU3i6INhpeWvcVC2uo oJsNZ5vB6WBTwisSB6N7fIAy5MYFfxyw1rgXb//cIyegvJjoISyAEuMtU M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUBAILenE2tJXHB/2dsb2JhbACYM41Md4h5niCcX4VsBI08g2M X-IronPort-AV: E=Sophos;i="4.63,312,1299456000"; d="scan'208";a="228922178" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rtp-iport-1.cisco.com with ESMTP; 06 Apr 2011 21:48:50 +0000 Received: from [10.86.240.127] (che-vpn-cluster-1-127.cisco.com [10.86.240.127]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p36LmnCl015387 for ; Wed, 6 Apr 2011 21:48:50 GMT Message-ID: <4D9CDFC0.9070300@cisco.com> Date: Wed, 06 Apr 2011 17:48:48 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 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] extensionData in XML X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2011 21:47:09 -0000 On 4/6/2011 8:57 AM, Elwell, John wrote: > Yes, I would be keen to hear Peter's or other opinions, but one other point. One of the properties of XML is that it is human-readable. Having extension data as a child element of the element representing the object to which it applies seems, in my opinion, to make it more readable. Having extension data as a separate element, with a link to the element to which it applies, seems hard for a human reader, particularly if the link is a long, random string. IMO human readability of the xml is a secondary/tertiary concern. (SIP is in theory readable, but real sip on the wire tends to be difficult to read due to need to match up non-ergonomic numeric addresses and tags from one message to another.) I'm inclined to agree it would be better to embed extensions into the basic elements, but not primarily due to readability. IMO extensions should function as much like the predefined parts as possible. (Today's extension may become common usage tomorrow.) I just don't know enough xml to define this "correctly". Thanks, Paul > John (as individual) > > >> -----Original Message----- >> From: Parthasarathi R (partr) [mailto:partr@cisco.com] >> Sent: 06 April 2011 10:16 >> To: Elwell, John; Hadriel Kaplan >> Cc: siprec@ietf.org; Jain, Rajnish; Peter Saint-Andre (psaintan) >> Subject: RE: [siprec] extensionData in XML >> >> John, >> >> Please read inline >> >> Thanks >> Partha >> >> -----Original Message----- >> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >> Sent: Wednesday, April 06, 2011 2:02 PM >> To: Parthasarathi R (partr); Hadriel Kaplan >> Cc: siprec@ietf.org; Jain, Rajnish >> Subject: RE: [siprec] extensionData in XML >> >> I already posted on this topic on the other thread. Partha >> states below >> an additional motivation for handling extension data in the way >> specified in the current I-D. My counter argument is that anyone >> specifying particular extension data could specify the expected >> behaviour when extension data is present in an object and then absent >> when that object is updated. For some types of metadata it >> could be that >> absence means it no longer applies, and for other types of metadata it >> could be that absence means it has not changed. >> >> Currently, metadata format draft XML element is written with >> the basics that "it is no longer applies" in case specific element is >> absent in the update. The question is how the information of >> extensiondata absence means "it is no longer applies" or "it has not >> changed" has to be passed between SRC and SRS. Here, there is >> a need of >> common understanding between SRC and SRS or else the >> information will be >> misunderstand even though both parties understand the specific >> extension. >> >> The current extensiondata is taken the route of all other >> metadata block >> XML element definition. There may be better way to represent in >> extensiondata XML element apart from creating new metadata block with >> URN UUID. I'm including Peter for his advise on XML front. >> >> The latter approach would avoid the need for repeating large >> quantities >> of metadata each time there is a minor change to an object. >> >> John (as individual) >> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org >>> [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi >> R (partr) >>> Sent: 03 April 2011 19:46 >>> To: Hadriel Kaplan >>> Cc: siprec@ietf.org; Jain, Rajnish >>> Subject: Re: [siprec] extensionData in XML >>> >>> Hadriel, >>> >>> I guess we have common understaning to the extend that the >> intention >>> is to send some extensiondata (Unknown) attribute by SRC >> which may or >>> may not understand by SRS and also for the usage of xs:any as the >>> solution. Few stuff are missing in yours proposal w.r.t >> partial data >>> passing of extensiondata: >>> >>> The question is whether there is a need to pass the extension data >>> during every time the corresponding metadata block is passed or >>> updated. For example, CS metadata block sends extension >> data specific >>> to call center data like Agent is remote or local, agent or >> customer >>> initiated call (direction) during the CS block creation >> (INVITE) and >>> these constant information in extensiondata is not required to be >>> passed in each update of CS metadata like adding video >> stream in the >>> mid-session. >>> >>> The current model allows to pass extensiondata only during >> the initial >> >>> CS block creation and there is no need to update or resend while CS >>> block is getting updated with other CS information. IMO, >> The current >>> extensiondata mechanism is required as SIPREC puts lot of >> call centre >>> specific attributes proposed during metadata model draft review as >>> outside the scope of SIPREC and most of the attributes >> mentioned are >>> constant within the scope of session. >>> >>> Also, it is possible to pass update only extension data within RS >>> session without impacting parent element. Please let me >> know your and >>> others opinion whethter it is fine to continue with the current >>> extension-data element or to move xs:any element to each of the >>> metadata block. >>> >>> Thanks >>> Partha >>> ________________________________ >>> >>> From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] >>> Sent: Sat 4/2/2011 6:19 PM >>> To: Parthasarathi R (partr) >>> Cc: Jain, Rajnish; siprec@ietf.org >>> Subject: Re: [siprec] extensionData in XML >>> >>> >>> >>> Hi Partha, >>> I think you're missing my point (or I'm missing yours) - you can do >>> all of that without specifying an "extensionData" XML element. >>> Unknown XML elements are simply ignored by the other side, so Cisco >>> can add a "ciscoPrivateData" XML element wherever it wants >> and send it >> >>> to an Acme; and that private element will be ignored by Acme while >>> everything else will continue to work. Which I think is >> the behavior >>> you want, right? >>> >>> -hadriel >>> >>> >>> On Apr 1, 2011, at 10:37 AM, Parthasarathi R (partr) wrote: >>> >>>> Hadriel/Raj, >>>> >>>> Extensiondata XML is provided as per Metadata model >>> extensiondata block. >>>> During the initial discussion of metadata model draft, we >>> realized that >>>> lot of attributes specified for recording are call center >>> specific or >>>> specific domain related and it is outside the scope of IETF >>> SIPREC but >>>> it is required for those specific solution to work. >>> Extensiondata XML >>>> element helps to meet those requirement. >>>> >>>> Extensiondata is provided with URN UUID to pass or not pass >>>> independently in partial data. But it is open item whether >>> extensiondata >>>> has to be within specific metadatablock or not. >>>> >>>> Please read inline for more comments. >>>> >>>> Thanks >>>> Partha >>>> >>>> -----Original Message----- >>>> From: siprec-bounces@ietf.org >>> [mailto:siprec-bounces@ietf.org] On Behalf >>>> Of Jain, Rajnish >>>> Sent: Friday, April 01, 2011 6:41 PM >>>> To: Hadriel Kaplan; siprec@ietf.org >>>> Subject: Re: [siprec] extensionData in XML >>>> >>>> There may be such motivation from how the CSTA standards >>> are specified. >>>> They have an element called privateData for each message. It is a >>>> placeholder for any non-standardized extensions. This could >>> be legacy >>>> and may not mean much for the modern text based protocols. >>>> >>>> I really didn't get the reason why is it not >>> require for modern >>>> text based protocols. This is more like generic param in >>> SIP or xs:any >>>> in XML. RFC 6120 is a new RFC which has the similar usage. >>>> >>>> >>>> That said, I think you're right (this generally applies >> to any text >>>> based protocols and is the fundamental basis for forward/backward >>>> compatibility in such protocols). >>>> >>>> Raj >>>> >>>> >>>> ----------------------------------------------------- >>>> Please consider the environment before printing this email. >>>> >>>>> -----Original Message----- >>>>> From: siprec-bounces@ietf.org >> [mailto:siprec-bounces@ietf.org] On >>>>> Behalf Of Hadriel Kaplan >>>>> Sent: Thursday, March 31, 2011 8:43 PM >>>>> To: siprec@ietf.org >>>>> Subject: [siprec] extensionData in XML >>>>> >>>>> Howdy, >>>>> With regards to the extensionData concept and XML, I have >>> a few basic >>>>> questions. I am by no means an XML expert so it could >>> just be my lack >>>> >>>>> of knowledge which makes me confused. If so, just tell >> me to RTFM. >>>>> >>>>> draft-ram-siprec-metadata-04 says in section 4.6: >>>>> A recording metadata object contains additional data not >>> specified >>>>> as >>>>> part of siprec. This is intended to accommodate >> future standards >>>>> track extensions, as well as vendor and user specific >> extensions. >>>>> The mechanism MUST provide a means of unambiguously >>> distinguishing >>>>> such extension data. >>>>> >>>>> What confuses me is I didn't think XML had to do such >>> machinations to >>>>> accommodate this need. I thought we could just specify >> in our RFCs >> >>>>> that unknown XML elements and attributes MUST be >> ignored, so that >>>>> future RFCs could add them without having to leave >>> specific "blob" XML >>>> >>>>> elements to carry such data. Or at least that's what >> we've done so >> >>>>> far in SIP RFCs with XML bodies, afaik. >>>>> namespace model that could be used to disambiguate proprietary >>>>> elements from standard ones. If both of those theories >>> are correct, >>>>> why do we need to define an extensionData element? >>>>> >>>>> -hadriel >>>>> >>>>> _______________________________________________ >>>>> siprec mailing list >>>>> siprec@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/siprec >>>> >>>> DISCLAIMER: This e-mail may contain information that is >>> confidential, >>>> privileged or otherwise protected from disclosure. If you >> are not an >> >>>> intended recipient of this e-mail, do not duplicate or >>> redistribute it >>>> by any means. Please delete it and any attachments and >>> notify the sender >>>> that you have received it in error. Unintended recipients >>> are prohibited >>>> from taking action on the basis of information in this >> e-mail.E-mail >> >>>> messages may contain computer viruses or other defects, >> may not be >>>> accurately replicated on other systems, or may be >>> intercepted, deleted >>>> or interfered with without the knowledge of the sender or >>> the intended >>>> recipient. If you are not comfortable with the risks >> associated with >> >>>> e-mail messages, you may decide not to use e-mail to >>> communicate with >>>> IPC. IPC reserves the right, to the extent and under >> circumstances >>>> permitted by applicable law, to retain, monitor and >> intercept e-mail >> >>>> messages to and from its systems. >>>> _______________________________________________ >>>> siprec mailing 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@cisco.com Wed Apr 6 14:49:26 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 606573A67D9 for ; Wed, 6 Apr 2011 14:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.549 X-Spam-Level: X-Spam-Status: No, score=-110.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XosP9wwyWIrV for ; Wed, 6 Apr 2011 14:49:25 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 72E153A67A8 for ; Wed, 6 Apr 2011 14:49:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=3888; q=dns/txt; s=iport; t=1302126669; x=1303336269; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=b+OnQ5COwotjpK2Um2TLirwoVwdvHCpjfchXm5pJPNg=; b=TE3gsoXa5eBRzRVgx4e0N4ez1O9NTWrdKkA40KolgtV3rPazjvuUtGcb ZaWQk9nAkqxYuFTeeyPe/dILy8ilz67guhmE0nP3ZCrmTIIK/ljm5uSL2 SRjOHs1sdu9Lx973n2mKkzt/e0GX1U+dDQCo4XuMq1M1Kl1Q2dq2KBzbk M=; X-IronPort-AV: E=Sophos;i="4.63,312,1299456000"; d="scan'208";a="353465432" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by sj-iport-5.cisco.com with ESMTP; 06 Apr 2011 21:51:09 +0000 Received: from [10.86.240.127] (che-vpn-cluster-1-127.cisco.com [10.86.240.127]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p36Lp8Kg024352; Wed, 6 Apr 2011 21:51:08 GMT Message-ID: <4D9CE04B.7030704@cisco.com> Date: Wed, 06 Apr 2011 17:51:07 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Muthu ArulMozhi Perumal (mperumal)" References: <4D9C711B.6070205@cisco.com> <1D062974A4845E4D8A343C65380492020523BAF6@XMB-BGL-414.cisco.com> In-Reply-To: <1D062974A4845E4D8A343C65380492020523BAF6@XMB-BGL-414.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: siprec@ietf.org Subject: Re: [siprec] RTP model X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2011 21:49:26 -0000 On 4/6/2011 10:57 AM, Muthu ArulMozhi Perumal (mperumal) wrote: > I agree we should keep the models open to cater to different use-cases. > However, for the most common ones we anticipate, I think we should have > clear guidelines/recommendations on how it must/should/may work to > achieve basic interop among implementations of that model. For e.g, the > translator model for SRC looks a simple one that would cater to a large > number of cases and we might want to have clear > guidelines/recommendations on how RTP and RTCP should be handled for it. I don't know a lot about RTP, but the above seems right to me - each different way the SRC might relate to the RTP will need some specification. Thanks, Paul > thanks, > Muthu > > |-----Original Message----- > |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Paul Kyzivat (pkyzivat) > |Sent: Wednesday, April 06, 2011 7:27 PM > |To: siprec@ietf.org > |Subject: Re: [siprec] RTP model > | > |I am definitely not an expert on this subject, but ISTM that making a > |choice about one of these models would inordinately limit > implementation > |choices for the SRC. IMO we want to provide a lot of latitude for SRC > |implementation, even if it means complicating life for the SRS. > | > | Thanks, > | Paul > | > |On 4/6/2011 4:05 AM, Elwell, John wrote: > |> There were discussions before and during the Prague meeting about > multiplexing media streams from > |different participants on to the same port. It became apparent that we > need a better understanding of > |the RTP model we are using first, before we can answer this. > |> > |> The question is whether the SRC acts as a translator or as a mixer or > end system. > |> > |> A translator is defined in RFC 3550 as: > |> "An intermediate system that forwards RTP packets > |> with their synchronization source identifier intact. Examples > of > |> translators include devices that convert encodings without > mixing, > |> replicators from multicast to unicast, and application-level > |> filters in firewalls." > |> > |> A mixer or end system, in contrast, would assign new synchronisation > sources to RTP packets. > |> > |> The translator model seems to require less processing in the SRC - > RTP packets would just be > |forwarded unchanged to the SRC (i.e., the UDP packet would change but > its RTP payload would be > |unchanged). > |> > |> However, the translator model prevents some capabilities, e.g.: > |> - the SRC cannot transcode (e.g., if the SRS does not support the > codec used in the CS); > |> - the SRC cannot mix streams from different participants (e.g., to > reduce the bandwidth required on > |the RS path); > |> - the SRC cannot encrypt streams on the RS path if unencrypted on the > CS path or vice versa; > |> - the SRC cannot use different encryption keys on the CS path and the > RS path. > |> > |> Therefore, although the translator model might work in some > situations, it probably can't satisfy > |all requirements. > |> > |> Also with the translator model, we would need to be clear how RTCP > would work. Consider an SRC at a > |B2BUA. It receives RTP packets from party A, forwards them as a > translator to party B, and also > |forwards them as a translator to the SRS. The SRC will receive RTCP > packets from both party B and the > |SRS and needs to send RTCP packets to party A - how does the SRC handle > this? > |> > |> John (as individual) > |> > |> > |> _______________________________________________ > |> siprec mailing 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 partr@cisco.com Thu Apr 7 02:49:31 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C6C83A69BE for ; Thu, 7 Apr 2011 02:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.466 X-Spam-Level: X-Spam-Status: No, score=-9.466 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pt7tKFcEEXj8 for ; Thu, 7 Apr 2011 02:49:29 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id F1FD63A68F5 for ; Thu, 7 Apr 2011 02:49:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=6894; q=dns/txt; s=iport; t=1302169874; x=1303379474; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=/SRXvmv8sz6V9EjJ+vh8R4bXfkCXJh5auUXKlnyFDWc=; b=RnX+WEqtXBIYfXaMHnPRddw5f3P+TPq/vfG+2T7yO0sO16bNaQGvXPaT LEoyJlKiR2K8krHhb5bX/9sYWKPlnMEP3seAgEcwgcUaQdjo7xwrEQct/ 4xhWeTD9NifgnsoWgqLej4xzzDidqrr+G79w8j7AMNdyq0G+OUcaA0i1B 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At4AAKeInU2Q/khMgWdsb2JhbACYNI1LFAEBFiYlpV6ccoVtBIVOi2Y X-IronPort-AV: E=Sophos;i="4.63,315,1299456000"; d="scan'208";a="82579670" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 07 Apr 2011 09:51:12 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p379pAe4023119; Thu, 7 Apr 2011 09:51:12 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Apr 2011 15:21:10 +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, 7 Apr 2011 15:21:08 +0530 Message-ID: In-Reply-To: <4D9CB8E1.7030402@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Partial updates and identifiers Thread-Index: Acv0jVXI4ji2YTo+SquJ6T6YR3i+lQAdOkDg References: <4D9CB8E1.7030402@cisco.com> From: "Parthasarathi R (partr)" To: "Paul Kyzivat (pkyzivat)" , , "Elwell, John" X-OriginalArrivalTime: 07 Apr 2011 09:51:10.0320 (UTC) FILETIME=[52D20F00:01CBF509] Cc: "Peter Saint-Andre \(psaintan\)" , "Joe Hildebrand \(jhildebr\)" , Hadriel Kaplan Subject: Re: [siprec] Partial updates and identifiers X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 07 Apr 2011 09:49:31 -0000 John, Sorry for the lengthy mail but it contains lot of analysis and reasoning for this id approach.=20 Adding to Paul's point, I wish to give more background and reason for these globally unique id. Initially I had the impression that the single unique id (RS dialog-id) in the recording (session level) and some relevant natural id for the rest of the element will serve the purpose. There are usecases where this assumption fails. Even I have thought of using "xml:id" instead of URN UUID to avoid long string but xml:id may not end up with unique value always. Our analysis for URN UUID for each level is as follows and please provide your input in case id shall be tweaked: 1) Recording block: The reason for globally unique id is that multiple SRC with same id to single SRS.=20 Topology: SRC1 SRC2 | | | ----(RS1-ID1)-----SRS1 | ---(RS2-ID1)------------------SRS1 In the above topology, it is possible for ID1 is generated by both SRC1 and SRC2 at the same time.=20 2) group (CSG) block: Grouping mechanism (Hadriel session-id, Paul Jones Session-UUID) is outside the scope of SIPREC. URN UUID abstracts the exact mechanism to SRS and provides the information only about the group of CS from SRC perspective. It possible that group may span across multiple RS and It is up to SRS to group and view as single recording. Here, the single level id in the top will fail. The counter argument is to force the single RS having complete CSG but it*may not* be possible in SRC implementation. Here, xml:id will not serve the purpose 3) session (CS) block: At the immediate look, session falls exactly under recording block. Use case 3 of draft-ietf-siprec-req-09 illustrates where CS span across multiple RS. This requirement calls for unique id in session by which these session shall be viewed as single CS even though there is no group exists among them. IMO, in case session should not have globally unique id, then it is preferred to remove usecase 3 in the requirement. 4) participant block: It needs some id which may be AOR but AOR is not unique. IMO, xml:id may serve the purpose with session unique id. The trick exists for participant who are not associated with CS. We shall discuss and fine tune if required. 5) stream block: Label attribute shall be used as unique value but RFC 4574 does not mandate label attribute has to be unique across the dialog or CS and so, it may possible to change within RS and no normative statement to stop this implementation. IMO, xml:id may serve the purpose with session unique id. Here as well, We shall discuss and fine tune if required. 6) extensiondata block: This is tracked in the separate mail thread whether unique id is required or not. Let us close this as part of that mail thread. Including explicitly Hadriel, Peter, Joe in this mail thread as they have different view on this ID mechanism.=20 I had offline discussion with Hadriel in Prague after SIPREC meeting and my understanding of his major concern is that how SRS will be able to design the database in case partial update does not have recording (top) id information. I'll put more thought processing to close Hadriel concern of how top id has to be tracked in case partial update by which SRS implementation will be simplified in terms of aggregation maintenance. Thanks Partha -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat (pkyzivat) Sent: Thursday, April 07, 2011 12:33 AM To: siprec@ietf.org Subject: Re: [siprec] Partial updates and identifiers John, For the moment we have proposed that the ids be conveyed in the form of URIs that are globally unique, and specifically that they be UUID URNs.=20 There is no dependency on the particular form of the URI, but specifying they must be UUID URNs makes it possible to perform some internal optimizations for storage. The UUID URN is a pretty inefficient encoding. A UUID can be expressed in 32 bits, so we could consider retaining UUIDs but alter the encoding if its really an issue. However I am far from convinced that the size of the IDs is going to be a major issue in the overall size of messages, so I think its probably premature to worry about it. Because the ids can be expressed in 32 bits, the SRC and SRS can store them internally that way, thus reducing the runtime cost of maintaining the data. The use of unique ids is a significant part of the overall approach to formatting updates. If somebody has a different concept in mind it could be useful to have an alternative proposal for the format. If we had two worked out approaches we could compare the tradeoffs in each. Thanks, Paul On 4/6/2011 10:24 AM, Elwell, John wrote: > Much of the discussion on draft-ram-metadata-format in Prague concerned the mechanism for performing partial updates and the use of identifiers. The draft permits partial updates by allowing individual objects (e.g., CS, participant, media stream) to be sent with updated content, without having to send again other objects that have not changed. So, for example, in a large conference, it would be possible to add or modify an individual participant object without having to send all the other participant objects again. I do not recall any opposition to this basic principle. > > However, to achieve this, every object requires an identifier, and it was asserted that these identifiers need to be globally unique for all time. Although this might be efficient for updating an individual object, when sending many objects (e.g., at the start of a CS or when refreshing the entire metadata), this can make the metadata very bulky. It depends, of course, on the format of the identifiers, and it was stated that there could be alternatives to UUID. Nevertheless, some people had concerns. These concerns also extended to the impact on the database where metadata is stored, since it might not be feasible to convert to a database-friendly mechanism for linking objects together. > > One alternative proposal during the meeting was to have a single unique identifier at the top level (for the RS) and use local identifiers for other objects. Thus when updating a single object, it would be necessary to include the top level identifier as well as one or more local identifiers. However, there were also concerns this might not fulfil actual or perceived future requirements. > > Please continue discussion on this. > > John (as chair) > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From partr@cisco.com Thu Apr 7 03:35:53 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 742C228C0F9 for ; Thu, 7 Apr 2011 03:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.065 X-Spam-Level: X-Spam-Status: No, score=-10.065 tagged_above=-999 required=5 tests=[AWL=0.534, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5QCCNHRzeKZi for ; Thu, 7 Apr 2011 03:35:52 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 583F928C113 for ; Thu, 7 Apr 2011 03:35:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=8005; q=dns/txt; s=iport; t=1302172656; x=1303382256; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=IYs3Tq0fIcyBmIsyd64jYq45LkNFcM6zinsGYxeudPs=; b=jvLDOU7IQsR+x684rVfQtAsj715y8JhBbYyqgPw5wAIKLFHxF17NRX9l eVrqvU1ErXfhUnQcCK3qk9wsjVm2ETV8Fm0KmD+aFGYBHRS4NRPCRayRD 1kX9be8RXBIWzoj6nm7shPywiHgiM0QZbX3OyYehdDZgYfZf+4HoY/WWu E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuwAALSSnU2Q/khNgWdsb2JhbACYNI1QFAEBFiYliHmcN5xphW0EhU6LZg X-IronPort-AV: E=Sophos;i="4.63,315,1299456000"; d="scan'208";a="24806432" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 07 Apr 2011 10:37:35 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p37AbW6k025590; Thu, 7 Apr 2011 10:37:34 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Apr 2011 16:06:53 +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, 7 Apr 2011 16:06:54 +0530 Message-ID: In-Reply-To: <4D9CBD8C.4010901@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] comments on draft-ram-siprec-metadata-04 Thread-Index: Acv0kBVIJHb7ZeT6Szm6WV4C4fEO8gAfxgZQ References: <21866C7FE177A4449B9136B5B24B1B130BC011290A@EXMBXCLUS01.citservers.local> <21866C7FE177A4449B9136B5B24B1B130BC011294A@EXMBXCLUS01.citservers.local> <35BCE99A477D6A4986FB2216D8CF2CFD05DD8C0C@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD05EF92EF@XMB-BGL-417.cisco.com> <4D9CBD8C.4010901@cisco.com> From: "Parthasarathi R (partr)" To: "Paul Kyzivat (pkyzivat)" , , "Ram Mohan R (rmohanr)" , "Elwell, John" X-OriginalArrivalTime: 07 Apr 2011 10:36:53.0491 (UTC) FILETIME=[B5E0BC30:01CBF50F] Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 07 Apr 2011 10:35:53 -0000 John/Ram, I see the issue without direct link between RS and CSG. It may be tough to correlate CSG to RS in SRS implementation. This issue is raised by Hadriel in terms of having single unique id for metadata format draft. I explained his concern in "Partial updates and identifiers" mail thread. Also another issue: SRS may be interested in knowing list of associated RS for a given CSG.=20 Thanks Partha -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat (pkyzivat) Sent: Thursday, April 07, 2011 12:53 AM To: siprec@ietf.org Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 John, I've been thinking about how everything relates to the RS, and that maybe we should make some more major changes. What I'm thinking is that none of the elements have a direct relationship to RS. Rather, each element is ultimately constructed as a time series of values delivered in updates. Its the updates that have a relationship to a RS - the one they are delivered in. That allows the possibility that not all the updates come from the same RS. I haven't drawn a model diagram here because the concept is still fuzzy. Its a trial balloon - to see what others think. Thanks, Paul On 4/6/2011 11:47 AM, Elwell, John wrote: > Ram, > > I am not sure this answers my question. In the model you drew below, a CSG has both a direct relationship with an RS and an indirect relationship (via a CS). I was questioning whether we could remove the direct relationship, on the basis that the indirect relationship is sufficient. > > John (as individual) > > >> -----Original Message----- >> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] >> Sent: 06 April 2011 15:52 >> To: Elwell, John; Scott Orton; Charles Eckel (eckelcu); Parthasarathi >> R (partr); siprec@ietf.org >> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 >> >> Hi John, >> >> Yes We have an indirect relationship in the current model. However in >> the current model it is REQUIRED to have a CSG as CS is connected to=20 >> RS through CSG. However not all use cases would need CSG, IOW CSG has >> to be optional and there should be direct association from CS to RS=20 >> even when CSG is absent. >> >> With the below associations we will have: >> - An instance of RS can have Zero or more CSG blocks. >> - An instance of RS can have Zero or more CS blocks. >> - If a CSG is present it will have 1 or more CS. >> - Each CS can be associated with Zero or 1 CSG. >> >> Let me know if you have any concerns. >> >> Regards, >> Ram >> >>> -----Original Message----- >>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>> Sent: Wednesday, April 06, 2011 6:16 PM >>> To: Ram Mohan R (rmohanr); Scott Orton; Charles Eckel (eckelcu);=20 >>> Parthasarathi R (partr); siprec@ietf.org >>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 >>> >>> I am OK in principle, but I wonder whether there really >> needs to be a >>> relationship between CSG and RS. Isn't that relationship an indirect >>> relationship via CS? >>> >>> John (as individual) >>> >>> >>>> -----Original Message----- >>>> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] >>>> Sent: 03 April 2011 18:13 >>>> To: Scott Orton; Elwell, John; Charles Eckel (eckelcu);=20 >>>> Parthasarathi R (partr); siprec@ietf.org >>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 >>>> >>>> Scott, >>>> >>>> I am ok to make this change to the model. I would like to >> hear from >>>> others if they have any issues in incorporating this change in the=20 >>>> model. >>>> >>>> The updated portion of the model will look like >>>> >>>> >>>> +-------------------------------+ 1 >>>> | Recording Session (RS) |---------------+ >>>> +-------------------------------+ | >>>> | 1..* |1..* | >>>> | | | >>>> | 0..* |0..* | >>>> +--------------+ +-----------------+ | >>>> |Communication | | Communication | 1 | >>>> | Session (CS) |----------| Session (CS) |---| >>>> | Group |0..1 1..*| | | 0..* >> +----------+ >>>> +--------------+ +-----------------+ >> |------|Extension >> | >>>> 1| | 0..* |1..* | | Data >> | >>>> | | 2..* |0..* | >> +----------+ >>>> 0..*| >>>> +---------+ >>>> |Extension| >>>> | Data | >>>> +---------+ >>>> >>>> The only change in the association is : >>>> A CS MUST be associated with zero or one CS-Group >>>> >>>> Rest of the associations remain same. Further the association=20 >>>> between CS and RS remains same as what is between CS-Group and RS. >>>> >>>> Comments ? >>>> >>>> Regards, >>>> Ram >>>> >>>>> -----Original Message----- >>>>> From: siprec-bounces@ietf.org >> [mailto:siprec-bounces@ietf.org] On >>>>> Behalf Of Scott Orton >>>>> Sent: Friday, April 01, 2011 12:18 AM >>>>> To: Elwell, John; Charles Eckel (eckelcu); Parthasarathi R >> (partr); >>>>> siprec@ietf.org >>>>> Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 >>>>> >>>>> John, >>>>> Thanks for the information. >>>>> >>>>> In that case I would like to see the CS group be >> made optional. >>>>> Rather than the CS pointing to the CS Group, I would like to >>> suggest >>>>> that the CS point to the RS and have the CS group stand >>>> alone where it >>>>> would just have its own ID and then a list of CS ids that belong >> to >>>> the >>>>> group. >>>>> >>>>> Scott >>>>> >>>>> -----Original Message----- >>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>>>> Sent: Thursday, March 31, 2011 11:50 AM >>>>> To: Scott Orton; Charles Eckel (eckelcu); Parthasarathi >> R (partr); >>>>> siprec@ietf.org >>>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 >>>>> >>>>> Scott, >>>>> >>>>> Some folks wanted to be able to group related CSs together >>>> (e.g., a CS >>>>> between a customer and an agent and a second CS >> resulting from the >>>>> customer being transferred to a second agent). I will >> leave it to >>>> those >>>>> folks to add to this. >>>>> >>>>> John (chair hat on) >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Scott Orton [mailto:sorton@broadsoft.com] >>>>>> Sent: 31 March 2011 17:43 >>>>>> To: Elwell, John; Charles Eckel (eckelcu); Parthasarathi R=20 >>>>>> (partr); siprec@ietf.org >>>>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 >>>>>> >>>>>> John, Charles, Partha, >>>>>> I have a question. What is the purpose of the CS Group? I do=20 >>>>>> not see it adding anything to the metadata. To me it seems that=20 >>>>>> the whole purpose of the metadata is to describe the recording=20 >>>>>> session to the SRS. Looking at the requirements I see 3=20 >>>>>> relationships that the spec is attempting to describe: >>>>>> >>>>>> A one to one relationship - one communication session to one=20 >>>>>> recording session A one to many relationship - one communication=20 >>>>>> session with multiple Recording sessions >>>>>> - one Recording session made up of=20 >>>>>> multiple communications sessions >>>>>> >>>>>> The current metadata format allows all of these and I do not see=20 >>>>>> what the group is adding. >>>>>> >>>>>> Regards, >>>>>> Scott >>>>>> >> > _______________________________________________ > siprec mailing 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 Apr 7 12:42:57 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BC9528C12E for ; Thu, 7 Apr 2011 12:42:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.578 X-Spam-Level: X-Spam-Status: No, score=-10.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5ypSQ-IoMcz for ; Thu, 7 Apr 2011 12:42:56 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 19C2528C120 for ; Thu, 7 Apr 2011 12:42:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=4077; q=dns/txt; s=iport; t=1302205481; x=1303415081; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=G8pI4pzqGo3pdfFj95CE0LBELOzSu/MhAM2rnAJaGho=; b=bFJveGOaVx93X5JhjAFWv0d62WJUxavHcjVJSzabEBQlFkzEYZ+7HU3Y Cieixho604eMrGa8BLMGw2ywdKqKF7an0/s1JSMP5uqWPoMm+hT7ivPEI HYkVMsa6QylEyMuFHzTcw7/kuIi6+QBDbKse3rYJ/UnVNPsZn+9Y05I2I Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYBAJ4Tnk2rRDoH/2dsb2JhbACYPI1Sd6U5nFGFbQSFUItk X-IronPort-AV: E=Sophos;i="4.63,318,1299456000"; d="scan'208";a="425838051" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-1.cisco.com with ESMTP; 07 Apr 2011 19:44:40 +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 p37Jier3026497 for ; Thu, 7 Apr 2011 19:44:40 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Apr 2011 12:44:40 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Apr 2011 12:44:39 -0700 Message-ID: In-Reply-To: <4D9CBB90.4080804@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Recording awareness indication Thread-Index: Acv0jt2kUmpsv464Rhe1hFUvohteYQAzLWaA References: <4D9CBB90.4080804@cisco.com> From: "Charles Eckel (eckelcu)" To: "Paul Kyzivat (pkyzivat)" , X-OriginalArrivalTime: 07 Apr 2011 19:44:40.0882 (UTC) FILETIME=[3C5E9920:01CBF55C] Subject: Re: [siprec] Recording awareness indication X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 07 Apr 2011 19:42:57 -0000 I agree with Paul. I would hate to force the addition of an audible beep or a red dot to all participants when a less intrusive mechanism is supported. Cheers, Charles=20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat (pkyzivat) > Sent: Wednesday, April 06, 2011 12:14 PM > To: siprec@ietf.org > Subject: Re: [siprec] Recording awareness indication >=20 > I liked this concept of an overt "opt-out" of the in-band indication. > ISTM that if the UA has a "better" way of doing the indication it may > not want the default mechanism. (E.g. The UA may want to apply its own > in-band indication. But that won't work well if a different one has > already been applied.) >=20 > If we can agree on the *concept* of opt-out, then we can determine the > exact form as a subsequent step. >=20 > I suppose some SRCs may feel they are obliged to do their own indication > even if a participant desires to opt-out, and we ought to allow that > too. In that case there should probably be some indication that the > opt-out has been ignored, so that the UA can behave accordingly. >=20 > Thanks, > Paul >=20 > On 4/6/2011 11:08 AM, Elwell, John wrote: > > My own thoughts on this are that the SIP/SDP indication that recording is in progress, even if sent > to a UA known to be recording-aware, should not be used as a substitute for other non-SIP/SDP means of > notification that might otherwise be needed (e.g., an in-band audio announcement). I think recording > indicators should be used to complement other means. For example, an in-band audio announcement would > be able to reach all users (although might be problematic for hearing-impaired users or for users > speaking a different language). Despite such limitations, an in-band announcement is often sufficient > to satisfy legal requirements. On the other hand, a SIP/SDP indication that recording is in progress > could be rendered in different ways and in different languages at the user interface of a recording- > aware UA. > > > > For this reason, I don't see a need for the recording-aware indication in SIP/SDP. Recording > indications can be sent without knowing whether they will be understood by the receiving UA - if they > are understood the user might get an enhanced indication - if not they will be discarded and the user > will get only the basic (non-SIP/SDP) indication. > > > > John (as individual) > > > > > >> -----Original Message----- > >> From: siprec-bounces@ietf.org > >> [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > >> Sent: 06 April 2011 15:55 > >> To: siprec@ietf.org > >> Subject: [siprec] Recording awareness indication > >> > >> There was an inconclusive discussion in Prague on the > >> recording awareness signalling indication in > >> draft-portman-siprec-protocol (slide 6 / section 6.1 of > >> draft). If I understand correctly, it indicates that a UA > >> involved in the CS supports the SIPREC extensions relevant to > >> the CS. In particular, it indicates that the UA would be able > >> to understand SIP/SDP recording indications (slide 7 / > >> section 6.2 of draft). It seems the recording awareness > >> indication means that the SRC can rely on the recording > >> indications in SIP/SDP to advise the user that recording is > >> in progress, thereby avoiding the need for the SRC to provide > >> suitable indications through non-SIP means (e.g., in-band > >> audio announcements). > >> > >> Please continue this discussion. > >> > >> John (as chair) > >> _______________________________________________ > >> siprec mailing list > >> siprec@ietf.org > >> https://www.ietf.org/mailman/listinfo/siprec > >> > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From partr@cisco.com Fri Apr 8 06:45:27 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9875328C118 for ; Fri, 8 Apr 2011 06:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.073 X-Spam-Level: X-Spam-Status: No, score=-10.073 tagged_above=-999 required=5 tests=[AWL=0.526, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4KonfZMoJkgT for ; Fri, 8 Apr 2011 06:45:26 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id AD43C28C120 for ; Fri, 8 Apr 2011 06:45:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=6369; q=dns/txt; s=iport; t=1302270431; x=1303480031; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=0oBlr3XkfQMT5Rnf44ZMVRHM+1cAzDF9Opg0rs9X2AU=; b=IxDZcNcFMeicPEl54mZTMSq9baagmJ65c5njd+CsqcxVG8OK3H9EYFUY upt3nOUzCgJRXoso92u2svf7MbBkdclCCeiSb11fvXY6KjFWQS2uiHJ/4 7vikUe00INVW5V7DjTHhNzUm2N1AUUfc3uN8wy62lhYsSo9BoY71lOJwD k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArYAAOEQn02Q/khNgWdsb2JhbACYQY1TFAEBFiYliHqcB5wwhW0EhVOLbA X-IronPort-AV: E=Sophos;i="4.63,323,1299456000"; d="scan'208";a="24995173" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 08 Apr 2011 13:47:10 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p38Dl9mR019509 for ; Fri, 8 Apr 2011 13:47:09 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Apr 2011 19:17:08 +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: Fri, 8 Apr 2011 19:17:08 +0530 Message-ID: In-Reply-To: <4D9CE04B.7030704@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] RTP model Thread-Index: Acv0pMhL/9tcjBrHQ8S/VnX3urvT+wBSNLoQ References: <4D9C711B.6070205@cisco.com><1D062974A4845E4D8A343C65380492020523BAF6@XMB-BGL-414.cisco.com> <4D9CE04B.7030704@cisco.com> From: "Parthasarathi R (partr)" To: "Paul Kyzivat (pkyzivat)" , "Muthu ArulMozhi Perumal (mperumal)" X-OriginalArrivalTime: 08 Apr 2011 13:47:08.0816 (UTC) FILETIME=[745AD900:01CBF5F3] Cc: siprec@ietf.org Subject: Re: [siprec] RTP model X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 08 Apr 2011 13:45:27 -0000 I'm not RTP guy but I'm writing the mail based on SIPREC understanding. In terms of SIPRC, SRC may be one of the following combination as per the architecture 1) UA(CS) + UA (RS) 2) B2BUA (CS) + UA(RS) 3) focus (CS) + UA (RS) 4) Non-SIP to UA(CS) + UA(RS). Non-sip may be PSTN, H.323, Jingle, RTCweb etc., 5) Non-SIP to Non-SIP (CS) + UA(RS) - different permutation & combination possible here=20 IMO, SRC MAY support any of the RTP model like RTP translator, RTP mixer or RTP endpoint and there is no restriction specific to SIPREC. How CS RTP information passes to RS RTP is implementation specific. Say one SRC which has (B2BUA + UA) may prefer to acts as RTP translator (forwarding) towards RS session whereas another SRC which has (B2BUA + UA) may prefer to RTP Endpoint towards RS Session. Till now, we haven't come across any restriction in RTP model specific to SIPREC. The question raised in IETF-80 is "multiple stream in single port" usage w.r.t metadata format. Here there two usecase: 1) "multiple stream in single port" for each participant (individually) - Here multiple stream is related to multiple sources of stream which has different SSRC but it belongs to single participant. It is possible for SRC to act as RTP translator (forwarder) in case SRC is a middle box (B2BUA, SBC) 2) "multiple stream in single port" for multiple participants - Here SRC has to combine all stream from different participant together whereas SRC has to act as RTP Endpoint. Please correct me incase I missed understand the translator functionality. Please note that it is SRC implementation choice. There is no need of restricting this stuff but I really don't know the reason for doing this by SRC. SRS is RTP Endpoint which store or perform real-time analysis of RTP/RTCP packet instead of play in the endpoint. Here, I like to hear from folks that any more restriction above RFC 3550 is required which is specific to SIPREC. Thanks Partha =20 -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat (pkyzivat) Sent: Thursday, April 07, 2011 3:21 AM To: Muthu ArulMozhi Perumal (mperumal) Cc: siprec@ietf.org Subject: Re: [siprec] RTP model On 4/6/2011 10:57 AM, Muthu ArulMozhi Perumal (mperumal) wrote: > I agree we should keep the models open to cater to different use-cases. > However, for the most common ones we anticipate, I think we should=20 > have clear guidelines/recommendations on how it must/should/may work=20 > to achieve basic interop among implementations of that model. For e.g, > the translator model for SRC looks a simple one that would cater to a=20 > large number of cases and we might want to have clear=20 > guidelines/recommendations on how RTP and RTCP should be handled for it. I don't know a lot about RTP, but the above seems right to me - each different way the SRC might relate to the RTP will need some specification. Thanks, Paul > thanks, > Muthu > > |-----Original Message----- > |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Paul Kyzivat (pkyzivat) > |Sent: Wednesday, April 06, 2011 7:27 PM > |To: siprec@ietf.org > |Subject: Re: [siprec] RTP model > | > |I am definitely not an expert on this subject, but ISTM that making a > |choice about one of these models would inordinately limit > implementation > |choices for the SRC. IMO we want to provide a lot of latitude for SRC > |implementation, even if it means complicating life for the SRS. > | > | Thanks, > | Paul > | > |On 4/6/2011 4:05 AM, Elwell, John wrote: > |> There were discussions before and during the Prague meeting about > multiplexing media streams from > |different participants on to the same port. It became apparent that=20 > |we > need a better understanding of > |the RTP model we are using first, before we can answer this. > |> > |> The question is whether the SRC acts as a translator or as a mixer > |> or > end system. > |> > |> A translator is defined in RFC 3550 as: > |> "An intermediate system that forwards RTP packets > |> with their synchronization source identifier intact. =20 > |> Examples > of > |> translators include devices that convert encodings without > mixing, > |> replicators from multicast to unicast, and application-level > |> filters in firewalls." > |> > |> A mixer or end system, in contrast, would assign new=20 > |> synchronisation > sources to RTP packets. > |> > |> The translator model seems to require less processing in the SRC - > RTP packets would just be > |forwarded unchanged to the SRC (i.e., the UDP packet would change but > its RTP payload would be > |unchanged). > |> > |> However, the translator model prevents some capabilities, e.g.: > |> - the SRC cannot transcode (e.g., if the SRS does not support the > codec used in the CS); > |> - the SRC cannot mix streams from different participants (e.g., to > reduce the bandwidth required on > |the RS path); > |> - the SRC cannot encrypt streams on the RS path if unencrypted on=20 > |> the > CS path or vice versa; > |> - the SRC cannot use different encryption keys on the CS path and=20 > |> the > RS path. > |> > |> Therefore, although the translator model might work in some > situations, it probably can't satisfy > |all requirements. > |> > |> Also with the translator model, we would need to be clear how RTCP > would work. Consider an SRC at a > |B2BUA. It receives RTP packets from party A, forwards them as a > translator to party B, and also > |forwards them as a translator to the SRS. The SRC will receive RTCP > packets from both party B and the > |SRS and needs to send RTCP packets to party A - how does the SRC=20 > |handle > this? > |> > |> John (as individual) > |> > |> > |> _______________________________________________ > |> siprec mailing 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 partr@cisco.com Fri Apr 8 07:03:10 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59A153A691F for ; Fri, 8 Apr 2011 07:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.081 X-Spam-Level: X-Spam-Status: No, score=-10.081 tagged_above=-999 required=5 tests=[AWL=0.518, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id po41CvXGxOWU for ; Fri, 8 Apr 2011 07:03:07 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 1F8173A690C for ; Fri, 8 Apr 2011 07:03:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=32088; q=dns/txt; s=iport; t=1302271491; x=1303481091; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=vM6K+nzfKLfYzFEZa5fbCBeQ7pr/RgHE3kqjOD7SBOE=; b=NU28rtjIqzRev5xz7yFgQvpdQ2V6IE6r5kIN6FV1J/ukj+cy48PLiP1i KnNyVqpE+HsyX0hxTyYQbQa8aCmeltFM4GyQWDlMBh2GYBqrBE2NE5pPj ISW+qhkuzKcbxQm4lkQBYdfki41FgElGVp4BTzq7TTkWE52AHib8Lzt+8 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArYAALUUn02Q/khMgWdsb2JhbACYQY1TFAEBFiYliHqcFZwsgxGCXASFU4ts X-IronPort-AV: E=Sophos;i="4.63,323,1299456000"; d="scan'208";a="82800269" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 08 Apr 2011 14:04:49 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p38E4miB030192; Fri, 8 Apr 2011 14:04:49 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Apr 2011 19:34:48 +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: Fri, 8 Apr 2011 19:34:48 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Dialog state in the CS block of metadatamodel[wasRE:Progressing the architecture document] Thread-Index: AcvY+qyFanmfNOL5Qlq3osURZ2w4qAJbzb1IACUhGWAAGstGAwFGdfdAAAXbWKAAA+XmQAAAGhNQABG/CmwAHSHXEAAZDuOFABzjR+AAVixTcAAUeoQQAAAj4EAAHgihsAAClqhQAAXOdEAADtUDkAAjidVAAABgrFAAAo/hIAAdpARgAAc8P9ABkDDsUAACY20AAAipdrAAI37TIA== References: <101C6067BEC68246B0C3F6843BCCC1E30B61DB3370@MCHP058A.global-ad.net><07465C1D981ABC41A344374066AE1A2C38A960C8F0@TLVMBX01.nice.com><101C6067BEC68246B0C3F6843BCCC1E30B61E96D11@MCHP058A.global-ad.net><07465C1D981ABC41A344374066AE1A2C38A960C9CA@TLVMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD05CC9E38@XMB-BGL-417.cisco.com> <07465C1D981ABC41A344374066AE1A2C38AB466335@TLVMBX01.nice.com> <07465C1D981ABC41A344374066AE1A2C38AB46639F@TLVMBX01.nice.com> <07465C1D981ABC41A344374066AE1A2C38AB466603@TLVMBX01.nice.com> <101C6067BEC68246B0C3F6843BCCC1E30B6D1ED8E0@MCHP058A.global-ad.net> <07465C1D981ABC41A344374066AE1A2C38AB466C1B@TLVMBX01.nice.com> From: "Parthasarathi R (partr)" To: "Elwell, John" , "Leon Portman" , "Charles Eckel (eckelcu)" , "Hutton, Andrew" , "Ram Mohan R (rmohanr)" X-OriginalArrivalTime: 08 Apr 2011 14:04:48.0073 (UTC) FILETIME=[EBB8A390:01CBF5F5] Cc: siprec@ietf.org Subject: Re: [siprec] Dialog state in the CS block of metadatamodel[wasRE:Progressing the architecture document] X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 08 Apr 2011 14:03:10 -0000 John, I guess that we are talking in the same line. I mentioned about session state as this attribute was originally added to distinguish between early versus regular media.=20 I completely agree with you that this attribute has to be in participant object or stream object even if somebody wants to have this. Thanks Partha -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 Sent: Wednesday, April 06, 2011 6:20 PM To: Parthasarathi R (partr); Leon Portman; Charles Eckel (eckelcu); Hutton, Andrew; Ram Mohan R (rmohanr) Cc: siprec@ietf.org Subject: RE: [siprec] Dialog state in the CS block of metadatamodel[wasRE:Progressing the architecture document] Partha, I don't see the connection between the discussion on session state and the discussion on early versus regular media. It seems to me that if we want to tag media as coming from an automaton, this would be an attribute of the participant object, not the session object. However, I am not arguing in favour of adding this attribute - just pointing out what it would mean. John (as individual) > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > Sent: 06 April 2011 10:02 > To: Elwell, John; Leon Portman; Charles Eckel (eckelcu); Hutton,=20 > Andrew; Ram Mohan R (rmohanr) > Cc: siprec@ietf.org > Subject: RE: [siprec] Dialog state in the CS block of=20 > metadatamodel[wasRE:Progressing the architecture document] > > John, > > As we agreed upon on IETF-80 SIPREC meeting, session state attribute=20 > will not be included as part of the metadata model & format. > In case any > requires this attribute, Let them speak for it. > > I really don't very sure whether it is required to pass feature tag in > SIPREC Metadata. > > Thanks > Partha > > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Wednesday, April 06, 2011 1:06 PM > To: Parthasarathi R (partr); Leon Portman; Charles Eckel (eckelcu);=20 > Hutton, Andrew; Ram Mohan R (rmohanr) > Cc: siprec@ietf.org > Subject: RE: [siprec] Dialog state in the CS block of=20 > metadatamodel[wasRE:Progressing the architecture document] > > So you are saying we might want to distinguish between media generated > automatically and media generated by a human? I guess the only SIP=20 > mechanism for determining this is that "Automata" media feature tag in > RFC 3840, but I don't know how widely implemented it is. > > John > > > -----Original Message----- > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > Sent: 29 March 2011 09:50 > > To: Elwell, John; Leon Portman; Charles Eckel (eckelcu); Hutton,=20 > > Andrew; Ram Mohan R (rmohanr) > > Cc: siprec@ietf.org > > Subject: RE: [siprec] Dialog state in the CS block of=20 > > metadatamodel[wasRE:Progressing the architecture document] > > > > John, > > > > I agree with you in case of media server participant sends > "ringback" > > media stream during the early dialog and later stage, the callee=20 > > participant sends actual stream of the session using another=20 > > offer/answer exchange. It is also possible that callee sends=20 > > "ringback" > > media stream wherein there is no difference between early > or regular > > media in terms of metadata information. > > > > Having said that, it "may" or "may not" be matter whether > the devices > > of the participant automatically creates the media stream or=20 > > participant actually creates media stream. > > > > Thanks > > Partha > > > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Tuesday, March 29, 2011 10:39 AM > > To: Parthasarathi R (partr); Leon Portman; Charles Eckel (eckelcu);=20 > > Hutton, Andrew; Ram Mohan R (rmohanr) > > Cc: siprec@ietf.org > > Subject: RE: [siprec] Dialog state in the CS block of=20 > > metadatamodel[wasRE:Progressing the architecture document] > > > > Partha, > > > > I think the real distinction you wish to make is between > media coming > > from a particular participant (associated with the UAS) and media=20 > > coming from some other entity (e.g., media server). In my view the=20 > > latter case, if we choose to record it, comes from a different=20 > > "participant". It has nothing to do with whether it is > deemed early or > > > regular from a SIP dialog perspective. > > > > John (as individual) > > > > > > > -----Original Message----- > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > Sent: 28 March 2011 17:53 > > > To: Leon Portman; Charles Eckel (eckelcu); Hutton, > Andrew; Elwell, > > > John; Ram Mohan R (rmohanr) > > > Cc: siprec@ietf.org > > > Subject: RE: [siprec] Dialog state in the CS block of=20 > > > metadatamodel[wasRE:Progressing the architecture document] > > > > > > > > > The question of "session" state is raised in my mind mainly to=20 > > > distinguish between early media (Media before session > > establishment) > > > from normal media. Without the information in SIPREC > metadata, the > > > early media will be associated with UAS participant's > media stream. > > > I'm interested in knowing whether SIPREC solution has to > > differentiate > > > > > between early media from normal media. > > > > > > As per John below mail, there is no need to differentiate > > as per the > > > current requirement. If most of the folks feel so, I'm fine > > with not > > > including "session state" in metadata. > > > > > > Thanks > > > Partha > > > > > > -----Original Message----- > > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > > Sent: Monday, March 28, 2011 7:16 PM > > > To: Charles Eckel (eckelcu); Hutton, Andrew; Elwell, John;=20 > > > Parthasarathi R (partr); Ram Mohan R (rmohanr) > > > Cc: siprec@ietf.org > > > Subject: RE: [siprec] Dialog state in the CS block of=20 > > > metadatamodel[wasRE:Progressing the architecture document] > > > > > > Charles Hi > > > > > > Just to make clear, I don't think SRS should receive dialog level=20 > > > state events about all CS dialogs. I think that we should > > to support > > > reporting high level session events. > > > I understand the complexity of that and Ok to keep it > open or next > > > phase extensions > > > > > > Leon > > > > > > -----Original Message----- > > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > Sent: Monday, March 28, 2011 3:35 PM > > > To: Hutton, Andrew; Elwell, John; Leon Portman; Parthasarathi R=20 > > > (partr); Ram Mohan R (rmohanr) > > > Cc: siprec@ietf.org > > > Subject: RE: [siprec] Dialog state in the CS block of=20 > > > metadatamodel[wasRE:Progressing the architecture document] > > > > > > I agree with this approach. Hopefully Leon and others > that saw the > > > need for this state information can confirm if it works for them. > > > > > > Cheers, > > > Charles > > > > > > > -----Original Message----- > > > > From: Hutton, Andrew > [mailto:andrew.hutton@siemens-enterprise.com] > > > > Sent: Monday, March 28, 2011 9:13 AM > > > > To: Elwell, John; Leon Portman; Charles Eckel (eckelcu); > > > Parthasarathi > > > R (partr); Ram Mohan R > > > > (rmohanr) > > > > Cc: siprec@ietf.org > > > > Subject: RE: [siprec] Dialog state in the CS block of > > > metadatamodel[wasRE:Progressing the architecture > > > > document] > > > > > > > > Hi, > > > > > > > > The draft-ietf-siprec-architecture has from the very > > > beginning listed > > > dialog state as an example of > > > > what would be included in metadata which is why I raised > > > the question. > > > > > > > > However it is true to say this was put in the > > architecture document > > > before we had firmed up the > > > > requirements or starting any indepth work on metadata so I could > > > accept that the architecture draft > > > > simply got this wrong from the start and it maybe should > > be removed. > > > We could of course take the view > > > > that if dialog events are important then the SRS could > > subscribe to > > > the dialog event package at the > > > > SRC and SIPREC does not need to touch this. > > > > > > > > I don't think we can allow SIPREC metadata to extend as far as > > > reporting everything that happens to > > > > the CS including how it is linked to other CS's and what > > > services are > > > used on the CS (E.g. types of > > > > transfer etc.). This would quickly get very difficult to > > > define and we > > > would probably fail. > > > > > > > > I would prefer to not report this state information in > > metadata than > > > open up the possibility of adding > > > > lots of complexity. > > > > > > > > Regards > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Elwell, John > > > > > Sent: 27 March 2011 14:50 > > > > > To: Leon Portman; Charles Eckel (eckelcu); Parthasarathi > > > R (partr); > > > > > Ram Mohan R (rmohanr); Hutton, Andrew > > > > > Cc: siprec@ietf.org > > > > > Subject: RE: [siprec] Dialog state in the CS block of=20 > > > > > metadatamodel[wasRE:Progressing the architecture document] > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > > > > > Sent: 27 March 2011 11:48 > > > > > > To: Charles Eckel (eckelcu); Elwell, John; Parthasarathi R=20 > > > > > > (partr); Ram Mohan R (rmohanr); Hutton, Andrew > > > > > > Cc: siprec@ietf.org > > > > > > Subject: RE: [siprec] Dialog state in the CS block of=20 > > > > > > metadatamodel[wasRE:Progressing the architecture document] > > > > > > > > > > > > Charles Hi > > > > > > > > > > > > Yes, it will be good to discuss it face to face. > > > > > > > > > > > > Just little background for such requirements. Today, > > especially > > > > > > for contact centers, it is important for SRS to capture the=20 > > > > > > information how long customer was waiting for agent to > > > answer the > > > > > > call, which party hang up, how long was the hold time, > > > if it was > > > > > > blind transfer or consultation transfer. This information=20 > > > > > > important both from quality management point of view > > > and customer > > > > > > experience point of view. > > > > > [JRE] (as chair) I think the group needs to consider > > > whether this is > > > > > > > > within scope. Looking at the requirements, we have: > > > > > "REQ-012 The mechanism MUST provide the SRS with metadata > > > describing > > > > > CSs that are being recorded, including the media > > being used and > > > the > > > > > identities of parties involved." > > > > > If we are not recording the session while the caller is > > > waiting to > > > > > be answered, it seems we perhaps don't have a requirement for=20 > > > > > metadata about that. This seems to be more about call detail=20 > > > > > recording (CDR) rather than session recording. We can by > > > all means > > > > > have this discussion, but I am concerned about scope creep. > > > > > > > > > > > It is important also from compliance point of view to > > detect if > > > > > > somebody actually received the media stream or still was in=20 > > > > > > pending state or media stream was disconnected. > > > > > [JRE] (as individual) I agree we should show a participant as=20 > > > > > receiving media only if the SRC believes media is > > actually being > > > > > sent to that participant (even then, there can be no > > > guarantee it is > > > > > > > > received, e.g., because NAT or firewall traversal isn't > > > functioning > > > > > properly, severe packet loss, speaker volume is muted, > > > etc..). But I > > > > > > > > have doubts whether it is necessarily to try to account > > > for periods > > > > > when the SRC knows a participant is not receiving media > > > by saying it > > > > > > > > is because of alerting, hold or whatever. > > > > > > > > > > John > > > > > > > > > > > > > > > > > > > > > > Leon > > > > > > > > > > > > -----Original Message----- > > > > > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > > > > Sent: Sunday, March 27, 2011 11:35 AM > > > > > > To: Leon Portman; Elwell, John; Parthasarathi R > > > (partr); Ram Mohan > > > > > > > > > R (rmohanr); Hutton, Andrew > > > > > > Cc: siprec@ietf.org > > > > > > Subject: RE: [siprec] Dialog state in the CS block of=20 > > > > > > metadatamodel[wasRE:Progressing the architecture document] > > > > > > > > > > > > Hi Leon, > > > > > > > > > > > > Thank you for your patience in trying to explain > this to me; > > > > > > however, I still am not able to understand why the SRS > > > might need > > > > > > to know this information, or what it would do with it. > > > > > > Is it that you need to know when a given participant > > > was receiving > > > > > > > > > the recorded media and when it was not? If so, I do > not think > > > > > > dialog state is sufficient. Is there some other > > requirement or > > > > > > functionality addressed by the SRS having such information? > > > > > > Perhaps it is easier to discuss in person at the > > > breakfast meeting > > > > > > > > > Wednesday or during the working group session. > > > > > > > > > > > > Cheers, > > > > > > Charles > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > > > > > > Sent: Saturday, March 26, 2011 8:15 PM > > > > > > > To: Charles Eckel (eckelcu); Elwell, John; Parthasarathi > > > > > R (partr); > > > > > > Ram Mohan R (rmohanr); Hutton, > > > > > > > Andrew > > > > > > > Cc: siprec@ietf.org > > > > > > > Subject: RE: [siprec] Dialog state in the CS block of > > > > > > metadatamodel[wasRE:Progressing the architecture > > > > > > > document] > > > > > > > > > > > > > > Charles Hi > > > > > > > > > > > > > > Without participant session state, SRS will know only when > > > > > > participant > > > > > > is part of the session and will > > > > > > > not know about intermediate states like ringing, > > retrying etc. > > > > > > > I know that we have media stream information per > > > > > participant but not > > > > > > sure that it is enough. > > > > > > > > > > > > > > Leon > > > > > > > -----Original Message----- > > > > > > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > > > > > Sent: Saturday, March 26, 2011 9:07 PM > > > > > > > To: Leon Portman; Elwell, John; Parthasarathi R (partr); > > > > > Ram Mohan R > > > > > > (rmohanr); Hutton, Andrew > > > > > > > Cc: siprec@ietf.org > > > > > > > Subject: RE: [siprec] Dialog state in the CS block of > > > > > metadatamodel > > > > > > [wasRE:Progressing the > > > > > > > architecture document] > > > > > > > > > > > > > > Hi Leon, > > > > > > > > > > > > > > I am still having a hard time understanding why we need > > > > > the session > > > > > > state information per CS > > > > > > > participant? Why is this required, who uses it, and how? > > > > > > > > > > > > > > Thanks, > > > > > > > Charles > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: siprec-bounces@ietf.org > > > > > [mailto:siprec-bounces@ietf.org] On > > > > > > > Behalf Of Leon Portman > > > > > > > > Sent: Saturday, March 26, 2011 10:31 AM > > > > > > > > To: Elwell, John; Parthasarathi R (partr); Ram Mohan R > > > > > (rmohanr); > > > > > > > Hutton, Andrew > > > > > > > > Cc: siprec@ietf.org > > > > > > > > Subject: Re: [siprec] Dialog state in the CS block of > > > > > > metadatamodel > > > > > > > [wasRE:Progressing the > > > > > > > > architecture document] > > > > > > > > > > > > > > > > John Hello > > > > > > > > > > > > > > > > I agree that SRS (and its application clients) > interested > > > > > > in SESSION > > > > > > > level events and not underlying > > > > > > > > DIALOG events. However we do need to support reporting > > > > > > session state > > > > > > > information per CS participant > > > > > > > > that sometimes equals to dialog level and sometimes not. > > > > > > > > > > > > > > > > We could have define more application level state > > > events like > > > > > > instead > > > > > > > of TRYING - > RINGING etc. > > > > > > > > However they could be domain specific. > > > > > > > > > > > > > > > > Leon > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Elwell, John > > > [mailto:john.elwell@siemens-enterprise.com] > > > > > > > > Sent: Thursday, March 24, 2011 6:34 PM > > > > > > > > To: Parthasarathi R (partr); Ram Mohan R (rmohanr); > > > > > Leon Portman; > > > > > > > Hutton, Andrew > > > > > > > > Cc: siprec@ietf.org > > > > > > > > Subject: RE: [siprec] Dialog state in the CS block of > > > > > > metadata model > > > > > > > [wasRE:Progressing the > > > > > > > > architecture document] > > > > > > > > > > > > > > > > This discussion gives me some concerns, echoing to some > > > > > > extent what > > > > > > > Ram is saying. > > > > > > > > > > > > > > > > SIPREC is about session recording, where a > session is the > > > > > > information > > > > > > > exchanged between participants > > > > > > > > in a CS (the media streams) plus metadata. The > > > metadata should > > > > > > provide > > > > > > > additional information about > > > > > > > > the CS. This means information about the communication > > > > > > SESSION, not > > > > > > > about the SIP dialog that is used > > > > > > > > to control that session. With this in mind, consider > > > > > the following > > > > > > > points, some of which have already > > > > > > > > been raised: > > > > > > > > > > > > > > > > 1. There may be more than one SIP dialog involved if the > > > > > > SRC is at a > > > > > > > B2BUA or conference focus. > > > > > > > > > > > > > > > > 2. Does the CS necessarily need to be controlled > > by SIP? For > > > > > > example, > > > > > > > it could be a PSTN call, an RTC- > > > > > > > > Web call or a Jingle call. None of these preclude using > > > > > > SIP for the > > > > > > RS > > > > > > > (that is what the charter of > > > > > > > > SIPREC is all about - a SIP-based RS). > > > > > > > > > > > > > > > > 3. Somebody retrieving and playing back a recorded > > > CS will be > > > > > > > interested in session-related events > > > > > > > > like participants leaving and joining > (including the first > > > > > > > participants joining at the start of the CS > > > > > > > > and the last participants leaving a the end of the > > > CS), media > > > > > > streams > > > > > > > starting and ending and > > > > > > > > participants starting or stopping receipt of a > > media stream. > > > In > > > > > > other > > > > > > > words, changes of SESSION state, > > > > > > > > not dialog state. > > > > > > > > > > > > > > > > 4. Some of the SIP dialog states just don't seem > > > relevant. The > > > > > > > distinction between early dialog and > > > > > > > > full dialog in SIP does not necessarily > > corresponding to any > > > > > > > meaningful state change of the session. > > > > > > > > For example, A makes a call to B and B answers and > > > > > starts sending > > > > > > > media. A receives and renders media > > > > > > > > (perhaps it has already received SDP answer, allowing > > > > > it to verify > > > > > > the > > > > > > > source of the media). Then A > > > > > > > > receives the 200 OK (transitioning from an early dialog > > > > > to a full > > > > > > > dialog) and continues to receive > > > > > > > > media. So although there is a dialog state > > change, there is > > > not > > > > > > really > > > > > > > a session state change. > > > > > > > > > > > > > > > > The bit about dialog state in the architecture > > > draft is, in my > > > > > > > opinion, a legacy from some earlier > > > > > > > > discussions, before we started having the metadata > > > > > discussions. I > > > > > > > think the metadata discussions have > > > > > > > > taken us in the right direction. > > > > > > > > > > > > > > > > John (as individual) > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: siprec-bounces@ietf.org=20 > > > > > > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of > > > Parthasarathi > > > R > > > > > > > (partr) > > > > > > > > > Sent: 24 March 2011 02:36 > > > > > > > > > To: Ram Mohan R (rmohanr); Leon Portman; > Hutton, Andrew > > > > > > > > > Cc: siprec@ietf.org > > > > > > > > > Subject: Re: [siprec] Dialog state in the CS block of > > > metadata > > > > > > model > > > > > > > > > [wasRE:Progressing the architecture document] > > > > > > > > > > > > > > > > > > Ram, > > > > > > > > > > > > > > > > > > Please read inline. > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > Partha > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > > > > > > > > > From: Ram Mohan R (rmohanr) > > > > > > > > > Sent: Wed 3/23/2011 7:59 PM > > > > > > > > > To: Parthasarathi R (partr); Leon Portman; > > Hutton, Andrew > > > > > > > > > Cc: siprec@ietf.org > > > > > > > > > Subject: RE: [siprec] Dialog state in the CS block of > > > metadata > > > > > > model > > > > > > > > > [wasRE:Progressing the architecture document] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I am still trying to understand what is the > > > > > significance of this > > > > > > > > > attribute w.r.t CS. Are we saying the attribute > > represents > > > the > > > > > > state > > > > > > > > > of CS ? > > > > > > > > > > > > > > > > > > Note that CS need not be one dialog. > > > > > > > > > > > > > > > > > > The attribute is to show the state of CS > > > > > > only. As it is > > > > > > > not > > > > > > > > > single dialog, I have mentioned as session > > state attribute > > > > > > > > > > > > > > > > > > > > > > > > For cases like Conference where there may be different > > > > > > participants, > > > > > > > > > if SRC happens to be Focus how do you derive/what is > > > "session > > > > > > state" > > > > > > > ? > > > > > > > > > > > > > > > > > > I really don't know whether it is generic. My > > > thought > > > > > > > > > processing of session state for conference is > > as follows: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 1) First participant of conference early media (ivr > > > > > play) may be > > > > > > > > > considered as "early" state of session. > > > > > > > > > > > > > > > > > > 2) The session state is chaged to confirmed > in case any > > > > > > one of the > > > > > > > > > participant joined in the conference. > > > > > > > > > > > > > > > > > > 3) The session state is move to terminated > when the last > > > > > > participant > > > > > > > > > moved out of the conference. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Please let me know in case other way to represent the > > > session > > > > > > state > > > > > > > of > > > > > > > > > conference > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > For cases where B2BUA acts as SRC what is > > > "session state" ? > > > > > > > > > > > > > > > > > > It looks straight forward for me. In > > B2BUA case , > > > > > > > > > > > > > > > > > > 1) The stage where in two party is not > connected, it is > > > > > > considered > > > > > > > as > > > > > > > > > early state. > > > > > > > > > > > > > > > > > > 2) when both are connected, it is confirmed state > > > > > > > > > > > > > > > > > > 3) In case of BYE received from any one of the party, > > > > > then CS is > > > > > > > > > considered as terminated state > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Please note that this is applicable for 3PCC as well. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ram > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: siprec-bounces@ietf.org=20 > > > > > > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of > > > Parthasarathi > > > R > > > > > > > (partr) > > > > > > > > > Sent: Wednesday, March 23, 2011 6:13 AM > > > > > > > > > To: Leon Portman; Hutton, Andrew > > > > > > > > > Cc: siprec@ietf.org > > > > > > > > > Subject: Re: [siprec] Dialog state in the CS block of > > > metadata > > > > > > model > > > > > > > > > [wasRE:Progressing the architecture document] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Leon, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Shall we have optional "event" attribute to > indicate the > > > state > > > > > > > change > > > > > > > > > which is similar to "event" attribute in RFC 4235. > > > > > The "event" > > > > > > will > > > > > > > > > include the following: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 1) cancelled > > > > > > > > > > > > > > > > > > 2) rejected > > > > > > > > > > > > > > > > > > 3) replaced > > > > > > > > > > > > > > > > > > 4) bye > > > > > > > > > > > > > > > > > > 5) error > > > > > > > > > > > > > > > > > > 6) timeout > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > Partha > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > > > > > > > > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > > > > > > > > Sent: Tue 3/22/2011 9:37 PM > > > > > > > > > To: Hutton, Andrew; Parthasarathi R (partr) > > > > > > > > > Cc: siprec@ietf.org > > > > > > > > > Subject: RE: Dialog state in the CS block of metadata > > > > > model [was > > > > > > > > > RE:Progressing the architecture document] > > > > > > > > > > > > > > > > > > It can be either application level error or dialog > > > > > > level errors - > > > > > > > like > > > > > > > > > timeout or failures. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Leon > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: Hutton, Andrew > > > > > > [mailto:andrew.hutton@siemens-enterprise.com] > > > > > > > > > Sent: Tuesday, March 22, 2011 6:02 PM > > > > > > > > > To: Leon Portman; Parthasarathi R (partr) > > > > > > > > > Cc: siprec@ietf.org > > > > > > > > > Subject: RE: Dialog state in the CS block of metadata > > > > > model [was > > > > > > RE: > > > > > > > > > Progressing the architecture document] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > What would it be used for? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > > > > > > > > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > > > > > > > > Sent: 22 March 2011 14:11 > > > > > > > > > To: Parthasarathi R (partr); Hutton, Andrew > > > > > > > > > Cc: siprec@ietf.org > > > > > > > > > Subject: RE: Dialog state in the CS block > of metadata > > > > > > model [was > > > > > > > RE: > > > > > > > > > Progressing the architecture document] > > > > > > > > > > > > > > > > > > Should we have error state as well? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Leon > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: siprec-bounces@ietf.org=20 > > > > > > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of > > > Parthasarathi > > > R > > > > > > > (partr) > > > > > > > > > Sent: Tuesday, March 22, 2011 3:33 PM > > > > > > > > > To: Parthasarathi R (partr); Hutton, Andrew > > > > > > > > > Cc: siprec@ietf.org > > > > > > > > > Subject: [siprec] Dialog state in the CS block of > > > > > > metadata model > > > > > > > [was > > > > > > > > > RE: Progressing the architecture document] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The architecture document proposes to have > > > > > > dialog/session state > > > > > > > in > > > > > > > > > Metadata model. To achieve this, "session state" > > > > > > attribute has to > > > > > > be > > > > > > > > > added in the CS block of Metadata model. The possible > > > > > values for > > > > > > > > > session state are > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 1) Trying > > > > > > > > > > > > > > > > > > 2) Proceeding > > > > > > > > > > > > > > > > > > 3) Early > > > > > > > > > > > > > > > > > > 4) Confirmed > > > > > > > > > > > > > > > > > > 5) Terminated > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Please let me know in case any objection to add > > > > > this attribute > > > > > > > in > > > > > > > > > Metadata model. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > Partha > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > > > > > > > > > From: Parthasarathi R (partr) > > > > > > > > > Sent: Wednesday, March 16, 2011 5:40 AM > > > > > > > > > To: Hutton, Andrew > > > > > > > > > Cc: Elwell, John; siprec@ietf.org > > > > > > > > > Subject: RE: Progressing the architecture document > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: siprec-bounces@ietf.org > > > > > > > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of > > > > > > Parthasarathi R > > > > > > > > > (partr) > > > > > > > > > > Sent: 14 March 2011 17:05 > > > > > > > > > > To: Elwell, John; siprec@ietf.org > > > > > > > > > > Subject: Re: [siprec] Progressing the > > > > > architecture document > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Sec 4.3.1 whether 3rd bullet is required? > > > > > > > > > > > > > > > > > > > > > > > > > > > > [AndyH]I assume it is as for example I assume > > > it would be > > > > > > > necessary > > > > > > > > > to record early-media and update the SRS when the > > > > > dialog changes > > > > > > to > > > > > > > > > the confirmed or terminated state. Does not > > seem to be in > > > the > > > > > > > metadata > > > > > > > > > draft though. In the end I will either remove > > > these bullets > > > or > > > > > > align > > > > > > > > > with the metadata draft. > > > > > > > > > It is a good point. Dialog state shall be > > > > > > added as one > > > > > > > of > > > > > > > > > the optional attribute in CS metadata block with > > > > > > default value as > > > > > > > > > mid-dialog. This helps to differentiate between > > > early dialog > > > > > > > > > (ringback) vs mid-dialog (normal > > > > > > > > > conversation) in recording. In case of no > > > objection for this > > > > > > > attribute > > > > > > > > > in metadata model, we will add it. We will work > > > out metadata > > > > > > format > > > > > > > > > once the consensus occurs for metadata model. > > > > > > > > > In case required, we will span separate mail thread to > > > > > > close this > > > > > > > > > issue > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > siprec mailing list > > > > > > > > siprec@ietf.org > > > > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > > > > > > > > > > From Henry.Lum@alcatel-lucent.com Fri Apr 8 07:45:25 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 727EB3A6876 for ; Fri, 8 Apr 2011 07:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.386 X-Spam-Level: X-Spam-Status: No, score=-6.386 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sn9xqZU2QBVQ for ; Fri, 8 Apr 2011 07:45:24 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 1E13F3A6820 for ; Fri, 8 Apr 2011 07:45:24 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p38El75m024513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Apr 2011 09:47:07 -0500 (CDT) Received: from relay-out1.wc.genesyslab.com (relay-out1.wc.genesyslab.com [172.22.70.114]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p38El50F001419 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 8 Apr 2011 09:47:07 -0500 Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out1.wc.genesyslab.com (8.13.8+Sun/8.13.8) with ESMTP id p38El4nf013503; Fri, 8 Apr 2011 07:47:04 -0700 (PDT) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.93]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Apr 2011 07:47:04 -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, 8 Apr 2011 07:46:55 -0700 Message-ID: <059AF07365DC474393A19A3AF187DF7406E677EF@NAHALD.us.int.genesyslab.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Recording awareness indication Thread-Index: Acv0jt2kUmpsv464Rhe1hFUvohteYQAzLWaAACfi9LA= References: <4D9CBB90.4080804@cisco.com> From: "Henry Lum" To: "Charles Eckel (eckelcu)" , "Paul Kyzivat (pkyzivat)" , X-OriginalArrivalTime: 08 Apr 2011 14:47:04.0712 (UTC) FILETIME=[D3AD0880:01CBF5FB] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: Re: [siprec] Recording awareness indication X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 08 Apr 2011 14:45:25 -0000 Currently in the draft we propose to use an SDP attribute to declare the awareness. I saw comments that this should be changed to a feature tag instead. I am okay either way; are there arguments against using a feature tag? Regards, Henry > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Charles Eckel (eckelcu) > Sent: Thursday, April 07, 2011 3:45 PM > To: Paul Kyzivat (pkyzivat); siprec@ietf.org > Subject: Re: [siprec] Recording awareness indication >=20 > I agree with Paul. I would hate to force the addition of an audible > beep > or a red dot to all participants when a less intrusive mechanism is > supported. >=20 > Cheers, > Charles >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Paul Kyzivat (pkyzivat) > > Sent: Wednesday, April 06, 2011 12:14 PM > > To: siprec@ietf.org > > Subject: Re: [siprec] Recording awareness indication > > > > I liked this concept of an overt "opt-out" of the in-band indication. > > ISTM that if the UA has a "better" way of doing the indication it may > > not want the default mechanism. (E.g. The UA may want to apply its > own > > in-band indication. But that won't work well if a different one has > > already been applied.) > > > > If we can agree on the *concept* of opt-out, then we can determine > the > > exact form as a subsequent step. > > > > I suppose some SRCs may feel they are obliged to do their own > indication > > even if a participant desires to opt-out, and we ought to allow that > > too. In that case there should probably be some indication that the > > opt-out has been ignored, so that the UA can behave accordingly. > > > > Thanks, > > Paul > > > > On 4/6/2011 11:08 AM, Elwell, John wrote: > > > My own thoughts on this are that the SIP/SDP indication that > recording is in progress, even if sent > > to a UA known to be recording-aware, should not be used as a > substitute for other non-SIP/SDP means of > > notification that might otherwise be needed (e.g., an in-band audio > announcement). I think recording > > indicators should be used to complement other means. For example, an > in-band audio announcement would > > be able to reach all users (although might be problematic for > hearing-impaired users or for users > > speaking a different language). Despite such limitations, an in-band > announcement is often sufficient > > to satisfy legal requirements. On the other hand, a SIP/SDP > indication > that recording is in progress > > could be rendered in different ways and in different languages at the > user interface of a recording- > > aware UA. > > > > > > For this reason, I don't see a need for the recording-aware > indication in SIP/SDP. Recording > > indications can be sent without knowing whether they will be > understood by the receiving UA - if they > > are understood the user might get an enhanced indication - if not > they > will be discarded and the user > > will get only the basic (non-SIP/SDP) indication. > > > > > > John (as individual) > > > > > > > > >> -----Original Message----- > > >> From: siprec-bounces@ietf.org > > >> [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > > >> Sent: 06 April 2011 15:55 > > >> To: siprec@ietf.org > > >> Subject: [siprec] Recording awareness indication > > >> > > >> There was an inconclusive discussion in Prague on the > > >> recording awareness signalling indication in > > >> draft-portman-siprec-protocol (slide 6 / section 6.1 of > > >> draft). If I understand correctly, it indicates that a UA > > >> involved in the CS supports the SIPREC extensions relevant to > > >> the CS. In particular, it indicates that the UA would be able > > >> to understand SIP/SDP recording indications (slide 7 / > > >> section 6.2 of draft). It seems the recording awareness > > >> indication means that the SRC can rely on the recording > > >> indications in SIP/SDP to advise the user that recording is > > >> in progress, thereby avoiding the need for the SRC to provide > > >> suitable indications through non-SIP means (e.g., in-band > > >> audio announcements). > > >> > > >> Please continue this discussion. > > >> > > >> John (as chair) > > >> _______________________________________________ > > >> siprec mailing list > > >> siprec@ietf.org > > >> https://www.ietf.org/mailman/listinfo/siprec > > >> > > > _______________________________________________ > > > siprec mailing list > > > siprec@ietf.org > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > _______________________________________________ > > siprec mailing 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 john.elwell@siemens-enterprise.com Fri Apr 8 08:38:39 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DBB63A693B for ; Fri, 8 Apr 2011 08:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.584 X-Spam-Level: X-Spam-Status: No, score=-104.584 tagged_above=-999 required=5 tests=[AWL=2.015, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDiURe0m+Ao6 for ; Fri, 8 Apr 2011 08:38:37 -0700 (PDT) Received: from mail174.messagelabs.com (mail174.messagelabs.com [85.158.138.51]) by core3.amsl.com (Postfix) with SMTP id EE14F3A681F for ; Fri, 8 Apr 2011 08:38:36 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-14.tower-174.messagelabs.com!1302277220!16512202!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 10979 invoked from network); 8 Apr 2011 15:40:20 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-14.tower-174.messagelabs.com with SMTP; 8 Apr 2011 15:40:20 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id BC1D123F0330; Fri, 8 Apr 2011 17:40:20 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 8 Apr 2011 17:40:20 +0200 From: "Elwell, John" To: "Parthasarathi R (partr)" , "Paul Kyzivat (pkyzivat)" , "Muthu ArulMozhi Perumal (mperumal)" Date: Fri, 8 Apr 2011 17:40:19 +0200 Thread-Topic: [siprec] RTP model Thread-Index: Acv0pMhL/9tcjBrHQ8S/VnX3urvT+wBSNLoQAAVNazA= Message-ID: References: <4D9C711B.6070205@cisco.com><1D062974A4845E4D8A343C65380492020523BAF6@XMB-BGL-414.cisco.com> <4D9CE04B.7030704@cisco.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] RTP model X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 08 Apr 2011 15:38:39 -0000 >From the various contributors do date on this thread, it sounds like people= are in favour of some flexibility as to how the SRC behaves. I think we ne= ed something written down in the architecture document on this, enumerating= the possibilities, perhaps in a new section, and it probably requires some= body with a reasonable understanding of RFC 3550 to do this. Any volunteers= ? John > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi R (partr) > Sent: 08 April 2011 14:47 > To: Paul Kyzivat (pkyzivat); Muthu ArulMozhi Perumal (mperumal) > Cc: siprec@ietf.org > Subject: Re: [siprec] RTP model >=20 > I'm not RTP guy but I'm writing the mail based on SIPREC=20 > understanding. > In terms of SIPRC, SRC may be one of the following combination as per > the architecture >=20 > 1) UA(CS) + UA (RS) > 2) B2BUA (CS) + UA(RS) > 3) focus (CS) + UA (RS) > 4) Non-SIP to UA(CS) + UA(RS). Non-sip may be PSTN, H.323, Jingle, > RTCweb etc., > 5) Non-SIP to Non-SIP (CS) + UA(RS) - different permutation & > combination possible here=20 >=20 > IMO, SRC MAY support any of the RTP model like RTP=20 > translator, RTP mixer > or RTP endpoint and there is no restriction specific to SIPREC. How CS > RTP information passes to RS RTP is implementation specific.=20 > Say one SRC > which has (B2BUA + UA) may prefer to acts as RTP translator > (forwarding) towards RS session whereas another SRC which has (B2BUA + > UA) may prefer to RTP Endpoint towards RS Session. Till now,=20 > we haven't > come across any restriction in RTP model specific to SIPREC. >=20 > The question raised in IETF-80 is "multiple stream in single=20 > port" usage > w.r.t metadata format. Here there two usecase: >=20 > 1) "multiple stream in single port" for each participant=20 > (individually) > - Here multiple stream is related to multiple sources of stream > which has different SSRC but it belongs to single participant. It is > possible for SRC to act as RTP translator (forwarder) in case SRC is a > middle box (B2BUA, SBC) >=20 > 2) "multiple stream in single port" for multiple participants=20 > - Here SRC > has to combine all stream from different participant together whereas > SRC has to act as RTP Endpoint. Please correct me incase I missed > understand the translator functionality. Please note that it is SRC > implementation choice. There is no need of restricting this=20 > stuff but I > really don't know the reason for doing this by SRC. >=20 > SRS is RTP Endpoint which store or perform real-time analysis of > RTP/RTCP packet instead of play in the endpoint. Here, I like to hear > from folks that any more restriction above RFC 3550 is=20 > required which is > specific to SIPREC. >=20 > Thanks > Partha =20 >=20 > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf > Of Paul Kyzivat (pkyzivat) > Sent: Thursday, April 07, 2011 3:21 AM > To: Muthu ArulMozhi Perumal (mperumal) > Cc: siprec@ietf.org > Subject: Re: [siprec] RTP model >=20 >=20 >=20 > On 4/6/2011 10:57 AM, Muthu ArulMozhi Perumal (mperumal) wrote: > > I agree we should keep the models open to cater to different > use-cases. > > However, for the most common ones we anticipate, I think we should=20 > > have clear guidelines/recommendations on how it=20 > must/should/may work=20 > > to achieve basic interop among implementations of that=20 > model. For e.g, >=20 > > the translator model for SRC looks a simple one that would=20 > cater to a=20 > > large number of cases and we might want to have clear=20 > > guidelines/recommendations on how RTP and RTCP should be handled for > it. >=20 > I don't know a lot about RTP, but the above seems right to me - each > different way the SRC might relate to the RTP will need some > specification. >=20 > Thanks, > Paul >=20 > > thanks, > > Muthu > > > > |-----Original Message----- > > |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Paul Kyzivat (pkyzivat) > > |Sent: Wednesday, April 06, 2011 7:27 PM > > |To: siprec@ietf.org > > |Subject: Re: [siprec] RTP model > > | > > |I am definitely not an expert on this subject, but ISTM=20 > that making a >=20 > > |choice about one of these models would inordinately limit > > implementation > > |choices for the SRC. IMO we want to provide a lot of=20 > latitude for SRC >=20 > > |implementation, even if it means complicating life for the SRS. > > | > > | Thanks, > > | Paul > > | > > |On 4/6/2011 4:05 AM, Elwell, John wrote: > > |> There were discussions before and during the Prague=20 > meeting about > > multiplexing media streams from > > |different participants on to the same port. It became=20 > apparent that=20 > > |we > > need a better understanding of > > |the RTP model we are using first, before we can answer this. > > |> > > |> The question is whether the SRC acts as a translator or=20 > as a mixer >=20 > > |> or > > end system. > > |> > > |> A translator is defined in RFC 3550 as: > > |> "An intermediate system that forwards RTP packets > > |> with their synchronization source identifier intact. =20 > > |> Examples > > of > > |> translators include devices that convert=20 > encodings without > > mixing, > > |> replicators from multicast to unicast, and > application-level > > |> filters in firewalls." > > |> > > |> A mixer or end system, in contrast, would assign new=20 > > |> synchronisation > > sources to RTP packets. > > |> > > |> The translator model seems to require less processing=20 > in the SRC - > > RTP packets would just be > > |forwarded unchanged to the SRC (i.e., the UDP packet would=20 > change but > > its RTP payload would be > > |unchanged). > > |> > > |> However, the translator model prevents some capabilities, e.g.: > > |> - the SRC cannot transcode (e.g., if the SRS does not=20 > support the > > codec used in the CS); > > |> - the SRC cannot mix streams from different=20 > participants (e.g., to > > reduce the bandwidth required on > > |the RS path); > > |> - the SRC cannot encrypt streams on the RS path if=20 > unencrypted on=20 > > |> the > > CS path or vice versa; > > |> - the SRC cannot use different encryption keys on the=20 > CS path and=20 > > |> the > > RS path. > > |> > > |> Therefore, although the translator model might work in some > > situations, it probably can't satisfy > > |all requirements. > > |> > > |> Also with the translator model, we would need to be=20 > clear how RTCP > > would work. Consider an SRC at a > > |B2BUA. It receives RTP packets from party A, forwards them as a > > translator to party B, and also > > |forwards them as a translator to the SRS. The SRC will receive RTCP > > packets from both party B and the > > |SRS and needs to send RTCP packets to party A - how does the SRC=20 > > |handle > > this? > > |> > > |> John (as individual) > > |> > > |> > > |> _______________________________________________ > > |> siprec mailing 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 Fri Apr 8 08:51:56 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D90F53A693B for ; Fri, 8 Apr 2011 08:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lx2jYgxsOcgS for ; Fri, 8 Apr 2011 08:51:55 -0700 (PDT) Received: from mail21.messagelabs.com (mail21.messagelabs.com [85.158.143.35]) by core3.amsl.com (Postfix) with SMTP id 490E53A6819 for ; Fri, 8 Apr 2011 08:51:55 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1302278014!36714929!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 20419 invoked from network); 8 Apr 2011 15:53:34 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-12.tower-21.messagelabs.com with SMTP; 8 Apr 2011 15:53:34 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id B7C1F23F0330; Fri, 8 Apr 2011 17:53:39 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 8 Apr 2011 17:53:39 +0200 From: "Elwell, John" To: Paul Kyzivat , "siprec@ietf.org" Date: Fri, 8 Apr 2011 17:53:38 +0200 Thread-Topic: [siprec] start/stop times & the metamodel Thread-Index: Acv0oYMbT8y82ywBTzuRpmDOUt9OMQBYnJrw Message-ID: References: <4D9CDADD.1020403@cisco.com> In-Reply-To: <4D9CDADD.1020403@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] start/stop times & the metamodel X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 08 Apr 2011 15:51:56 -0000 Paul, I think much of what you say makes sense. I was concerned that we probably = need to record when a participant stops or starts sending or receiving a st= ream, which seems to be covered by your statement: "Changes to media stream= s should similarly be tagged with the time they occurred in the CS signalin= g. Each participant relationship change (send, receive, inactive,) will be = there." That doesn't seem to be in the model at present. John (as individual) =20 > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 06 April 2011 22:28 > To: siprec@ietf.org > Subject: [siprec] start/stop times & the metamodel >=20 > In Prague, one of the open issues was around start/stop times. The=20 > format draft floated the possibility of having explicit=20 > start/stop times=20 > signaled for each of the metatdata elements. But then we asked for=20 > feedback on which make sense. >=20 > IMO explicit start/stop times make more sense for some things=20 > than others. >=20 > One place where we potentially have explicit times to report with the=20 > dialogs that constitute a CS. Each such dialog presumably has a start=20 > and stop time observable by the SRC, which might differ, at=20 > least a bit,=20 > from the corresponding signaling on the RS. >=20 > We might want to report those times. Or, since we abstract=20 > the CS away=20 > from the dialog, we might want to report the start time of the first=20 > dialog in the CS as the CS start time, and the stop time of the last=20 > dialog in the CS as the CS stop time. >=20 > Similarly, we have abstracted media streams away from the=20 > media streams=20 > in the sip dialogs that make up the CS. We might want to report the=20 > start time of a media stream as the time (according to the CS) of the=20 > first participant to a new media stream, and the stop time as=20 > the time=20 > that the last participant leaves the media stream. >=20 > There are several things that complicate this: >=20 > - Do we consider the case of a stream that starts with recvonly > or inactive participants, and only later gets a sender? If so, > is the start time of the stream when the first participant arrived, > or when the first sender arrived? >=20 > - How do we get the clock times for the media streams? > IIUC the correct ones are in the RTP/RTCP, but the reporting of > these events is driven by the signaling, and we don't have good > sync between those. (E.g. media could start flowing before the > corresponding signaling, and we would like to include that if we > can figure it out.) So, even if the clocks used for media and > signaling are in sync, we might see media packets arrive with > a timestamp prior to the timestamp for the signaling that > indicates the send state of the participant. This could cause > trouble in playback. >=20 > - There isn't any guarantee that the clock used for signaling > messages is synchronized with the clock used in RTP/RTCP. >=20 > - There isn't any guarantee that there will be any RTCP at all, > to provide correlation of the RTP to clocktime. >=20 > The best I can see to deal with all of this is: >=20 > - All the metadata messages should be timestamped by the SRC > using its local clock. This is easily achieved by the Date > header in the sip message. >=20 > - Changes to a CS, including changes of participants, should > be explicitly tagged with the time they occurred in the > CS signaling, according to the SRC's clock. (If that is > unavailable for some reason, then use the time the SRC > became aware of it.) >=20 > - We could provide a metadata update element to indicate end > of a CS, but I suggest this just be shorthand for indicating > removal of all participants from it. (While its possible to > mark that the CS is truly ended, that simply introduces an > error case if added metadata about it is subsequently sent.) > The actual start/stop time would be determined by the SRS > based on the timestamps of first and last data about it. >=20 > - Changes to media streams should similarly be tagged with > the time they occurred in the CS signaling. Each participant > relationship change (send, receive, inactive,) will be there. > The actual start/stop time of the media stream again would be > derived by the SRS. >=20 > - CS-Groups can simply be tagged by the timestamps of the > updates that put CSs into them. Explicit start/stop times don't > seem useful. If desired, the SRS can derive start/stop times > from the start/stop times of the contained stuff. >=20 > - I now think that CS-Groups should not be "contained" within > a recording. This just seems to introduce unnecessary error > conditions, and limitations on future enhancements. The > lifetime of CS-Groups will probably be naturally limited by > the ability of the SRC to remember the IDs of old ones. > For instance, if a CS-G is created during one Recording, > and then another CS is added to it from a different recording > session, would we prefer to fail that, or just allow it? > (I think allow.) >=20 > - Rather, I think every update transmitted during a recording > session can be tagged with a link to the metadata of the > recording session it came from. This need not be explicit - the > SRS can do it automatically. The recording session entity > itself will also have a start/stop time which is the start/ > stop of the RS dialog as observed by the SRS. >=20 > (Note the above doesn't solve the problem of getting correct=20 > clock times=20 > for RTP media. If anyone has a suggestion for this I'm all ears.) >=20 > Thanks, > Paul > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > = From john.elwell@siemens-enterprise.com Fri Apr 8 08:55:39 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9E663A6946 for ; Fri, 8 Apr 2011 08:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.614 X-Spam-Level: X-Spam-Status: No, score=-104.614 tagged_above=-999 required=5 tests=[AWL=1.985, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8IN34BCguBqr for ; Fri, 8 Apr 2011 08:55:38 -0700 (PDT) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by core3.amsl.com (Postfix) with SMTP id 1B55B3A693B for ; Fri, 8 Apr 2011 08:55:37 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1302278240!21690272!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 17981 invoked from network); 8 Apr 2011 15:57:20 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-3.tower-27.messagelabs.com with SMTP; 8 Apr 2011 15:57:20 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id B719D1EB8338; Fri, 8 Apr 2011 17:57:22 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 8 Apr 2011 17:57:22 +0200 From: "Elwell, John" To: Paul Kyzivat , "siprec@ietf.org" Date: Fri, 8 Apr 2011 17:57:21 +0200 Thread-Topic: [siprec] AD review: draft-ietf-siprec-req-08 Thread-Index: Acv0o5MDPXoAJW21QmCRVuuf52nmIwBYcOqQ Message-ID: References: <4D89D801.8040308@ericsson.com> <07465C1D981ABC41A344374066AE1A2C38AB466348@TLVMBX01.nice.com> <07465C1D981ABC41A344374066AE1A2C38AB4669F4@TLVMBX01.nice.com> <4D9CDE43.4040909@cisco.com> In-Reply-To: <4D9CDE43.4040909@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] AD review: draft-ietf-siprec-req-08 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 08 Apr 2011 15:55:39 -0000 Paul, I think we have moved in a different direction from what Leon suggested bel= ow - see -09 and Ken's slides from Prague. If you have concerns about what = is in the requirements document, please respond to IETF last call. However,= the points you make below will be relevant for the protocol document at so= me stage. John (as chair) =20 > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 06 April 2011 22:42 > To: siprec@ietf.org > Subject: Re: [siprec] AD review: draft-ietf-siprec-req-08 >=20 > Just to be clear - do you consider mandatory to implement=20 > distinct from=20 > mandatory to *use*? (IOW, that an administrator deploying siprec=20 > compliant products might configure them to not use some of=20 > these features.) >=20 > IMO: > - most things are mandatory to implement in the SRS. > Which are used is determined mostly by behavior of the SRC. > We aren't defining the form or content of the actual recorded > data/metadata, so the only definition of compliance we have > will be based on how it interacts with an SRC. > - the basic mechanisms are probably mandatory to implement > in the SRC, but there should be a lot of latitude. There are > many ways to hook an SRC into CSs, so there can be a lot of > special purpose SRCs that focus on a particular way of fitting > in. Some of them will have more access to metadata than others. > If they can't discover a certain sort of metadata then they > will not be delivering it, and so don't need support for doing > so. > - an SRC implementation may provide ways for an administrator > to turn off a variety of things so that they aren't used. > But we will have to draw a line somewhere - at some point if > you have turned too much off it will cease to be identifiable > as an SRC. >=20 > Thanks, > Paul >=20 > On 3/28/2011 4:42 AM, Leon Portman wrote: > > Hi, > > > > Following AD comments, I am proposing to indicate that=20 > following requirements are mandatory to implement, in=20 > contrast for other requirements that are mandatory for the=20 > protocol to support but optional for implementation depending=20 > use cases: > > > > 1. REQ-001 - implement SIP based protocol > > 2. REQ-012 - metadata reporting support > > 3. REQ-013 - map between participant and media > > 4. REQ-022 - wall clock reporting for media synchronization > > 5. REQ-023 - wall clock, assuming pause/resume is used > > 6. REQ 27-30 are mandatory security requirements > > > > Leon > > > > -----Original Message----- > > From: Leon Portman > > Sent: Monday, March 28, 2011 10:39 AM > > To: 'Elwell, John'; Gonzalo Camarillo; siprec@ietf.org; Ken=20 > Rehor (krehor) (krehor@cisco.com) > > Subject: RE: [siprec] AD review: draft-ietf-siprec-req-08 > > > >> -----Original Message----- > >> From: siprec-bounces@ietf.org > >> [mailto:siprec-bounces@ietf.org] On Behalf Of Gonzalo Camarillo > >> Sent: Wednesday, March 23, 2011 1:23 PM > >> To: siprec@ietf.org > >> Subject: [siprec] AD review: draft-ietf-siprec-req-08 > >> > >> Hi, > >> > >> the SIPREC WG requested the publication of the following=20 > draft a few > >> days ago. Please, find below my AD review. > >> > >> https://datatracker.ietf.org/doc/draft-ietf-siprec-req/ > >> > >> Given that the draft contains both requirements and use=20 > cases, you may > >> want to edit the title so that it reads "Use Cases and Requirements > >> for ..." > >> > >> Typically, Section 1 contains the Introduction and Section 2 the > >> terminology. You may want to swap both sections. > >> > >> Most of the requirements are phrased so that they describe > >> capabilities that need to be supported by the system (e.g., the > >> mechanism MUST provide the SRS with the means to ...) but=20 > that do not > >> need to be necessarily used (e.g., a particular use case=20 > may not make > >> use of that functionality). However, some requirements are=20 > phrased so > >> that the functionality needs to be used (e.g., the mechanism MUST > >> provide the SRS the wall clock time ...). Requirements 12,=20 > 22, 23, 27, > >> 28, and 29 seem to fall into the latter category. Could you please > >> check whether that was the intention with all those requirements? > >> > >> A few requirements relate to the security and privacy related > >> properties of the SRC-SRS interface (e.g., requirements 24 and 29). > >> However, the draft does not discuss how the security and privacy of > >> that interface relate to the security and privacy level=20 > used for the > >> CS being recorded. > >> For example, can the confidentiality level of the media=20 > going from the > >> SRC and the SRS be lower than that of the media flowing between the > >> actual participants of the CS? If you decide there should not be a > >> requirement on this area, you need to at least discuss this issue > >> (probably in Sections 6 or 7). > >> > >> Once you address these comments, I will request the IETF-wide last > >> call for this draft. > >> > >> Thanks, > >> > >> Gonzalo > >> > >> _______________________________________________ > >> siprec mailing list > >> siprec@ietf.org > >> https://www.ietf.org/mailman/listinfo/siprec > >> > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > = From john.elwell@siemens-enterprise.com Fri Apr 8 09:03:49 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 385A53A6905 for ; Fri, 8 Apr 2011 09:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.029 X-Spam-Level: X-Spam-Status: No, score=-102.029 tagged_above=-999 required=5 tests=[AWL=-0.630, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_32=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ac5r203tfVP1 for ; Fri, 8 Apr 2011 09:03:48 -0700 (PDT) Received: from mail216.messagelabs.com (mail216.messagelabs.com [85.158.143.99]) by core3.amsl.com (Postfix) with SMTP id 7DB053A680A for ; Fri, 8 Apr 2011 09:03:47 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-14.tower-216.messagelabs.com!1302278732!1755857!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 21158 invoked from network); 8 Apr 2011 16:05:32 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-14.tower-216.messagelabs.com with SMTP; 8 Apr 2011 16:05:32 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id F2A8123F0330; Fri, 8 Apr 2011 18:05:31 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 8 Apr 2011 18:05:32 +0200 From: "Elwell, John" To: "Parthasarathi R (partr)" , "Paul Kyzivat (pkyzivat)" , "siprec@ietf.org" Date: Fri, 8 Apr 2011 18:05:30 +0200 Thread-Topic: [siprec] Partial updates and identifiers Thread-Index: Acv0jVXI4ji2YTo+SquJ6T6YR3i+lQAdOkDgAEETmvA= Message-ID: References: <4D9CB8E1.7030402@cisco.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: "Peter Saint-Andre \(psaintan\)" , "Joe Hildebrand \(jhildebr\)" , Hadriel Kaplan Subject: Re: [siprec] Partial updates and identifiers X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 08 Apr 2011 16:03:49 -0000 Focusing just on participant and stream for the time being, do these need t= o be unique across multiple CSs or not? John=20 > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com]=20 > Sent: 07 April 2011 10:51 > To: Paul Kyzivat (pkyzivat); siprec@ietf.org; Elwell, John > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe=20 > Hildebrand (jhildebr) > Subject: RE: [siprec] Partial updates and identifiers >=20 > John, >=20 > Sorry for the lengthy mail but it contains lot of analysis=20 > and reasoning > for this id approach.=20 >=20 > Adding to Paul's point, I wish to give more background and reason for > these globally unique id. Initially I had the impression that=20 > the single > unique id (RS dialog-id) in the recording (session level) and some > relevant natural id for the rest of the element will serve=20 > the purpose. > There are usecases where this assumption fails. Even I have thought of > using "xml:id" instead of URN UUID to avoid long string but xml:id may > not end up with unique value always. Our analysis for URN=20 > UUID for each > level is as follows and please provide your input in case id shall be > tweaked: >=20 > 1) Recording block: The reason for globally unique id is that multiple > SRC with same id to single SRS.=20 >=20 > Topology: >=20 > SRC1 SRC2 > | | > | ----(RS1-ID1)-----SRS1 > | > ---(RS2-ID1)------------------SRS1 >=20 > In the above topology, it is possible for ID1 is generated by=20 > both SRC1 > and SRC2 at the same time.=20 >=20 > 2) group (CSG) block: Grouping mechanism (Hadriel session-id,=20 > Paul Jones > Session-UUID) is outside the scope of SIPREC. URN UUID abstracts the > exact mechanism to SRS and provides the information only=20 > about the group > of CS from SRC perspective. It possible that group may span across > multiple RS and It is up to SRS to group and view as single recording. > Here, the single level id in the top will fail. The counter=20 > argument is > to force the single RS having complete CSG but it*may not* be possible > in SRC implementation. Here, xml:id will not serve the purpose >=20 > 3) session (CS) block: At the immediate look, session falls exactly > under recording block. Use case 3 of draft-ietf-siprec-req-09 > illustrates where CS span across multiple RS. This=20 > requirement calls for > unique id in session by which these session shall be viewed=20 > as single CS > even though there is no group exists among them. IMO, in case session > should not have globally unique id, then it is preferred to remove > usecase 3 in the requirement. >=20 > 4) participant block: It needs some id which may be AOR but AOR is not > unique. IMO, xml:id may serve the purpose with session unique id. The > trick exists for participant who are not associated with CS. We shall > discuss and fine tune if required. >=20 > 5) stream block: Label attribute shall be used as unique value but RFC > 4574 does not mandate label attribute has to be unique across=20 > the dialog > or CS and so, it may possible to change within RS and no normative > statement to stop this implementation. IMO, xml:id may serve=20 > the purpose > with session unique id. Here as well, We shall discuss and=20 > fine tune if > required. >=20 > 6) extensiondata block: This is tracked in the separate mail thread > whether unique id is required or not. Let us close this as=20 > part of that > mail thread. >=20 > Including explicitly Hadriel, Peter, Joe in this mail thread as they > have different view on this ID mechanism.=20 >=20 > I had offline discussion with Hadriel in Prague after SIPREC=20 > meeting and > my understanding of his major concern is that how SRS will be able to > design the database in case partial update does not have=20 > recording (top) > id information. I'll put more thought processing to close Hadriel > concern of how top id has to be tracked in case partial=20 > update by which > SRS implementation will be simplified in terms of aggregation > maintenance. >=20 > Thanks > Partha >=20 > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf > Of Paul Kyzivat (pkyzivat) > Sent: Thursday, April 07, 2011 12:33 AM > To: siprec@ietf.org > Subject: Re: [siprec] Partial updates and identifiers >=20 > John, >=20 > For the moment we have proposed that the ids be conveyed in=20 > the form of > URIs that are globally unique, and specifically that they be=20 > UUID URNs.=20 > There is no dependency on the particular form of the URI, but=20 > specifying > they must be UUID URNs makes it possible to perform some internal > optimizations for storage. >=20 > The UUID URN is a pretty inefficient encoding. A UUID can be expressed > in 32 bits, so we could consider retaining UUIDs but alter=20 > the encoding > if its really an issue. However I am far from convinced that=20 > the size of > the IDs is going to be a major issue in the overall size of=20 > messages, so > I think its probably premature to worry about it. >=20 > Because the ids can be expressed in 32 bits, the SRC and SRS can store > them internally that way, thus reducing the runtime cost of=20 > maintaining > the data. >=20 > The use of unique ids is a significant part of the overall approach to > formatting updates. If somebody has a different concept in=20 > mind it could > be useful to have an alternative proposal for the format. If=20 > we had two > worked out approaches we could compare the tradeoffs in each. >=20 > Thanks, > Paul >=20 > On 4/6/2011 10:24 AM, Elwell, John wrote: > > Much of the discussion on draft-ram-metadata-format in Prague > concerned the mechanism for performing partial updates and the use of > identifiers. The draft permits partial updates by allowing individual > objects (e.g., CS, participant, media stream) to be sent with updated > content, without having to send again other objects that have not > changed. So, for example, in a large conference, it would be=20 > possible to > add or modify an individual participant object without having to send > all the other participant objects again. I do not recall any=20 > opposition > to this basic principle. > > > > However, to achieve this, every object requires an=20 > identifier, and it > was asserted that these identifiers need to be globally unique for all > time. Although this might be efficient for updating an individual > object, when sending many objects (e.g., at the start of a CS or when > refreshing the entire metadata), this can make the metadata=20 > very bulky. > It depends, of course, on the format of the identifiers, and it was > stated that there could be alternatives to UUID. Nevertheless, some > people had concerns. These concerns also extended to the impact on the > database where metadata is stored, since it might not be feasible to > convert to a database-friendly mechanism for linking objects together. > > > > One alternative proposal during the meeting was to have a single > unique identifier at the top level (for the RS) and use local > identifiers for other objects. Thus when updating a single object, it > would be necessary to include the top level identifier as=20 > well as one or > more local identifiers. However, there were also concerns=20 > this might not > fulfil actual or perceived future requirements. > > > > Please continue discussion on this. > > > > John (as chair) > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > = From mperumal@cisco.com Fri Apr 8 10:15:16 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD1B33A68D4 for ; Fri, 8 Apr 2011 10:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.574 X-Spam-Level: X-Spam-Status: No, score=-10.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6xzq3exZTvna for ; Fri, 8 Apr 2011 10:15:15 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id EAE413A696F for ; Fri, 8 Apr 2011 10:15:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=8232; q=dns/txt; s=iport; t=1302283020; x=1303492620; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=aqJbZisDhoHpEfuoqrxkYQx/Ebl3+WGhYqb3w/CLaCg=; b=CZsZxgcWOQvpNgZ3evt22pNHUbscxUl93BejrEsu4KTsnZ5NAvC5GKSZ hoPTvPrSDwMgkHUEIZc6A5DLOasYSwETOed5FaYLp6sBEnvXde3mhOC08 DEwKuQmErHDpbfg0YIh5mKc3HIL8G7IN9fV9cLWHP2hjMi+R96cL23MAT s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArgAAGxCn02Q/khNgWdsb2JhbACYQY1UFAEBFiYlpEicIIVtBIVTi2w X-IronPort-AV: E=Sophos;i="4.63,324,1299456000"; d="scan'208";a="82823137" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 08 Apr 2011 17:16:59 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p38HGvqV010752; Fri, 8 Apr 2011 17:16:59 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Apr 2011 22:46:56 +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: Fri, 8 Apr 2011 22:46:51 +0530 Message-ID: <1D062974A4845E4D8A343C65380492020523C18A@XMB-BGL-414.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] RTP model Thread-Index: Acv0pMhL/9tcjBrHQ8S/VnX3urvT+wBSNLoQAAVNazAAAtnNcA== References: <4D9C711B.6070205@cisco.com><1D062974A4845E4D8A343C65380492020523BAF6@XMB-BGL-414.cisco.com><4D9CE04B.7030704@cisco.com> From: "Muthu ArulMozhi Perumal (mperumal)" To: "Elwell, John" , "Parthasarathi R (partr)" , "Paul Kyzivat (pkyzivat)" X-OriginalArrivalTime: 08 Apr 2011 17:16:56.0772 (UTC) FILETIME=[C35C8040:01CBF610] Cc: siprec@ietf.org Subject: Re: [siprec] RTP model X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 08 Apr 2011 17:15:17 -0000 I volunteer to take this forward. Ram, Charles and I are having offline discussions on this and we will get back with our thoughts to the group. Muthu |-----Original Message----- |From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] |Sent: Friday, April 08, 2011 9:10 PM |To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); Muthu ArulMozhi Perumal (mperumal) |Cc: siprec@ietf.org |Subject: RE: [siprec] RTP model | |From the various contributors do date on this thread, it sounds like people are in favour of some |flexibility as to how the SRC behaves. I think we need something written down in the architecture |document on this, enumerating the possibilities, perhaps in a new section, and it probably requires |somebody with a reasonable understanding of RFC 3550 to do this. Any volunteers? | |John | |> -----Original Message----- |> From: siprec-bounces@ietf.org |> [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi R (partr) |> Sent: 08 April 2011 14:47 |> To: Paul Kyzivat (pkyzivat); Muthu ArulMozhi Perumal (mperumal) |> Cc: siprec@ietf.org |> Subject: Re: [siprec] RTP model |> |> I'm not RTP guy but I'm writing the mail based on SIPREC |> understanding. |> In terms of SIPRC, SRC may be one of the following combination as per |> the architecture |> |> 1) UA(CS) + UA (RS) |> 2) B2BUA (CS) + UA(RS) |> 3) focus (CS) + UA (RS) |> 4) Non-SIP to UA(CS) + UA(RS). Non-sip may be PSTN, H.323, Jingle, |> RTCweb etc., |> 5) Non-SIP to Non-SIP (CS) + UA(RS) - different permutation & |> combination possible here |> |> IMO, SRC MAY support any of the RTP model like RTP |> translator, RTP mixer |> or RTP endpoint and there is no restriction specific to SIPREC. How CS |> RTP information passes to RS RTP is implementation specific. |> Say one SRC |> which has (B2BUA + UA) may prefer to acts as RTP translator |> (forwarding) towards RS session whereas another SRC which has (B2BUA + |> UA) may prefer to RTP Endpoint towards RS Session. Till now, |> we haven't |> come across any restriction in RTP model specific to SIPREC. |> |> The question raised in IETF-80 is "multiple stream in single |> port" usage |> w.r.t metadata format. Here there two usecase: |> |> 1) "multiple stream in single port" for each participant |> (individually) |> - Here multiple stream is related to multiple sources of stream |> which has different SSRC but it belongs to single participant. It is |> possible for SRC to act as RTP translator (forwarder) in case SRC is a |> middle box (B2BUA, SBC) |> |> 2) "multiple stream in single port" for multiple participants |> - Here SRC |> has to combine all stream from different participant together whereas |> SRC has to act as RTP Endpoint. Please correct me incase I missed |> understand the translator functionality. Please note that it is SRC |> implementation choice. There is no need of restricting this |> stuff but I |> really don't know the reason for doing this by SRC. |> |> SRS is RTP Endpoint which store or perform real-time analysis of |> RTP/RTCP packet instead of play in the endpoint. Here, I like to hear |> from folks that any more restriction above RFC 3550 is |> required which is |> specific to SIPREC. |> |> Thanks |> Partha |> |> -----Original Message----- |> From: siprec-bounces@ietf.org |> [mailto:siprec-bounces@ietf.org] On Behalf |> Of Paul Kyzivat (pkyzivat) |> Sent: Thursday, April 07, 2011 3:21 AM |> To: Muthu ArulMozhi Perumal (mperumal) |> Cc: siprec@ietf.org |> Subject: Re: [siprec] RTP model |> |> |> |> On 4/6/2011 10:57 AM, Muthu ArulMozhi Perumal (mperumal) wrote: |> > I agree we should keep the models open to cater to different |> use-cases. |> > However, for the most common ones we anticipate, I think we should |> > have clear guidelines/recommendations on how it |> must/should/may work |> > to achieve basic interop among implementations of that |> model. For e.g, |> |> > the translator model for SRC looks a simple one that would |> cater to a |> > large number of cases and we might want to have clear |> > guidelines/recommendations on how RTP and RTCP should be handled for |> it. |> |> I don't know a lot about RTP, but the above seems right to me - each |> different way the SRC might relate to the RTP will need some |> specification. |> |> Thanks, |> Paul |> |> > thanks, |> > Muthu |> > |> > |-----Original Message----- |> > |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On |> > Behalf Of Paul Kyzivat (pkyzivat) |> > |Sent: Wednesday, April 06, 2011 7:27 PM |> > |To: siprec@ietf.org |> > |Subject: Re: [siprec] RTP model |> > | |> > |I am definitely not an expert on this subject, but ISTM |> that making a |> |> > |choice about one of these models would inordinately limit |> > implementation |> > |choices for the SRC. IMO we want to provide a lot of |> latitude for SRC |> |> > |implementation, even if it means complicating life for the SRS. |> > | |> > | Thanks, |> > | Paul |> > | |> > |On 4/6/2011 4:05 AM, Elwell, John wrote: |> > |> There were discussions before and during the Prague |> meeting about |> > multiplexing media streams from |> > |different participants on to the same port. It became |> apparent that |> > |we |> > need a better understanding of |> > |the RTP model we are using first, before we can answer this. |> > |> |> > |> The question is whether the SRC acts as a translator or |> as a mixer |> |> > |> or |> > end system. |> > |> |> > |> A translator is defined in RFC 3550 as: |> > |> "An intermediate system that forwards RTP packets |> > |> with their synchronization source identifier intact. |> > |> Examples |> > of |> > |> translators include devices that convert |> encodings without |> > mixing, |> > |> replicators from multicast to unicast, and |> application-level |> > |> filters in firewalls." |> > |> |> > |> A mixer or end system, in contrast, would assign new |> > |> synchronisation |> > sources to RTP packets. |> > |> |> > |> The translator model seems to require less processing |> in the SRC - |> > RTP packets would just be |> > |forwarded unchanged to the SRC (i.e., the UDP packet would |> change but |> > its RTP payload would be |> > |unchanged). |> > |> |> > |> However, the translator model prevents some capabilities, e.g.: |> > |> - the SRC cannot transcode (e.g., if the SRS does not |> support the |> > codec used in the CS); |> > |> - the SRC cannot mix streams from different |> participants (e.g., to |> > reduce the bandwidth required on |> > |the RS path); |> > |> - the SRC cannot encrypt streams on the RS path if |> unencrypted on |> > |> the |> > CS path or vice versa; |> > |> - the SRC cannot use different encryption keys on the |> CS path and |> > |> the |> > RS path. |> > |> |> > |> Therefore, although the translator model might work in some |> > situations, it probably can't satisfy |> > |all requirements. |> > |> |> > |> Also with the translator model, we would need to be |> clear how RTCP |> > would work. Consider an SRC at a |> > |B2BUA. It receives RTP packets from party A, forwards them as a |> > translator to party B, and also |> > |forwards them as a translator to the SRS. The SRC will receive RTCP |> > packets from both party B and the |> > |SRS and needs to send RTCP packets to party A - how does the SRC |> > |handle |> > this? |> > |> |> > |> John (as individual) |> > |> |> > |> |> > |> _______________________________________________ |> > |> siprec mailing 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 partr@cisco.com Mon Apr 11 00:34:37 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C53753A6AE0 for ; Mon, 11 Apr 2011 00:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.189 X-Spam-Level: X-Spam-Status: No, score=-9.189 tagged_above=-999 required=5 tests=[AWL=-0.390, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d7OMtBkw77ZE for ; Mon, 11 Apr 2011 00:34:36 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id A55763A6ADF for ; Mon, 11 Apr 2011 00:34:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=9088; q=dns/txt; s=iport; t=1302507276; x=1303716876; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=7vWZ+cfMFPDCN1BK2DFZcbHnBhpw0zfLUEuLC+oOpo0=; b=Dpjzd91JdlaP4KZq37P1+Q7ck/PfKXUJQbKDhZ0DvGnDcaX9b/aqH6po i3J/HmcSDK+w/1pkCfEAgz+UzQhSpISzr1NUtqqj2Z0DsPm7TvJgPA4eL yGzjjl/XtMpxIh51RfqW88awNNwwIZhsJKMbMGKepq1MpkvG6JnrcmRz7 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAAPetok2Q/khNgWdsb2JhbACYQY1YFAEBFiYliHqcG5snhW4EhVmLcA X-IronPort-AV: E=Sophos;i="4.63,338,1299456000"; d="scan'208";a="83011372" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 11 Apr 2011 07:34:35 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3B7YXAg030713; Mon, 11 Apr 2011 07:34:34 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 11 Apr 2011 13:04:33 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 11 Apr 2011 13:04:33 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Partial updates and identifiers Thread-Index: Acv0jVXI4ji2YTo+SquJ6T6YR3i+lQAdOkDgAEETmvAAg54qsA== References: <4D9CB8E1.7030402@cisco.com> From: "Parthasarathi R (partr)" To: "Elwell, John" , "Paul Kyzivat (pkyzivat)" , X-OriginalArrivalTime: 11 Apr 2011 07:34:33.0872 (UTC) FILETIME=[E7025900:01CBF81A] Cc: "Peter Saint-Andre \(psaintan\)" , "Joe Hildebrand \(jhildebr\)" , Hadriel Kaplan Subject: Re: [siprec] Partial updates and identifiers X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 11 Apr 2011 07:34:37 -0000 John, As I mentioned below, stream block will be unique within CS, (not required to be unique across multiple CS) and so, xml:id or enhancing the normative statement of RFC 4574 label attribute to be unique within CS will serve the purpose. I'm fine with any of the above mentioned id. Please note that RFC 4574 "label" attribute is the nature data for RS dialog. In case participant within CS, xml:id will serve the purpose but we need to get more clarity about participants who are not part of CS but within RS. Because CS may span across different RS how about the participant who are not part of CS? Ex: One of the user in the conference acts as SRC, fetch participant info using conferene package and new RS is created during initial conference creation and hold&resume of a user within CS. Thanks Partha -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 Sent: Friday, April 08, 2011 9:36 PM To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); siprec@ietf.org Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr) Subject: RE: [siprec] Partial updates and identifiers Focusing just on participant and stream for the time being, do these need to be unique across multiple CSs or not? John=20 > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > Sent: 07 April 2011 10:51 > To: Paul Kyzivat (pkyzivat); siprec@ietf.org; Elwell, John > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe Hildebrand=20 > (jhildebr) > Subject: RE: [siprec] Partial updates and identifiers >=20 > John, >=20 > Sorry for the lengthy mail but it contains lot of analysis and=20 > reasoning for this id approach. >=20 > Adding to Paul's point, I wish to give more background and reason for=20 > these globally unique id. Initially I had the impression that the=20 > single unique id (RS dialog-id) in the recording (session level) and=20 > some relevant natural id for the rest of the element will serve the=20 > purpose. > There are usecases where this assumption fails. Even I have thought of > using "xml:id" instead of URN UUID to avoid long string but xml:id may > not end up with unique value always. Our analysis for URN UUID for=20 > each level is as follows and please provide your input in case id=20 > shall be > tweaked: >=20 > 1) Recording block: The reason for globally unique id is that multiple > SRC with same id to single SRS. >=20 > Topology: >=20 > SRC1 SRC2 > | | > | ----(RS1-ID1)-----SRS1 > | > ---(RS2-ID1)------------------SRS1 >=20 > In the above topology, it is possible for ID1 is generated by both=20 > SRC1 and SRC2 at the same time. >=20 > 2) group (CSG) block: Grouping mechanism (Hadriel session-id, Paul=20 > Jones > Session-UUID) is outside the scope of SIPREC. URN UUID abstracts the=20 > exact mechanism to SRS and provides the information only about the=20 > group of CS from SRC perspective. It possible that group may span=20 > across multiple RS and It is up to SRS to group and view as single=20 > recording. > Here, the single level id in the top will fail. The counter argument=20 > is to force the single RS having complete CSG but it*may not* be=20 > possible in SRC implementation. Here, xml:id will not serve the=20 > purpose >=20 > 3) session (CS) block: At the immediate look, session falls exactly=20 > under recording block. Use case 3 of draft-ietf-siprec-req-09=20 > illustrates where CS span across multiple RS. This requirement calls=20 > for unique id in session by which these session shall be viewed as=20 > single CS even though there is no group exists among them. IMO, in=20 > case session should not have globally unique id, then it is preferred=20 > to remove usecase 3 in the requirement. >=20 > 4) participant block: It needs some id which may be AOR but AOR is not > unique. IMO, xml:id may serve the purpose with session unique id. The=20 > trick exists for participant who are not associated with CS. We shall=20 > discuss and fine tune if required. >=20 > 5) stream block: Label attribute shall be used as unique value but RFC > 4574 does not mandate label attribute has to be unique across the=20 > dialog or CS and so, it may possible to change within RS and no=20 > normative statement to stop this implementation. IMO, xml:id may serve > the purpose with session unique id. Here as well, We shall discuss and > fine tune if required. >=20 > 6) extensiondata block: This is tracked in the separate mail thread=20 > whether unique id is required or not. Let us close this as part of=20 > that mail thread. >=20 > Including explicitly Hadriel, Peter, Joe in this mail thread as they=20 > have different view on this ID mechanism. >=20 > I had offline discussion with Hadriel in Prague after SIPREC meeting=20 > and my understanding of his major concern is that how SRS will be able > to design the database in case partial update does not have recording=20 > (top) id information. I'll put more thought processing to close=20 > Hadriel concern of how top id has to be tracked in case partial update > by which SRS implementation will be simplified in terms of aggregation > maintenance. >=20 > Thanks > Partha >=20 > -----Original Message----- > From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat (pkyzivat) > Sent: Thursday, April 07, 2011 12:33 AM > To: siprec@ietf.org > Subject: Re: [siprec] Partial updates and identifiers >=20 > John, >=20 > For the moment we have proposed that the ids be conveyed in the form=20 > of URIs that are globally unique, and specifically that they be UUID=20 > URNs. > There is no dependency on the particular form of the URI, but=20 > specifying they must be UUID URNs makes it possible to perform some=20 > internal optimizations for storage. >=20 > The UUID URN is a pretty inefficient encoding. A UUID can be expressed > in 32 bits, so we could consider retaining UUIDs but alter the=20 > encoding if its really an issue. However I am far from convinced that=20 > the size of the IDs is going to be a major issue in the overall size=20 > of messages, so I think its probably premature to worry about it. >=20 > Because the ids can be expressed in 32 bits, the SRC and SRS can store > them internally that way, thus reducing the runtime cost of=20 > maintaining the data. >=20 > The use of unique ids is a significant part of the overall approach to > formatting updates. If somebody has a different concept in mind it=20 > could be useful to have an alternative proposal for the format. If we=20 > had two worked out approaches we could compare the tradeoffs in each. >=20 > Thanks, > Paul >=20 > On 4/6/2011 10:24 AM, Elwell, John wrote: > > Much of the discussion on draft-ram-metadata-format in Prague > concerned the mechanism for performing partial updates and the use of=20 > identifiers. The draft permits partial updates by allowing individual=20 > objects (e.g., CS, participant, media stream) to be sent with updated=20 > content, without having to send again other objects that have not=20 > changed. So, for example, in a large conference, it would be possible=20 > to add or modify an individual participant object without having to=20 > send all the other participant objects again. I do not recall any=20 > opposition to this basic principle. > > > > However, to achieve this, every object requires an > identifier, and it > was asserted that these identifiers need to be globally unique for all > time. Although this might be efficient for updating an individual=20 > object, when sending many objects (e.g., at the start of a CS or when=20 > refreshing the entire metadata), this can make the metadata very=20 > bulky. > It depends, of course, on the format of the identifiers, and it was=20 > stated that there could be alternatives to UUID. Nevertheless, some=20 > people had concerns. These concerns also extended to the impact on the > database where metadata is stored, since it might not be feasible to=20 > convert to a database-friendly mechanism for linking objects together. > > > > One alternative proposal during the meeting was to have a single > unique identifier at the top level (for the RS) and use local=20 > identifiers for other objects. Thus when updating a single object, it=20 > would be necessary to include the top level identifier as well as one=20 > or more local identifiers. However, there were also concerns this=20 > might not fulfil actual or perceived future requirements. > > > > Please continue discussion on this. > > > > John (as chair) > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec >=20 From john.elwell@siemens-enterprise.com Mon Apr 11 01:41:08 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A9043A69E3 for ; Mon, 11 Apr 2011 01:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.724 X-Spam-Level: X-Spam-Status: No, score=-103.724 tagged_above=-999 required=5 tests=[AWL=1.075, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OR06p8wxybGp for ; Mon, 11 Apr 2011 01:40:58 -0700 (PDT) Received: from mail182.messagelabs.com (mail182.messagelabs.com [85.158.139.83]) by core3.amsl.com (Postfix) with SMTP id E6D4D3A69D2 for ; Mon, 11 Apr 2011 01:40:54 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-2.tower-182.messagelabs.com!1302511254!3815426!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 28778 invoked from network); 11 Apr 2011 08:40:54 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-2.tower-182.messagelabs.com with SMTP; 11 Apr 2011 08:40:54 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 41D4E1EB83AA; Mon, 11 Apr 2011 10:40:54 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 11 Apr 2011 10:40:54 +0200 From: "Elwell, John" To: "Parthasarathi R (partr)" , "Paul Kyzivat (pkyzivat)" , "siprec@ietf.org" Date: Mon, 11 Apr 2011 10:40:53 +0200 Thread-Topic: [siprec] Partial updates and identifiers Thread-Index: Acv0jVXI4ji2YTo+SquJ6T6YR3i+lQAdOkDgAEETmvAAg54qsAADKDEg Message-ID: References: <4D9CB8E1.7030402@cisco.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: "Peter Saint-Andre \(psaintan\)" , "Joe Hildebrand \(jhildebr\)" , Hadriel Kaplan Subject: Re: [siprec] Partial updates and identifiers X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 11 Apr 2011 08:41:08 -0000 =20 > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com]=20 > Sent: 11 April 2011 08:35 > To: Elwell, John; Paul Kyzivat (pkyzivat); siprec@ietf.org > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe=20 > Hildebrand (jhildebr) > Subject: RE: [siprec] Partial updates and identifiers >=20 > John, >=20 > As I mentioned below, stream block will be unique within CS, (not > required to be unique across multiple CS) and so, xml:id or enhancing > the normative statement of RFC 4574 label attribute to be=20 > unique within > CS will serve the purpose. I'm fine with any of the above=20 > mentioned id. > Please note that RFC 4574 "label" attribute is the nature data for RS > dialog. >=20 > In case participant within CS, xml:id will serve the purpose=20 > but we need > to get more clarity about participants who are not part of CS=20 > but within > RS.=20 [JRE] If I understand the figure in section 3 of metadata-04 correctly, a P= articipant can have a relationship with a CS, but no direct relationship wi= th an RS. So a participant that does not have a relationship with a CS is l= eft completely unattached, unless it has a relationship with a Media Stream= (which always has a relationship with a CS). So to summarize: - a Participant can have a direct relationship with a CS; or - a Participant can have an indirect relationship with a CS (via a Media St= ream); - a Participant can have no relationship with a CS, and therefore no relati= onship with an RS. Do we really need this last case? > Because CS may span across different RS how about the participant > who are not part of CS? [JRE] I don't understand the words "Because CS may span across different RS= ", because in the rest of the sentence you are talking about a Participant = that is not part of a CS. > Ex: One of the user in the conference acts as > SRC, fetch participant info using conferene package and new RS is > created during initial conference creation and hold&resume of a user > within CS. [JRE] I am not sure what you are trying to say here. I would consider a use= r whose identity is obtained via a conference event package as being part o= f the CS. That user is sending/receiving Media Streams that are part of a C= S, or if it isn't sending/receiving Media Streams, what is the relevance of= that Participant? Why would we create a new RS for such a participant?=20 John (as individual) >=20 > Thanks > Partha >=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > Sent: Friday, April 08, 2011 9:36 PM > To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); siprec@ietf.org > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe Hildebrand > (jhildebr) > Subject: RE: [siprec] Partial updates and identifiers >=20 > Focusing just on participant and stream for the time being, do these > need to be unique across multiple CSs or not? >=20 > John=20 >=20 > > -----Original Message----- > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > Sent: 07 April 2011 10:51 > > To: Paul Kyzivat (pkyzivat); siprec@ietf.org; Elwell, John > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe Hildebrand=20 > > (jhildebr) > > Subject: RE: [siprec] Partial updates and identifiers > >=20 > > John, > >=20 > > Sorry for the lengthy mail but it contains lot of analysis and=20 > > reasoning for this id approach. > >=20 > > Adding to Paul's point, I wish to give more background and=20 > reason for=20 > > these globally unique id. Initially I had the impression that the=20 > > single unique id (RS dialog-id) in the recording (session=20 > level) and=20 > > some relevant natural id for the rest of the element will serve the=20 > > purpose. > > There are usecases where this assumption fails. Even I have=20 > thought of >=20 > > using "xml:id" instead of URN UUID to avoid long string but=20 > xml:id may >=20 > > not end up with unique value always. Our analysis for URN UUID for=20 > > each level is as follows and please provide your input in case id=20 > > shall be > > tweaked: > >=20 > > 1) Recording block: The reason for globally unique id is=20 > that multiple >=20 > > SRC with same id to single SRS. > >=20 > > Topology: > >=20 > > SRC1 SRC2 > > | | > > | ----(RS1-ID1)-----SRS1 > > | > > ---(RS2-ID1)------------------SRS1 > >=20 > > In the above topology, it is possible for ID1 is generated by both=20 > > SRC1 and SRC2 at the same time. > >=20 > > 2) group (CSG) block: Grouping mechanism (Hadriel session-id, Paul=20 > > Jones > > Session-UUID) is outside the scope of SIPREC. URN UUID=20 > abstracts the=20 > > exact mechanism to SRS and provides the information only about the=20 > > group of CS from SRC perspective. It possible that group may span=20 > > across multiple RS and It is up to SRS to group and view as single=20 > > recording. > > Here, the single level id in the top will fail. The counter=20 > argument=20 > > is to force the single RS having complete CSG but it*may not* be=20 > > possible in SRC implementation. Here, xml:id will not serve the=20 > > purpose > >=20 > > 3) session (CS) block: At the immediate look, session falls exactly=20 > > under recording block. Use case 3 of draft-ietf-siprec-req-09=20 > > illustrates where CS span across multiple RS. This=20 > requirement calls=20 > > for unique id in session by which these session shall be viewed as=20 > > single CS even though there is no group exists among them. IMO, in=20 > > case session should not have globally unique id, then it is=20 > preferred=20 > > to remove usecase 3 in the requirement. > >=20 > > 4) participant block: It needs some id which may be AOR but=20 > AOR is not >=20 > > unique. IMO, xml:id may serve the purpose with session=20 > unique id. The=20 > > trick exists for participant who are not associated with=20 > CS. We shall=20 > > discuss and fine tune if required. > >=20 > > 5) stream block: Label attribute shall be used as unique=20 > value but RFC > > 4574 does not mandate label attribute has to be unique across the=20 > > dialog or CS and so, it may possible to change within RS and no=20 > > normative statement to stop this implementation. IMO,=20 > xml:id may serve >=20 > > the purpose with session unique id. Here as well, We shall=20 > discuss and >=20 > > fine tune if required. > >=20 > > 6) extensiondata block: This is tracked in the separate mail thread=20 > > whether unique id is required or not. Let us close this as part of=20 > > that mail thread. > >=20 > > Including explicitly Hadriel, Peter, Joe in this mail=20 > thread as they=20 > > have different view on this ID mechanism. > >=20 > > I had offline discussion with Hadriel in Prague after=20 > SIPREC meeting=20 > > and my understanding of his major concern is that how SRS=20 > will be able >=20 > > to design the database in case partial update does not have=20 > recording=20 > > (top) id information. I'll put more thought processing to close=20 > > Hadriel concern of how top id has to be tracked in case=20 > partial update >=20 > > by which SRS implementation will be simplified in terms of=20 > aggregation >=20 > > maintenance. > >=20 > > Thanks > > Partha > >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat=20 > (pkyzivat) > > Sent: Thursday, April 07, 2011 12:33 AM > > To: siprec@ietf.org > > Subject: Re: [siprec] Partial updates and identifiers > >=20 > > John, > >=20 > > For the moment we have proposed that the ids be conveyed in=20 > the form=20 > > of URIs that are globally unique, and specifically that=20 > they be UUID=20 > > URNs. > > There is no dependency on the particular form of the URI, but=20 > > specifying they must be UUID URNs makes it possible to perform some=20 > > internal optimizations for storage. > >=20 > > The UUID URN is a pretty inefficient encoding. A UUID can=20 > be expressed >=20 > > in 32 bits, so we could consider retaining UUIDs but alter the=20 > > encoding if its really an issue. However I am far from=20 > convinced that=20 > > the size of the IDs is going to be a major issue in the=20 > overall size=20 > > of messages, so I think its probably premature to worry about it. > >=20 > > Because the ids can be expressed in 32 bits, the SRC and=20 > SRS can store >=20 > > them internally that way, thus reducing the runtime cost of=20 > > maintaining the data. > >=20 > > The use of unique ids is a significant part of the overall=20 > approach to >=20 > > formatting updates. If somebody has a different concept in mind it=20 > > could be useful to have an alternative proposal for the=20 > format. If we=20 > > had two worked out approaches we could compare the=20 > tradeoffs in each. > >=20 > > Thanks, > > Paul > >=20 > > On 4/6/2011 10:24 AM, Elwell, John wrote: > > > Much of the discussion on draft-ram-metadata-format in Prague > > concerned the mechanism for performing partial updates and=20 > the use of=20 > > identifiers. The draft permits partial updates by allowing=20 > individual=20 > > objects (e.g., CS, participant, media stream) to be sent=20 > with updated=20 > > content, without having to send again other objects that have not=20 > > changed. So, for example, in a large conference, it would=20 > be possible=20 > > to add or modify an individual participant object without having to=20 > > send all the other participant objects again. I do not recall any=20 > > opposition to this basic principle. > > > > > > However, to achieve this, every object requires an > > identifier, and it > > was asserted that these identifiers need to be globally=20 > unique for all >=20 > > time. Although this might be efficient for updating an individual=20 > > object, when sending many objects (e.g., at the start of a=20 > CS or when=20 > > refreshing the entire metadata), this can make the metadata very=20 > > bulky. > > It depends, of course, on the format of the identifiers, and it was=20 > > stated that there could be alternatives to UUID. Nevertheless, some=20 > > people had concerns. These concerns also extended to the=20 > impact on the >=20 > > database where metadata is stored, since it might not be=20 > feasible to=20 > > convert to a database-friendly mechanism for linking=20 > objects together. > > > > > > One alternative proposal during the meeting was to have a single > > unique identifier at the top level (for the RS) and use local=20 > > identifiers for other objects. Thus when updating a single=20 > object, it=20 > > would be necessary to include the top level identifier as=20 > well as one=20 > > or more local identifiers. However, there were also concerns this=20 > > might not fulfil actual or perceived future requirements. > > > > > > Please continue discussion on this. > > > > > > John (as chair) > > > _______________________________________________ > > > siprec mailing list > > > siprec@ietf.org > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > >=20 > = From partr@cisco.com Mon Apr 11 02:29:38 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D5CD3A69E9 for ; Mon, 11 Apr 2011 02:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.183 X-Spam-Level: X-Spam-Status: No, score=-9.183 tagged_above=-999 required=5 tests=[AWL=-0.384, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CqFifPv2F9VX for ; Mon, 11 Apr 2011 02:29:36 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 0C2F23A69E3 for ; Mon, 11 Apr 2011 02:29:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=13519; q=dns/txt; s=iport; t=1302514175; x=1303723775; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=Zgce3yDlv7bTSQ/zt1vyWR861HVMuCvha1GXtG+7KYw=; b=brwxy1vN9DpKe2ylS1vw4eUCDGtusOgPshXaBrusajtNKkwMZhnMa/hg sbjMMwMxbeaH46Sl3suUGsFyB9zG4sV+nHtSKtHVdFVHb66iFg4blkXLl s5SoNkcAGFnzGIIC/HfA37QYS8mYfWmFS5A1oyAmAVrirxg8oyWEP1gCE 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAANXIok2Q/khMgWdsb2JhbACYQY1YFAEBFiYliHqdEJs1gn+CbwSFWYtw X-IronPort-AV: E=Sophos;i="4.63,338,1299456000"; d="scan'208";a="83034975" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 11 Apr 2011 09:29:34 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3B9TVXH011242; Mon, 11 Apr 2011 09:29:34 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 11 Apr 2011 14:59:29 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 11 Apr 2011 14:59:29 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Partial updates and identifiers Thread-Index: Acv0jVXI4ji2YTo+SquJ6T6YR3i+lQAdOkDgAEETmvAAg54qsAADKDEgAADSn+A= References: <4D9CB8E1.7030402@cisco.com> From: "Parthasarathi R (partr)" To: "Elwell, John" , "Paul Kyzivat (pkyzivat)" , X-OriginalArrivalTime: 11 Apr 2011 09:29:29.0370 (UTC) FILETIME=[F50BD7A0:01CBF82A] Cc: "Peter Saint-Andre \(psaintan\)" , "Joe Hildebrand \(jhildebr\)" , Hadriel Kaplan Subject: Re: [siprec] Partial updates and identifiers X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 11 Apr 2011 09:29:39 -0000 John, Please read inline. Thanks Partha=20 -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 Sent: Monday, April 11, 2011 2:11 PM To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); siprec@ietf.org Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr) Subject: RE: [siprec] Partial updates and identifiers =20 > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > Sent: 11 April 2011 08:35 > To: Elwell, John; Paul Kyzivat (pkyzivat); siprec@ietf.org > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe Hildebrand=20 > (jhildebr) > Subject: RE: [siprec] Partial updates and identifiers >=20 > John, >=20 > As I mentioned below, stream block will be unique within CS, (not=20 > required to be unique across multiple CS) and so, xml:id or enhancing=20 > the normative statement of RFC 4574 label attribute to be unique=20 > within CS will serve the purpose. I'm fine with any of the above=20 > mentioned id. > Please note that RFC 4574 "label" attribute is the nature data for RS=20 > dialog. >=20 > In case participant within CS, xml:id will serve the purpose but we=20 > need to get more clarity about participants who are not part of CS but > within RS. [JRE] If I understand the figure in section 3 of metadata-04 correctly, a Participant can have a relationship with a CS, but no direct relationship with an RS. Sorry, I mixed up my statement with the latest update of making CSG optional. As per Sec 3 of metadata-04, participant has direct relationship with CSG in case CS is left completely unattached. In case CSG is optional, then participant will have direct relationship with RS in case there is no relationship between CS and participant. =20 So a participant that does not have a relationship with a CS is left completely unattached, unless it has a relationship with a Media Stream (which always has a relationship with a CS). So to summarize: - a Participant can have a direct relationship with a CS; or - a Participant can have an indirect relationship with a CS (via a Media Stream); agreed - a Participant can have no relationship with a CS, and therefore no relationship with an RS. Do we really need this last case? I'm happy if the last case is not required because it simplify the solution and there is no need of unique id for participant. But SRS implementers may prefer to have relationship with participant and RS. I wish more opinion before taking decision whether to remove the last case > Because CS may span across different RS how about the participant who=20 > are not part of CS? [JRE] I don't understand the words "Because CS may span across different RS", because in the rest of the sentence you are talking about a Participant that is not part of a CS. > Ex: One of the user in the conference acts as SRC, fetch participant=20 > info using conferene package and new RS is created during initial=20 > conference creation and hold&resume of a user within CS. [JRE] I am not sure what you are trying to say here. I would consider a user whose identity is obtained via a conference event package as being part of the CS. I'm trying to give the example where participant is not associated with CS directly but related to CSG (/RS). This scenario was considered as a blocking in -03 version of metadata. I'm not arguing to have this scenario but it is major concern for few folks. CS is between focus and UA, UA acts as SRC, UA receives the participant info via conference event package but those participants are not related in CS directly (and only focus is related) but they contributed for the mixed stream. That user is sending/receiving Media Streams that are part of a CS, or if it isn't sending/receiving Media Streams, what is the relevance of that Participant? Mixed media stream from focus to UA belongs to the Conference event package participants. There participant are not directly involved as part of CS. =20 Why would we create a new RS for such a participant?=20 RS is not created for participant. Multiple RS shall be created the same CS during the different time frame as shown below <-------------------CS1-------------> <---RS1--> <---RS2------>=20 CS1 is between UA (SRC) and focus whereas RS1, RS2 is between UA (SRC) and SRS. Here tangling (conference event package) participant has to be grouped together in RS1, RS2 by some means through given metadata. The question whether this corner has to be solved ? John (as individual) >=20 > Thanks > Partha >=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Friday, April 08, 2011 9:36 PM > To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); siprec@ietf.org > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe Hildebrand > (jhildebr) > Subject: RE: [siprec] Partial updates and identifiers >=20 > Focusing just on participant and stream for the time being, do these=20 > need to be unique across multiple CSs or not? >=20 > John >=20 > > -----Original Message----- > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > Sent: 07 April 2011 10:51 > > To: Paul Kyzivat (pkyzivat); siprec@ietf.org; Elwell, John > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe Hildebrand > > (jhildebr) > > Subject: RE: [siprec] Partial updates and identifiers > >=20 > > John, > >=20 > > Sorry for the lengthy mail but it contains lot of analysis and=20 > > reasoning for this id approach. > >=20 > > Adding to Paul's point, I wish to give more background and > reason for > > these globally unique id. Initially I had the impression that the=20 > > single unique id (RS dialog-id) in the recording (session > level) and > > some relevant natural id for the rest of the element will serve the=20 > > purpose. > > There are usecases where this assumption fails. Even I have > thought of >=20 > > using "xml:id" instead of URN UUID to avoid long string but > xml:id may >=20 > > not end up with unique value always. Our analysis for URN UUID for=20 > > each level is as follows and please provide your input in case id=20 > > shall be > > tweaked: > >=20 > > 1) Recording block: The reason for globally unique id is > that multiple >=20 > > SRC with same id to single SRS. > >=20 > > Topology: > >=20 > > SRC1 SRC2 > > | | > > | ----(RS1-ID1)-----SRS1 > > | > > ---(RS2-ID1)------------------SRS1 > >=20 > > In the above topology, it is possible for ID1 is generated by both > > SRC1 and SRC2 at the same time. > >=20 > > 2) group (CSG) block: Grouping mechanism (Hadriel session-id, Paul=20 > > Jones > > Session-UUID) is outside the scope of SIPREC. URN UUID > abstracts the > > exact mechanism to SRS and provides the information only about the=20 > > group of CS from SRC perspective. It possible that group may span=20 > > across multiple RS and It is up to SRS to group and view as single=20 > > recording. > > Here, the single level id in the top will fail. The counter > argument > > is to force the single RS having complete CSG but it*may not* be=20 > > possible in SRC implementation. Here, xml:id will not serve the=20 > > purpose > >=20 > > 3) session (CS) block: At the immediate look, session falls exactly=20 > > under recording block. Use case 3 of draft-ietf-siprec-req-09=20 > > illustrates where CS span across multiple RS. This > requirement calls > > for unique id in session by which these session shall be viewed as=20 > > single CS even though there is no group exists among them. IMO, in=20 > > case session should not have globally unique id, then it is > preferred > > to remove usecase 3 in the requirement. > >=20 > > 4) participant block: It needs some id which may be AOR but > AOR is not >=20 > > unique. IMO, xml:id may serve the purpose with session > unique id. The > > trick exists for participant who are not associated with > CS. We shall > > discuss and fine tune if required. > >=20 > > 5) stream block: Label attribute shall be used as unique > value but RFC > > 4574 does not mandate label attribute has to be unique across the=20 > > dialog or CS and so, it may possible to change within RS and no=20 > > normative statement to stop this implementation. IMO, > xml:id may serve >=20 > > the purpose with session unique id. Here as well, We shall > discuss and >=20 > > fine tune if required. > >=20 > > 6) extensiondata block: This is tracked in the separate mail thread=20 > > whether unique id is required or not. Let us close this as part of=20 > > that mail thread. > >=20 > > Including explicitly Hadriel, Peter, Joe in this mail > thread as they > > have different view on this ID mechanism. > >=20 > > I had offline discussion with Hadriel in Prague after > SIPREC meeting > > and my understanding of his major concern is that how SRS > will be able >=20 > > to design the database in case partial update does not have > recording > > (top) id information. I'll put more thought processing to close=20 > > Hadriel concern of how top id has to be tracked in case > partial update >=20 > > by which SRS implementation will be simplified in terms of > aggregation >=20 > > maintenance. > >=20 > > Thanks > > Partha > >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > (pkyzivat) > > Sent: Thursday, April 07, 2011 12:33 AM > > To: siprec@ietf.org > > Subject: Re: [siprec] Partial updates and identifiers > >=20 > > John, > >=20 > > For the moment we have proposed that the ids be conveyed in > the form > > of URIs that are globally unique, and specifically that > they be UUID > > URNs. > > There is no dependency on the particular form of the URI, but=20 > > specifying they must be UUID URNs makes it possible to perform some=20 > > internal optimizations for storage. > >=20 > > The UUID URN is a pretty inefficient encoding. A UUID can > be expressed >=20 > > in 32 bits, so we could consider retaining UUIDs but alter the=20 > > encoding if its really an issue. However I am far from > convinced that > > the size of the IDs is going to be a major issue in the > overall size > > of messages, so I think its probably premature to worry about it. > >=20 > > Because the ids can be expressed in 32 bits, the SRC and > SRS can store >=20 > > them internally that way, thus reducing the runtime cost of=20 > > maintaining the data. > >=20 > > The use of unique ids is a significant part of the overall > approach to >=20 > > formatting updates. If somebody has a different concept in mind it=20 > > could be useful to have an alternative proposal for the > format. If we > > had two worked out approaches we could compare the > tradeoffs in each. > >=20 > > Thanks, > > Paul > >=20 > > On 4/6/2011 10:24 AM, Elwell, John wrote: > > > Much of the discussion on draft-ram-metadata-format in Prague > > concerned the mechanism for performing partial updates and > the use of > > identifiers. The draft permits partial updates by allowing > individual > > objects (e.g., CS, participant, media stream) to be sent > with updated > > content, without having to send again other objects that have not=20 > > changed. So, for example, in a large conference, it would > be possible > > to add or modify an individual participant object without having to=20 > > send all the other participant objects again. I do not recall any=20 > > opposition to this basic principle. > > > > > > However, to achieve this, every object requires an > > identifier, and it > > was asserted that these identifiers need to be globally > unique for all >=20 > > time. Although this might be efficient for updating an individual=20 > > object, when sending many objects (e.g., at the start of a > CS or when > > refreshing the entire metadata), this can make the metadata very=20 > > bulky. > > It depends, of course, on the format of the identifiers, and it was=20 > > stated that there could be alternatives to UUID. Nevertheless, some=20 > > people had concerns. These concerns also extended to the > impact on the >=20 > > database where metadata is stored, since it might not be > feasible to > > convert to a database-friendly mechanism for linking > objects together. > > > > > > One alternative proposal during the meeting was to have a single > > unique identifier at the top level (for the RS) and use local=20 > > identifiers for other objects. Thus when updating a single > object, it > > would be necessary to include the top level identifier as > well as one > > or more local identifiers. However, there were also concerns this=20 > > might not fulfil actual or perceived future requirements. > > > > > > Please continue discussion on this. > > > > > > John (as chair) > > > _______________________________________________ > > > siprec mailing list > > > siprec@ietf.org > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > >=20 >=20 From pkyzivat@cisco.com Mon Apr 11 05:21:25 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B00E228C0F6 for ; Mon, 11 Apr 2011 05:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.8 X-Spam-Level: X-Spam-Status: No, score=-108.8 tagged_above=-999 required=5 tests=[AWL=-1.691, BAYES_00=-2.599, DATE_IN_PAST_96_XX=1.69, J_CHICKENPOX_210=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlzXDglpE4gZ for ; Mon, 11 Apr 2011 05:21:24 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 3BACE3A6A0D for ; Mon, 11 Apr 2011 05:21:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=7176; q=dns/txt; s=iport; t=1302524484; x=1303734084; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=ZRGyLm1h3TUyBymr0kyhpfGMNzzmosvAOWvFLHe6aoo=; b=PQGM2fRDLMLKEHuCDTHlSn3WB+vRfmvmPSeNrcNJyj1RUSMtxzNozBPE W7BnoSOAY9lRLpr2M3wABn5SvQXhb02NFFASvI0+WprrTg1oPiDbUjcac kvc1lF1gXc/zmFzj6ZMuWtcIjL+OukrkngPWzBRDGCVn+nZaQz1E4dAni o=; X-IronPort-AV: E=Sophos;i="4.63,339,1299456000"; d="scan'208";a="427417644" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-1.cisco.com with ESMTP; 11 Apr 2011 12:21:17 +0000 Received: from [161.44.174.125] (dhcp-161-44-174-125.cisco.com [161.44.174.125]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3BCLFg7011671; Mon, 11 Apr 2011 12:21:16 GMT Message-ID: <4D9631BB.5060104@cisco.com> Date: Fri, 01 Apr 2011 16:12:43 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Scott Orton References: <4D93ADCB.2050106@stpeter.im> <4D94416E.7070102@cisco.com><4D944429.10607@stpeter.im> <4D94714B.8010102@cisco.com> <21866C7FE177A4449B9136B5B24B1B130BC01128BC@EXMBXCLUS01.citservers.local> <21866C7FE177A4449B9136B5B24B1B130BC01128FB@EXMBXCLUS01.citservers.local> In-Reply-To: <21866C7FE177A4449B9136B5B24B1B130BC01128FB@EXMBXCLUS01.citservers.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "siprec@ietf.org" Subject: Re: [siprec] draft-ram-siprec-metadata-format-01 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 11 Apr 2011 12:21:25 -0000 Scott, One general principle (IMO): metadata is *never* deleted as a consequence of the mechanisms we are defining - the database is essentially write-only. But everything will be timestamped. (If the SRS wants to delete metadata by policy it may.) For some things the interpretation of transmitting the same thing again is that there is a single value at any point in time - sending a new value affects what the value is considered to be for subsequent times. For other things, (and this needs to be discussed) it may be that values just accumulate as received, and all apply to the thing they attach to for all time. Does that sound right? Thanks, Paul On 3/31/2011 12:21 PM, Scott Orton wrote: > Inline comments. > > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > Sent: Thursday, March 31, 2011 10:42 AM > To: Scott Orton; Paul Kyzivat (pkyzivat); Peter Saint-Andre > Cc: siprec@ietf.org > Subject: RE: [siprec] draft-ram-siprec-metadata-format-01 > > Scott, > > Thanks for the feedback. > > Thanks > Partha > > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf > Of Scott Orton > Sent: Thursday, March 31, 2011 8:59 PM > To: Paul Kyzivat (pkyzivat); Peter Saint-Andre > Cc: siprec@ietf.org > Subject: Re: [siprec] draft-ram-siprec-metadata-format-01 > > Here is some feedback on draft-ram-siprec-metadata-format-01. > > In the xml schema, the group is not listed as an element in the sequence > for the recording-metadata, which conflicts with the example in 5.1. > > Agreed. I'll update in the next revision > > In addition, I found it confusing that the extension data is included in > the participant type but not included in any of the other defined > elements in the recording-metadata. I think it might be good idea to > include the extension data as last element in the sequences for the > group, session, etc. As that would eliminate the need for the parent > attribute in the extension data assuming it stays close to its current > format. > > It purely depend on whether extension-data has to be partially > passed across separately or not. Currently mechanism allows to pass > extension data partially within RS whereas in case it is an element > within any of the metadata block element like participant, stream then > it has to be passed across with any change in that particular metadata > block element. > > > I see the advantages of it being separate for the partial update. I would just like it to be consistent. Either in each element or in none of the elements. I think the key to deciding where to include the extension data is how a partial update should treat the data. If for example in the initial metadata you send to the SRS there is extensiondata associated with the participant. Then in an UPDATE the partial metadata for the participant update the stop-time, but does not include the extensiondata. How is the SRS expected to handle the lack of extensiondata? Should it treat it as the extensiondata is no longer relevant and delete it or should it assume it is not changed. If it should treat it as unchanged then how do you delete the extension data if it is no longer relevant. Since the definition of the extension data requires at least one string there is no way to remove it. All this leads me to believe that the extension data should be part of each element and the re should be no generic extensiondata element in the recording-metadata. > > In case everyone feels that there is no need to pass extensiondata > explicitly, it realy simply the solution as there is no need another > open item like parent id within extensiondata > > > Regards, > Scott > > > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf > Of Paul Kyzivat > Sent: Thursday, March 31, 2011 7:19 AM > To: Peter Saint-Andre > Cc: siprec@ietf.org > Subject: Re: [siprec] draft-ram-siprec-metadata-format-01 > > > > On 3/31/2011 5:06 AM, Peter Saint-Andre wrote: >> I am booked through 11 PM tonight. >> >> Tomorrow I have the following windows of time: >> >> 07:00-07:30 >> 15:15-16:00 >> >> Naturally that time might get filled if issues come up in some of my >> working groups. :) > > But you also have 11-12pm tonite? :-) > (That is much better for me than the others.) > > Maybe its just too late in the week to hope for this. > We can take it to the list. > > Thanks, > Paul > >> On 3/31/11 10:55 AM, Paul Kyzivat wrote: >>> Peter/Joe, >>> >>> Do either of you have any time in the remainder of the week when some > >>> of us could sit and try to sort out the right way to do the extension > data? >>> I doubt it would take very long. >>> >>> Thanks, >>> Paul >>> >>> On 3/30/2011 6:25 PM, Peter Saint-Andre wrote: >>>> Here is some quick feedback on draft-ram-siprec-metadata-format-01. >>>> I hope to review it more fully soon. >>>> >>>> 1. I would change application/recording to application/recording+xml > >>>> in accordance with RFC 3023 (many specs illustrate the use of XML >>>> media types -- see for example RFC 4287). >>>> >>>> 2. The large number of elements is a bit confusing > in >>>> the examples. >>>> >>>> 3. In Section 5.1, the example has one element >>>> qualified by the 'urn:ietf:params:xml:ns:siprec' namespace (no other >>>> namespace is defined) and then multiple elements >>>> qualified by other namespaces ('http://example.com/groupapp', >>>> 'http://example.com/sessionapp', etc.). Although those other >>>> namespaces are certainly *allowed* to use "extensiondata" as an >>>> element name (that's the beauty of namespaces), it is confusing in > this document. >>>> Perhaps you even meant to have elements qualified > by >>>> the 'urn:ietf:params:xml:ns:siprec' and then child elements >>>> qualified by other namespaces (in accordance with the schema). >>>> However, that is not clear in the spec. >>>> >>>> 4. There is no built-in datatype for xs:urnuuid, xs:streamMode, >>>> xs:requester, and so on. See W3C XML Schema Part 2: >>>> >>>> http://www.w3.org/TR/xmlschema-2/#built-in-datatypes >>>> >>>> 5. The data in the elements with xml:lang="it" really > should be >>>> Giulietta Capuleti and Romeo Montecchi. ;-) >>>> >>>> Peter >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> siprec mailing 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@cisco.com Mon Apr 11 06:03:23 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E4BF28C11B for ; Mon, 11 Apr 2011 06:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.523 X-Spam-Level: X-Spam-Status: No, score=-110.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eATibUZLDhc7 for ; Mon, 11 Apr 2011 06:03:22 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id EAB4828C111 for ; Mon, 11 Apr 2011 06:03:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=6354; q=dns/txt; s=iport; t=1302527002; x=1303736602; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=E+/pGkCX5K1PluVh49CBAgt7kBR9yoy7WCedoDi7moA=; b=KObamDaSTqxIH7UXD7hGjgyfDzlvLnQuTfZQc8sM4m5tqDKZDXzI1ufK Ml5KjADQcadSrcviD9Smq4KofKTIlcKvEcLbkypicI9RRXaHejETvUO8h AG/xNzELrS6GPNnTFjLBxxRygaZ0q8wg4F1CulCB+f6RiKYcE0pxElkfg 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACf7ok2tJV2b/2dsb2JhbACmGXeIep0vm2CFbgSNWINq X-IronPort-AV: E=Sophos;i="4.63,339,1299456000"; d="scan'208";a="678947875" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by sj-iport-6.cisco.com with ESMTP; 11 Apr 2011 13:03:20 +0000 Received: from [161.44.174.125] (dhcp-161-44-174-125.cisco.com [161.44.174.125]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3BD3J43017033; Mon, 11 Apr 2011 13:03:19 GMT Message-ID: <4DA2FC17.1060100@cisco.com> Date: Mon, 11 Apr 2011 09:03:19 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Elwell, John" References: <4D9CDADD.1020403@cisco.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] start/stop times & the metamodel X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 11 Apr 2011 13:03:23 -0000 On 4/8/2011 11:53 AM, Elwell, John wrote: > Paul, > > I think much of what you say makes sense. I was concerned that we probably need to record when a participant stops or starts sending or receiving a stream, which seems to be covered by your statement: "Changes to media streams should similarly be tagged with the time they occurred in the CS signaling. Each participant relationship change (send, receive, inactive,) will be there." That doesn't seem to be in the model at present. John, I agree the current model doesn't reflect this - it was a private thought by me, provoked by the work and discussion to date. It is a bit of a change of direction, so I'm interested in what others think about it. Thanks, Paul > John (as individual) > > >> -----Original Message----- >> From: siprec-bounces@ietf.org >> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: 06 April 2011 22:28 >> To: siprec@ietf.org >> Subject: [siprec] start/stop times& the metamodel >> >> In Prague, one of the open issues was around start/stop times. The >> format draft floated the possibility of having explicit >> start/stop times >> signaled for each of the metatdata elements. But then we asked for >> feedback on which make sense. >> >> IMO explicit start/stop times make more sense for some things >> than others. >> >> One place where we potentially have explicit times to report with the >> dialogs that constitute a CS. Each such dialog presumably has a start >> and stop time observable by the SRC, which might differ, at >> least a bit, >> from the corresponding signaling on the RS. >> >> We might want to report those times. Or, since we abstract >> the CS away >> from the dialog, we might want to report the start time of the first >> dialog in the CS as the CS start time, and the stop time of the last >> dialog in the CS as the CS stop time. >> >> Similarly, we have abstracted media streams away from the >> media streams >> in the sip dialogs that make up the CS. We might want to report the >> start time of a media stream as the time (according to the CS) of the >> first participant to a new media stream, and the stop time as >> the time >> that the last participant leaves the media stream. >> >> There are several things that complicate this: >> >> - Do we consider the case of a stream that starts with recvonly >> or inactive participants, and only later gets a sender? If so, >> is the start time of the stream when the first participant arrived, >> or when the first sender arrived? >> >> - How do we get the clock times for the media streams? >> IIUC the correct ones are in the RTP/RTCP, but the reporting of >> these events is driven by the signaling, and we don't have good >> sync between those. (E.g. media could start flowing before the >> corresponding signaling, and we would like to include that if we >> can figure it out.) So, even if the clocks used for media and >> signaling are in sync, we might see media packets arrive with >> a timestamp prior to the timestamp for the signaling that >> indicates the send state of the participant. This could cause >> trouble in playback. >> >> - There isn't any guarantee that the clock used for signaling >> messages is synchronized with the clock used in RTP/RTCP. >> >> - There isn't any guarantee that there will be any RTCP at all, >> to provide correlation of the RTP to clocktime. >> >> The best I can see to deal with all of this is: >> >> - All the metadata messages should be timestamped by the SRC >> using its local clock. This is easily achieved by the Date >> header in the sip message. >> >> - Changes to a CS, including changes of participants, should >> be explicitly tagged with the time they occurred in the >> CS signaling, according to the SRC's clock. (If that is >> unavailable for some reason, then use the time the SRC >> became aware of it.) >> >> - We could provide a metadata update element to indicate end >> of a CS, but I suggest this just be shorthand for indicating >> removal of all participants from it. (While its possible to >> mark that the CS is truly ended, that simply introduces an >> error case if added metadata about it is subsequently sent.) >> The actual start/stop time would be determined by the SRS >> based on the timestamps of first and last data about it. >> >> - Changes to media streams should similarly be tagged with >> the time they occurred in the CS signaling. Each participant >> relationship change (send, receive, inactive,) will be there. >> The actual start/stop time of the media stream again would be >> derived by the SRS. >> >> - CS-Groups can simply be tagged by the timestamps of the >> updates that put CSs into them. Explicit start/stop times don't >> seem useful. If desired, the SRS can derive start/stop times >> from the start/stop times of the contained stuff. >> >> - I now think that CS-Groups should not be "contained" within >> a recording. This just seems to introduce unnecessary error >> conditions, and limitations on future enhancements. The >> lifetime of CS-Groups will probably be naturally limited by >> the ability of the SRC to remember the IDs of old ones. >> For instance, if a CS-G is created during one Recording, >> and then another CS is added to it from a different recording >> session, would we prefer to fail that, or just allow it? >> (I think allow.) >> >> - Rather, I think every update transmitted during a recording >> session can be tagged with a link to the metadata of the >> recording session it came from. This need not be explicit - the >> SRS can do it automatically. The recording session entity >> itself will also have a start/stop time which is the start/ >> stop of the RS dialog as observed by the SRS. >> >> (Note the above doesn't solve the problem of getting correct >> clock times >> for RTP media. If anyone has a suggestion for this I'm all ears.) >> >> Thanks, >> Paul >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >> From Leon.Portman@nice.com Mon Apr 11 06:24:31 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 871C628C0CE for ; Mon, 11 Apr 2011 06:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.431 X-Spam-Level: X-Spam-Status: No, score=-2.431 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hvyw+oBcQXdc for ; Mon, 11 Apr 2011 06:24:30 -0700 (PDT) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by core3.amsl.com (Postfix) with ESMTP id 86BC93A6B14 for ; Mon, 11 Apr 2011 06:24:28 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Mon, 11 Apr 2011 16:24:27 +0300 From: Leon Portman To: "siprec@ietf.org" , "Parthasarathi R (partr) (partr@cisco.com)" Date: Mon, 11 Apr 2011 16:24:25 +0300 Thread-Topic: [siprec] metadata model and persisent recording Thread-Index: Acv4S3UkNsX1IonBSQuklfkGrhYJ8g== Message-ID: <07465C1D981ABC41A344374066AE1A2C38AB6E1DC4@TLVMBX01.nice.com> Accept-Language: en-US, he-IL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, he-IL Content-Type: multipart/alternative; boundary="_000_07465C1D981ABC41A344374066AE1A2C38AB6E1DC4TLVMBX01nicec_" MIME-Version: 1.0 Subject: [siprec] metadata model and persisent recording X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 11 Apr 2011 13:24:31 -0000 --_000_07465C1D981ABC41A344374066AE1A2C38AB6E1DC4TLVMBX01nicec_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Partha Hi I think we are missing in the metadata model support for persistent recordi= ng mode, where RS INVITE may be sent from SRC to SRC with participant info= but without any communication session or group. For example where RS will = be established when somebody logins to the phone. Regards Leon --_000_07465C1D981ABC41A344374066AE1A2C38AB6E1DC4TLVMBX01nicec_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Partha Hi

 

I th= ink we are missing in the metadata model support for persistent recording m= ode, where RS INVITE may be  sent from SRC to SRC with participant inf= o but without any communication session or group. For example where RS will= be established when somebody logins to the phone.

 

Regards

 

Leon<= /o:p>

= --_000_07465C1D981ABC41A344374066AE1A2C38AB6E1DC4TLVMBX01nicec_-- From Leon.Portman@nice.com Mon Apr 11 06:36:45 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4111C28C0CE for ; Mon, 11 Apr 2011 06:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNpLEpqNl5ce for ; Mon, 11 Apr 2011 06:36:44 -0700 (PDT) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by core3.amsl.com (Postfix) with ESMTP id 54B5E3A6A18 for ; Mon, 11 Apr 2011 06:36:43 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Mon, 11 Apr 2011 16:36:43 +0300 From: Leon Portman To: Paul Kyzivat , "Elwell, John" Date: Mon, 11 Apr 2011 16:36:42 +0300 Thread-Topic: [siprec] start/stop times & the metamodel Thread-Index: Acv4SNr4f1bEOQYiQC6wqhsaOOxr7gAA9nRg Message-ID: <07465C1D981ABC41A344374066AE1A2C38AB6E1DE4@TLVMBX01.nice.com> References: <4D9CDADD.1020403@cisco.com> <4DA2FC17.1060100@cisco.com> In-Reply-To: <4DA2FC17.1060100@cisco.com> Accept-Language: en-US, he-IL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, he-IL Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] start/stop times & the metamodel X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 11 Apr 2011 13:36:45 -0000 Paul Hi I agree with proposed method of time stamping metadata elements with SRC cl= ock (it is like a wall clock from the requirement document). About RTP time synchronization to metadata events, we either should have so= me low latency event from SRC to SRS with SRC time that will allow SRS to m= aintain time difference between its clock and SRC clock and then apply it a= lso to receive time of RTP packet (assuming no buffering) Leon -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Paul Kyzivat Sent: Monday, April 11, 2011 4:03 PM To: Elwell, John Cc: siprec@ietf.org Subject: Re: [siprec] start/stop times & the metamodel On 4/8/2011 11:53 AM, Elwell, John wrote: > Paul, > > I think much of what you say makes sense. I was concerned that we probabl= y need to record when a participant stops or starts sending or receiving a = stream, which seems to be covered by your statement: "Changes to media stre= ams should similarly be tagged with the time they occurred in the CS signal= ing. Each participant relationship change (send, receive, inactive,) will b= e there." That doesn't seem to be in the model at present. John, I agree the current model doesn't reflect this - it was a private thought b= y me, provoked by the work and discussion to date. It is a bit of a change = of direction, so I'm interested in what others think about it. Thanks, Paul > John (as individual) > > >> -----Original Message----- >> From: siprec-bounces@ietf.org >> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: 06 April 2011 22:28 >> To: siprec@ietf.org >> Subject: [siprec] start/stop times& the metamodel >> >> In Prague, one of the open issues was around start/stop times. The=20 >> format draft floated the possibility of having explicit start/stop=20 >> times signaled for each of the metatdata elements. But then we asked=20 >> for feedback on which make sense. >> >> IMO explicit start/stop times make more sense for some things than=20 >> others. >> >> One place where we potentially have explicit times to report with the=20 >> dialogs that constitute a CS. Each such dialog presumably has a start=20 >> and stop time observable by the SRC, which might differ, at least a=20 >> bit, from the corresponding signaling on the RS. >> >> We might want to report those times. Or, since we abstract the CS=20 >> away from the dialog, we might want to report the start time of the=20 >> first dialog in the CS as the CS start time, and the stop time of the=20 >> last dialog in the CS as the CS stop time. >> >> Similarly, we have abstracted media streams away from the media=20 >> streams in the sip dialogs that make up the CS. We might want to=20 >> report the start time of a media stream as the time (according to the=20 >> CS) of the first participant to a new media stream, and the stop time=20 >> as the time that the last participant leaves the media stream. >> >> There are several things that complicate this: >> >> - Do we consider the case of a stream that starts with recvonly >> or inactive participants, and only later gets a sender? If so, >> is the start time of the stream when the first participant arrived, >> or when the first sender arrived? >> >> - How do we get the clock times for the media streams? >> IIUC the correct ones are in the RTP/RTCP, but the reporting of >> these events is driven by the signaling, and we don't have good >> sync between those. (E.g. media could start flowing before the >> corresponding signaling, and we would like to include that if we >> can figure it out.) So, even if the clocks used for media and >> signaling are in sync, we might see media packets arrive with >> a timestamp prior to the timestamp for the signaling that >> indicates the send state of the participant. This could cause >> trouble in playback. >> >> - There isn't any guarantee that the clock used for signaling >> messages is synchronized with the clock used in RTP/RTCP. >> >> - There isn't any guarantee that there will be any RTCP at all, >> to provide correlation of the RTP to clocktime. >> >> The best I can see to deal with all of this is: >> >> - All the metadata messages should be timestamped by the SRC >> using its local clock. This is easily achieved by the Date >> header in the sip message. >> >> - Changes to a CS, including changes of participants, should >> be explicitly tagged with the time they occurred in the >> CS signaling, according to the SRC's clock. (If that is >> unavailable for some reason, then use the time the SRC >> became aware of it.) >> >> - We could provide a metadata update element to indicate end >> of a CS, but I suggest this just be shorthand for indicating >> removal of all participants from it. (While its possible to >> mark that the CS is truly ended, that simply introduces an >> error case if added metadata about it is subsequently sent.) >> The actual start/stop time would be determined by the SRS >> based on the timestamps of first and last data about it. >> >> - Changes to media streams should similarly be tagged with >> the time they occurred in the CS signaling. Each participant >> relationship change (send, receive, inactive,) will be there. >> The actual start/stop time of the media stream again would be >> derived by the SRS. >> >> - CS-Groups can simply be tagged by the timestamps of the >> updates that put CSs into them. Explicit start/stop times don't >> seem useful. If desired, the SRS can derive start/stop times >> from the start/stop times of the contained stuff. >> >> - I now think that CS-Groups should not be "contained" within >> a recording. This just seems to introduce unnecessary error >> conditions, and limitations on future enhancements. The >> lifetime of CS-Groups will probably be naturally limited by >> the ability of the SRC to remember the IDs of old ones. >> For instance, if a CS-G is created during one Recording, >> and then another CS is added to it from a different recording >> session, would we prefer to fail that, or just allow it? >> (I think allow.) >> >> - Rather, I think every update transmitted during a recording >> session can be tagged with a link to the metadata of the >> recording session it came from. This need not be explicit - the >> SRS can do it automatically. The recording session entity >> itself will also have a start/stop time which is the start/ >> stop of the RS dialog as observed by the SRS. >> >> (Note the above doesn't solve the problem of getting correct clock=20 >> times for RTP media. If anyone has a suggestion for this I'm all=20 >> ears.) >> >> Thanks, >> Paul >> _______________________________________________ >> siprec mailing 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@cisco.com Mon Apr 11 06:39:28 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5AA13A6B18 for ; Mon, 11 Apr 2011 06:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.524 X-Spam-Level: X-Spam-Status: No, score=-110.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JUj9ih9dKjnF for ; Mon, 11 Apr 2011 06:39:27 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 3D5E53A6B17 for ; Mon, 11 Apr 2011 06:39:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=6412; q=dns/txt; s=iport; t=1302529167; x=1303738767; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=cXLlO2FpoH+q1+gmoj3lhc9FbeSwQUjVWSPExJ6zBxg=; b=Q52LfUuN8F+Miiy6dp/dW/dj+aWq68Ts7F+MFckQxrZJ55Pgr5pdPoUu pT2Z7R/gVmWhaM5gZb78pxbNmBEXbllv0CjRzs2clTBC8TMRwLn4Pw/RH OueoXTWQ14IXgL8OQdJzr7d3vfNPTyEtgihoXPKv9gbmfZAVxirtbjxhb 8=; X-IronPort-AV: E=Sophos;i="4.63,339,1299456000"; d="scan'208";a="293679012" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 11 Apr 2011 13:39:27 +0000 Received: from [161.44.174.125] (dhcp-161-44-174-125.cisco.com [161.44.174.125]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3BDdQVD013757; Mon, 11 Apr 2011 13:39:26 GMT Message-ID: <4DA3048E.5000103@cisco.com> Date: Mon, 11 Apr 2011 09:39:26 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Henry Lum References: <4D9CBB90.4080804@cisco.com> <059AF07365DC474393A19A3AF187DF7406E677EF@NAHALD.us.int.genesyslab.com> In-Reply-To: <059AF07365DC474393A19A3AF187DF7406E677EF@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] Recording awareness indication X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 11 Apr 2011 13:39:28 -0000 On 4/8/2011 10:46 AM, Henry Lum wrote: > Currently in the draft we propose to use an SDP attribute to declare the > awareness. I saw comments that this should be changed to a feature tag > instead. I am okay either way; are there arguments against using a > feature tag? IIUC the main argument has been to use SDP attributes to indicate that recording is being done. And there it *is* important for it to be in SDP so it can be indicated on a per-media basis. For the awareness indicator its not so clear cut. Certainly we could define awareness so that it applies to all media, and then it *could* be in the SIP rather than the SDP. It then comes down to taste - for consistency it might be preferable to indicate it in SDP. I don't have a strong preference one way or the other. Thanks, Paul > Regards, > Henry > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Charles Eckel (eckelcu) >> Sent: Thursday, April 07, 2011 3:45 PM >> To: Paul Kyzivat (pkyzivat); siprec@ietf.org >> Subject: Re: [siprec] Recording awareness indication >> >> I agree with Paul. I would hate to force the addition of an audible >> beep >> or a red dot to all participants when a less intrusive mechanism is >> supported. >> >> Cheers, >> Charles >> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Paul Kyzivat (pkyzivat) >>> Sent: Wednesday, April 06, 2011 12:14 PM >>> To: siprec@ietf.org >>> Subject: Re: [siprec] Recording awareness indication >>> >>> I liked this concept of an overt "opt-out" of the in-band > indication. >>> ISTM that if the UA has a "better" way of doing the indication it > may >>> not want the default mechanism. (E.g. The UA may want to apply its >> own >>> in-band indication. But that won't work well if a different one has >>> already been applied.) >>> >>> If we can agree on the *concept* of opt-out, then we can determine >> the >>> exact form as a subsequent step. >>> >>> I suppose some SRCs may feel they are obliged to do their own >> indication >>> even if a participant desires to opt-out, and we ought to allow that >>> too. In that case there should probably be some indication that the >>> opt-out has been ignored, so that the UA can behave accordingly. >>> >>> Thanks, >>> Paul >>> >>> On 4/6/2011 11:08 AM, Elwell, John wrote: >>>> My own thoughts on this are that the SIP/SDP indication that >> recording is in progress, even if sent >>> to a UA known to be recording-aware, should not be used as a >> substitute for other non-SIP/SDP means of >>> notification that might otherwise be needed (e.g., an in-band audio >> announcement). I think recording >>> indicators should be used to complement other means. For example, an >> in-band audio announcement would >>> be able to reach all users (although might be problematic for >> hearing-impaired users or for users >>> speaking a different language). Despite such limitations, an in-band >> announcement is often sufficient >>> to satisfy legal requirements. On the other hand, a SIP/SDP >> indication >> that recording is in progress >>> could be rendered in different ways and in different languages at > the >> user interface of a recording- >>> aware UA. >>>> >>>> For this reason, I don't see a need for the recording-aware >> indication in SIP/SDP. Recording >>> indications can be sent without knowing whether they will be >> understood by the receiving UA - if they >>> are understood the user might get an enhanced indication - if not >> they >> will be discarded and the user >>> will get only the basic (non-SIP/SDP) indication. >>>> >>>> John (as individual) >>>> >>>> >>>>> -----Original Message----- >>>>> From: siprec-bounces@ietf.org >>>>> [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John >>>>> Sent: 06 April 2011 15:55 >>>>> To: siprec@ietf.org >>>>> Subject: [siprec] Recording awareness indication >>>>> >>>>> There was an inconclusive discussion in Prague on the >>>>> recording awareness signalling indication in >>>>> draft-portman-siprec-protocol (slide 6 / section 6.1 of >>>>> draft). If I understand correctly, it indicates that a UA >>>>> involved in the CS supports the SIPREC extensions relevant to >>>>> the CS. In particular, it indicates that the UA would be able >>>>> to understand SIP/SDP recording indications (slide 7 / >>>>> section 6.2 of draft). It seems the recording awareness >>>>> indication means that the SRC can rely on the recording >>>>> indications in SIP/SDP to advise the user that recording is >>>>> in progress, thereby avoiding the need for the SRC to provide >>>>> suitable indications through non-SIP means (e.g., in-band >>>>> audio announcements). >>>>> >>>>> Please continue this discussion. >>>>> >>>>> John (as chair) >>>>> _______________________________________________ >>>>> siprec mailing list >>>>> siprec@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>> >>>> _______________________________________________ >>>> siprec mailing list >>>> siprec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/siprec >>>> >>> _______________________________________________ >>> siprec mailing list >>> siprec@ietf.org >>> https://www.ietf.org/mailman/listinfo/siprec >> _______________________________________________ >> 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 partr@cisco.com Mon Apr 11 06:39:37 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D98F28C103 for ; Mon, 11 Apr 2011 06:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.077 X-Spam-Level: X-Spam-Status: No, score=-10.077 tagged_above=-999 required=5 tests=[AWL=0.521, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vCPhR5PSnA1n for ; Mon, 11 Apr 2011 06:39:36 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id C5C0E28C101 for ; Mon, 11 Apr 2011 06:39:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=6402; q=dns/txt; s=iport; t=1302529176; x=1303738776; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=vmeNC5jL5aAX+5X2Yr8BR2zJ3bsmW98S5ySSMjtP8AI=; b=MTjXO1/qdx/+WjfbiwvjjI4r4HIGOvmBkJXEE8AgVFFHUGePY+2vWtFf 08tcFlOtoRxoumhgkpifa0pdxtxVeRTecuBRmEZeR8osJRAx0MqSLmAx0 Ay69uocQ05avyvRdktJSdu7ynb5FfgkFgm8e7S0wDVtHKpifEz48ByzLi 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0BACUEo02Q/khNgWdsb2JhbACCYJVgjVkUAQEWJiWmSptqhW4EhVmLcA X-IronPort-AV: E=Sophos;i="4.63,339,1299456000"; d="scan'208,217";a="25255013" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 11 Apr 2011 13:39:35 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3BDdYvW000337; Mon, 11 Apr 2011 13:39:35 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 11 Apr 2011 19:09:33 +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_01CBF84D.E443E848" Date: Mon, 11 Apr 2011 19:09:33 +0530 Message-ID: In-Reply-To: <07465C1D981ABC41A344374066AE1A2C38AB6E1DC4@TLVMBX01.nice.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] metadata model and persisent recording Thread-Index: Acv4S3UkNsX1IonBSQuklfkGrhYJ8gAALnCg References: <07465C1D981ABC41A344374066AE1A2C38AB6E1DC4@TLVMBX01.nice.com> From: "Parthasarathi R (partr)" To: "Leon Portman" , X-OriginalArrivalTime: 11 Apr 2011 13:39:33.0839 (UTC) FILETIME=[E4681DF0:01CBF84D] Subject: Re: [siprec] metadata model and persisent recording X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 11 Apr 2011 13:39:37 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBF84D.E443E848 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The current model (-04) insists on CSG has directly relationship with participant in case CS is not associated with participant. Moving forward, CSG will be optional metadata block whereas RS has direct relationship with participant in case CS is not associated with participant. =20 Good timing from the discussion perspective as the same issue which I'm explaining with conference recording by user usecase in the another mail thread "Partial updates and identifiers" wherein RS is related directly with participant without CS & CSG.=20 =20 I wish that we will track this issue as part of "Partial updates and identifiers" mail thread. =20 Thanks Partha ________________________________ From: Leon Portman [mailto:Leon.Portman@nice.com]=20 Sent: Monday, April 11, 2011 6:54 PM To: siprec@ietf.org; Parthasarathi R (partr) Subject: [siprec] metadata model and persisent recording Partha Hi =20 I think we are missing in the metadata model support for persistent recording mode, where RS INVITE may be sent from SRC to SRC with participant info but without any communication session or group. For example where RS will be established when somebody logins to the phone. =20 Regards =20 Leon ------_=_NextPart_001_01CBF84D.E443E848 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
The current model (-04) insists on CSG has = directly=20 relationship with participant in case CS is not associated with = participant.=20 Moving forward, CSG will be optional metadata block whereas RS has = direct=20 relationship with participant in case CS is not associated with=20 participant.
 
Good timing from the discussion perspective = as the=20 same issue which I'm explaining with conference recording by=20 user usecase in the another mail thread "Partial updates and = identifiers"=20 wherein RS is related directly with participant without CS & = CSG.=20
 
I wish that we will track this issue as part = of "Partial=20 updates and identifiers" mail thread.
 
Thanks
Partha
From: Leon Portman=20 [mailto:Leon.Portman@nice.com]
Sent: Monday, April 11, 2011 = 6:54=20 PM
To: siprec@ietf.org; Parthasarathi R = (partr)
Subject:=20 [siprec] metadata model and persisent recording

Partha Hi

 

I think we are missing in the metadata model = support for=20 persistent recording mode, where RS INVITE may be  sent from SRC to = SRC=20 with participant info but without any communication session or group. = For=20 example where RS will be established when somebody logins to the=20 phone.

 

Regards

 

Leon

------_=_NextPart_001_01CBF84D.E443E848-- From Leon.Portman@nice.com Mon Apr 11 06:45:33 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B403A3A6B1A for ; Mon, 11 Apr 2011 06:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.539 X-Spam-Level: X-Spam-Status: No, score=-1.539 tagged_above=-999 required=5 tests=[AWL=-0.740, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4RjxdUg8j9Hb for ; Mon, 11 Apr 2011 06:45:32 -0700 (PDT) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by core3.amsl.com (Postfix) with ESMTP id 63C603A6B17 for ; Mon, 11 Apr 2011 06:45:31 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Mon, 11 Apr 2011 16:45:31 +0300 From: Leon Portman To: "Parthasarathi R (partr)" , "Elwell, John" , "Paul Kyzivat (pkyzivat)" , "siprec@ietf.org" Date: Mon, 11 Apr 2011 16:45:29 +0300 Thread-Topic: [siprec] Partial updates and identifiers Thread-Index: Acv0jVXI4ji2YTo+SquJ6T6YR3i+lQAdOkDgAEETmvAAg54qsAADKDEgAADSn+AACl0k8A== Message-ID: <07465C1D981ABC41A344374066AE1A2C38AB6E1DFC@TLVMBX01.nice.com> References: <4D9CB8E1.7030402@cisco.com> In-Reply-To: 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: "Peter Saint-Andre \(psaintan\)" , Hadriel Kaplan , "Joe Hildebrand \(jhildebr\)" Subject: Re: [siprec] Partial updates and identifiers X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 11 Apr 2011 13:45:33 -0000 Hello As I have mentioned in another thread, we also have a use case of persiste= nt recording of specific participant (between login/logout events for examp= le), where participant will not have media, CS or CSG and will be connecte= d directly to RS. We will have m-lines with label in RS SDP and SRC will update SRS with meta= data with CS and media streams that point to these labels per CS. Leon -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Parthasarathi R (partr) Sent: Monday, April 11, 2011 12:29 PM To: Elwell, John; Paul Kyzivat (pkyzivat); siprec@ietf.org Cc: Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr); Hadriel Kaplan Subject: Re: [siprec] Partial updates and identifiers John, Please read inline. Thanks Partha=20 -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] Sent: Monday, April 11, 2011 2:11 PM To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); siprec@ietf.org Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr) Subject: RE: [siprec] Partial updates and identifiers =20 > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > Sent: 11 April 2011 08:35 > To: Elwell, John; Paul Kyzivat (pkyzivat); siprec@ietf.org > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe Hildebrand > (jhildebr) > Subject: RE: [siprec] Partial updates and identifiers >=20 > John, >=20 > As I mentioned below, stream block will be unique within CS, (not=20 > required to be unique across multiple CS) and so, xml:id or enhancing=20 > the normative statement of RFC 4574 label attribute to be unique=20 > within CS will serve the purpose. I'm fine with any of the above=20 > mentioned id. > Please note that RFC 4574 "label" attribute is the nature data for RS=20 > dialog. >=20 > In case participant within CS, xml:id will serve the purpose but we=20 > need to get more clarity about participants who are not part of CS but > within RS. [JRE] If I understand the figure in section 3 of metadata-04 correctly, a P= articipant can have a relationship with a CS, but no direct relationship wi= th an RS. Sorry, I mixed up my statement with the latest update of making CS= G optional. As per Sec 3 of metadata-04, participant has direct relationshi= p with CSG in case CS is left completely unattached. In case CSG is optiona= l, then participant will have direct relationship with RS in case there is = no relationship between CS and participant. =20 So a participant that does not have a relationship with a CS is left compl= etely unattached, unless it has a relationship with a Media Stream (which a= lways has a relationship with a CS). So to summarize: - a Participant can have a direct relationship with a CS; or - a Participant can have an indirect relationship with a CS (via a Media St= ream); agreed - a Participant can have no relationship with a CS, and therefore no relati= onship with an RS. Do we really need this last case? I'm happy if the last case is not required because it simplify the= solution and there is no need of unique id for participant. But SRS implem= enters may prefer to have relationship with participant and RS. I wish more= opinion before taking decision whether to remove the last case > Because CS may span across different RS how about the participant who=20 > are not part of CS? [JRE] I don't understand the words "Because CS may span across different RS= ", because in the rest of the sentence you are talking about a Participant = that is not part of a CS. > Ex: One of the user in the conference acts as SRC, fetch participant=20 > info using conferene package and new RS is created during initial=20 > conference creation and hold&resume of a user within CS. [JRE] I am not sure what you are trying to say here. I would consider a use= r whose identity is obtained via a conference event package as being part o= f the CS. I'm trying to give the example where participant is not associated= with CS directly but related to CSG (/RS). This scenario was considered as= a blocking in -03 version of metadata. I'm not arguing to have this scenar= io but it is major concern for few folks. CS is between focus and UA, UA acts as SRC, UA receives the participant inf= o via conference event package but those participants are not related in CS= directly (and only focus is related) but they contributed for the mixed st= ream. That user is sending/receiving Media Streams that are part of a CS, or if = it isn't sending/receiving Media Streams, what is the relevance of that Par= ticipant? Mixed media stream from focus to UA belongs to the Conference even= t package participants. There participant are not directly involved as part= of CS. Why would we create a new RS for such a participant?=20 RS is not created for participant. Multiple RS shall be created th= e same CS during the different time frame as shown below <-------------------CS1-------------> <---RS1--> <---RS2------>=20 CS1 is between UA (SRC) and focus whereas RS1, RS2 is between UA (SRC) and = SRS. Here tangling (conference event package) participant has to be grouped= together in RS1, RS2 by some means through given metadata. The question wh= ether this corner has to be solved ? John (as individual) >=20 > Thanks > Partha >=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Friday, April 08, 2011 9:36 PM > To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); siprec@ietf.org > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe Hildebrand > (jhildebr) > Subject: RE: [siprec] Partial updates and identifiers >=20 > Focusing just on participant and stream for the time being, do these=20 > need to be unique across multiple CSs or not? >=20 > John >=20 > > -----Original Message----- > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > Sent: 07 April 2011 10:51 > > To: Paul Kyzivat (pkyzivat); siprec@ietf.org; Elwell, John > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe Hildebrand > > (jhildebr) > > Subject: RE: [siprec] Partial updates and identifiers > >=20 > > John, > >=20 > > Sorry for the lengthy mail but it contains lot of analysis and=20 > > reasoning for this id approach. > >=20 > > Adding to Paul's point, I wish to give more background and > reason for > > these globally unique id. Initially I had the impression that the=20 > > single unique id (RS dialog-id) in the recording (session > level) and > > some relevant natural id for the rest of the element will serve the=20 > > purpose. > > There are usecases where this assumption fails. Even I have > thought of >=20 > > using "xml:id" instead of URN UUID to avoid long string but > xml:id may >=20 > > not end up with unique value always. Our analysis for URN UUID for=20 > > each level is as follows and please provide your input in case id=20 > > shall be > > tweaked: > >=20 > > 1) Recording block: The reason for globally unique id is > that multiple >=20 > > SRC with same id to single SRS. > >=20 > > Topology: > >=20 > > SRC1 SRC2 > > | | > > | ----(RS1-ID1)-----SRS1 > > | > > ---(RS2-ID1)------------------SRS1 > >=20 > > In the above topology, it is possible for ID1 is generated by both > > SRC1 and SRC2 at the same time. > >=20 > > 2) group (CSG) block: Grouping mechanism (Hadriel session-id, Paul=20 > > Jones > > Session-UUID) is outside the scope of SIPREC. URN UUID > abstracts the > > exact mechanism to SRS and provides the information only about the=20 > > group of CS from SRC perspective. It possible that group may span=20 > > across multiple RS and It is up to SRS to group and view as single=20 > > recording. > > Here, the single level id in the top will fail. The counter > argument > > is to force the single RS having complete CSG but it*may not* be=20 > > possible in SRC implementation. Here, xml:id will not serve the=20 > > purpose > >=20 > > 3) session (CS) block: At the immediate look, session falls exactly=20 > > under recording block. Use case 3 of draft-ietf-siprec-req-09=20 > > illustrates where CS span across multiple RS. This > requirement calls > > for unique id in session by which these session shall be viewed as=20 > > single CS even though there is no group exists among them. IMO, in=20 > > case session should not have globally unique id, then it is > preferred > > to remove usecase 3 in the requirement. > >=20 > > 4) participant block: It needs some id which may be AOR but > AOR is not >=20 > > unique. IMO, xml:id may serve the purpose with session > unique id. The > > trick exists for participant who are not associated with > CS. We shall > > discuss and fine tune if required. > >=20 > > 5) stream block: Label attribute shall be used as unique > value but RFC > > 4574 does not mandate label attribute has to be unique across the=20 > > dialog or CS and so, it may possible to change within RS and no=20 > > normative statement to stop this implementation. IMO, > xml:id may serve >=20 > > the purpose with session unique id. Here as well, We shall > discuss and >=20 > > fine tune if required. > >=20 > > 6) extensiondata block: This is tracked in the separate mail thread=20 > > whether unique id is required or not. Let us close this as part of=20 > > that mail thread. > >=20 > > Including explicitly Hadriel, Peter, Joe in this mail > thread as they > > have different view on this ID mechanism. > >=20 > > I had offline discussion with Hadriel in Prague after > SIPREC meeting > > and my understanding of his major concern is that how SRS > will be able >=20 > > to design the database in case partial update does not have > recording > > (top) id information. I'll put more thought processing to close=20 > > Hadriel concern of how top id has to be tracked in case > partial update >=20 > > by which SRS implementation will be simplified in terms of > aggregation >=20 > > maintenance. > >=20 > > Thanks > > Partha > >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > (pkyzivat) > > Sent: Thursday, April 07, 2011 12:33 AM > > To: siprec@ietf.org > > Subject: Re: [siprec] Partial updates and identifiers > >=20 > > John, > >=20 > > For the moment we have proposed that the ids be conveyed in > the form > > of URIs that are globally unique, and specifically that > they be UUID > > URNs. > > There is no dependency on the particular form of the URI, but=20 > > specifying they must be UUID URNs makes it possible to perform some=20 > > internal optimizations for storage. > >=20 > > The UUID URN is a pretty inefficient encoding. A UUID can > be expressed >=20 > > in 32 bits, so we could consider retaining UUIDs but alter the=20 > > encoding if its really an issue. However I am far from > convinced that > > the size of the IDs is going to be a major issue in the > overall size > > of messages, so I think its probably premature to worry about it. > >=20 > > Because the ids can be expressed in 32 bits, the SRC and > SRS can store >=20 > > them internally that way, thus reducing the runtime cost of=20 > > maintaining the data. > >=20 > > The use of unique ids is a significant part of the overall > approach to >=20 > > formatting updates. If somebody has a different concept in mind it=20 > > could be useful to have an alternative proposal for the > format. If we > > had two worked out approaches we could compare the > tradeoffs in each. > >=20 > > Thanks, > > Paul > >=20 > > On 4/6/2011 10:24 AM, Elwell, John wrote: > > > Much of the discussion on draft-ram-metadata-format in Prague > > concerned the mechanism for performing partial updates and > the use of > > identifiers. The draft permits partial updates by allowing > individual > > objects (e.g., CS, participant, media stream) to be sent > with updated > > content, without having to send again other objects that have not=20 > > changed. So, for example, in a large conference, it would > be possible > > to add or modify an individual participant object without having to=20 > > send all the other participant objects again. I do not recall any=20 > > opposition to this basic principle. > > > > > > However, to achieve this, every object requires an > > identifier, and it > > was asserted that these identifiers need to be globally > unique for all >=20 > > time. Although this might be efficient for updating an individual=20 > > object, when sending many objects (e.g., at the start of a > CS or when > > refreshing the entire metadata), this can make the metadata very=20 > > bulky. > > It depends, of course, on the format of the identifiers, and it was=20 > > stated that there could be alternatives to UUID. Nevertheless, some=20 > > people had concerns. These concerns also extended to the > impact on the >=20 > > database where metadata is stored, since it might not be > feasible to > > convert to a database-friendly mechanism for linking > objects together. > > > > > > One alternative proposal during the meeting was to have a single > > unique identifier at the top level (for the RS) and use local=20 > > identifiers for other objects. Thus when updating a single > object, it > > would be necessary to include the top level identifier as > well as one > > or more local identifiers. However, there were also concerns this=20 > > might not fulfil actual or perceived future requirements. > > > > > > Please continue discussion on this. > > > > > > John (as chair) > > > _______________________________________________ > > > siprec mailing list > > > siprec@ietf.org > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > >=20 >=20 _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From pkyzivat@cisco.com Mon Apr 11 08:28:57 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBE723A6A47 for ; Mon, 11 Apr 2011 08:28:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.525 X-Spam-Level: X-Spam-Status: No, score=-110.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dA16bEQ2wd13 for ; Mon, 11 Apr 2011 08:28:57 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 873473A697E for ; Mon, 11 Apr 2011 08:28:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=716; q=dns/txt; s=iport; t=1302535737; x=1303745337; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=pLSMmWXvgAPeEvH2Y7+5VatHoFyssZ/HdCsTCwBqE5o=; b=OjEc00402nG07Jn9m2Syc/em1gkc4X5XZxRhQerHCcnrhctC+trYe2cR zjIPkd6XIrLRBwDBZc44hfdtQwSNB5g8pwkPytROCv6+ye9pQuMb6wGs+ WgYQ0cK1ATEvPnGuFY+sx9Z8dlAGhuxkzOO3RpeVt5Zgtxp/UWF83MPRH U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoIHAIYdo02tJV2a/2dsb2JhbACZAI0ad6ZhnAaCfoJwBI1Yg2o X-IronPort-AV: E=Sophos;i="4.63,339,1299456000"; d="scan'208";a="293762702" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by sj-iport-3.cisco.com with ESMTP; 11 Apr 2011 15:28:56 +0000 Received: from [161.44.174.125] (dhcp-161-44-174-125.cisco.com [161.44.174.125]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3BFSi3Q023852 for ; Mon, 11 Apr 2011 15:28:45 GMT Message-ID: <4DA31E2C.6080008@cisco.com> Date: Mon, 11 Apr 2011 11:28:44 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: siprec@ietf.org References: <07465C1D981ABC41A344374066AE1A2C38AB6E1DC4@TLVMBX01.nice.com> In-Reply-To: <07465C1D981ABC41A344374066AE1A2C38AB6E1DC4@TLVMBX01.nice.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] metadata model and persisent recording X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 11 Apr 2011 15:28:57 -0000 Leon, Is it important that a persistent RS identify a participant when there is no CS? Isn't it sufficient to identify the participant at the time the CS is reported? Thanks, Paul On 4/11/2011 9:24 AM, Leon Portman wrote: > Partha Hi > > I think we are missing in the metadata model support for persistent > recording mode, where RS INVITE may be sent from SRC to SRC with > participant info but without any communication session or group. For > example where RS will be established when somebody logins to the phone. > > Regards > > Leon > > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From eckelcu@cisco.com Mon Apr 11 08:32:54 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFE883A697E for ; Mon, 11 Apr 2011 08:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.579 X-Spam-Level: X-Spam-Status: No, score=-10.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pyvnXZre6YrZ for ; Mon, 11 Apr 2011 08:32:52 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id A559628C12B for ; Mon, 11 Apr 2011 08:32:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=7553; q=dns/txt; s=iport; t=1302535973; x=1303745573; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=Cy1gHvPrkmtxEiOh1TUTMiBqL9prZmSV+TjyvOqW/FU=; b=JLnnllMLb9LIsStqHXbA9XZyhMrGY7uUV7ZCrFlmEopJmCq8pwMxKTn9 fghNmqVD2faCTZOr+3DnUa90p0d+nKzAo0qDDJwT98hrSOOzNZ1Kjg1Ii YXiZH4sYecU4qMJsn9+M3LFjofooniy4gXKBJh78zKQIqaTNCEnyAVdkT g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8BAC4eo02rRDoI/2dsb2JhbACYQI1Zd6ZfnAeFbgSFW4tu X-IronPort-AV: E=Sophos;i="4.63,339,1299456000"; d="scan'208";a="334714405" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 11 Apr 2011 15:32:52 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3BFWqKS031049; Mon, 11 Apr 2011 15:32:52 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); Mon, 11 Apr 2011 08:32:52 -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, 11 Apr 2011 08:32:50 -0700 Message-ID: In-Reply-To: <4DA3048E.5000103@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Recording awareness indication Thread-Index: Acv4TeQi+KylUoLKQ8aqVd4Ks0+vxQADzIHA References: <4D9CBB90.4080804@cisco.com> <059AF07365DC474393A19A3AF187DF7406E677EF@NAHALD.us.int.genesyslab.com> <4DA3048E.5000103@cisco.com> From: "Charles Eckel (eckelcu)" To: "Paul Kyzivat (pkyzivat)" , "Henry Lum" X-OriginalArrivalTime: 11 Apr 2011 15:32:52.0626 (UTC) FILETIME=[B8CCAF20:01CBF85D] Cc: siprec@ietf.org Subject: Re: [siprec] Recording awareness indication X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 11 Apr 2011 15:32:54 -0000 My thinking on this is that recording awareness indication may be useful to indicate an ability to request and/or provide recording. As such, I may place a call and see in the response that I have the ability to request this call, or not. I also thought this indication may be useful to help a SRC determine how best to indicate to a UA that its media is being recorded. In both case, but especially in the former, the indication is not tied to the media, so I think it makes more sense to signal it as a feature tag than as an SDP attribute.=20 Cheers, Charles > -----Original Message----- > From: Paul Kyzivat (pkyzivat) > Sent: Monday, April 11, 2011 6:39 AM > To: Henry Lum > Cc: Charles Eckel (eckelcu); siprec@ietf.org > Subject: Re: [siprec] Recording awareness indication >=20 >=20 >=20 > On 4/8/2011 10:46 AM, Henry Lum wrote: > > Currently in the draft we propose to use an SDP attribute to declare the > > awareness. I saw comments that this should be changed to a feature tag > > instead. I am okay either way; are there arguments against using a > > feature tag? >=20 > IIUC the main argument has been to use SDP attributes to indicate that > recording is being done. And there it *is* important for it to be in SDP > so it can be indicated on a per-media basis. >=20 > For the awareness indicator its not so clear cut. Certainly we could > define awareness so that it applies to all media, and then it *could* be > in the SIP rather than the SDP. It then comes down to taste - for > consistency it might be preferable to indicate it in SDP. I don't have a > strong preference one way or the other. >=20 > Thanks, > Paul >=20 > > Regards, > > Henry > > > >> -----Original Message----- > >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >> Behalf Of Charles Eckel (eckelcu) > >> Sent: Thursday, April 07, 2011 3:45 PM > >> To: Paul Kyzivat (pkyzivat); siprec@ietf.org > >> Subject: Re: [siprec] Recording awareness indication > >> > >> I agree with Paul. I would hate to force the addition of an audible > >> beep > >> or a red dot to all participants when a less intrusive mechanism is > >> supported. > >> > >> Cheers, > >> Charles > >> > >>> -----Original Message----- > >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >> Behalf Of Paul Kyzivat (pkyzivat) > >>> Sent: Wednesday, April 06, 2011 12:14 PM > >>> To: siprec@ietf.org > >>> Subject: Re: [siprec] Recording awareness indication > >>> > >>> I liked this concept of an overt "opt-out" of the in-band > > indication. > >>> ISTM that if the UA has a "better" way of doing the indication it > > may > >>> not want the default mechanism. (E.g. The UA may want to apply its > >> own > >>> in-band indication. But that won't work well if a different one has > >>> already been applied.) > >>> > >>> If we can agree on the *concept* of opt-out, then we can determine > >> the > >>> exact form as a subsequent step. > >>> > >>> I suppose some SRCs may feel they are obliged to do their own > >> indication > >>> even if a participant desires to opt-out, and we ought to allow that > >>> too. In that case there should probably be some indication that the > >>> opt-out has been ignored, so that the UA can behave accordingly. > >>> > >>> Thanks, > >>> Paul > >>> > >>> On 4/6/2011 11:08 AM, Elwell, John wrote: > >>>> My own thoughts on this are that the SIP/SDP indication that > >> recording is in progress, even if sent > >>> to a UA known to be recording-aware, should not be used as a > >> substitute for other non-SIP/SDP means of > >>> notification that might otherwise be needed (e.g., an in-band audio > >> announcement). I think recording > >>> indicators should be used to complement other means. For example, an > >> in-band audio announcement would > >>> be able to reach all users (although might be problematic for > >> hearing-impaired users or for users > >>> speaking a different language). Despite such limitations, an in-band > >> announcement is often sufficient > >>> to satisfy legal requirements. On the other hand, a SIP/SDP > >> indication > >> that recording is in progress > >>> could be rendered in different ways and in different languages at > > the > >> user interface of a recording- > >>> aware UA. > >>>> > >>>> For this reason, I don't see a need for the recording-aware > >> indication in SIP/SDP. Recording > >>> indications can be sent without knowing whether they will be > >> understood by the receiving UA - if they > >>> are understood the user might get an enhanced indication - if not > >> they > >> will be discarded and the user > >>> will get only the basic (non-SIP/SDP) indication. > >>>> > >>>> John (as individual) > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: siprec-bounces@ietf.org > >>>>> [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > >>>>> Sent: 06 April 2011 15:55 > >>>>> To: siprec@ietf.org > >>>>> Subject: [siprec] Recording awareness indication > >>>>> > >>>>> There was an inconclusive discussion in Prague on the > >>>>> recording awareness signalling indication in > >>>>> draft-portman-siprec-protocol (slide 6 / section 6.1 of > >>>>> draft). If I understand correctly, it indicates that a UA > >>>>> involved in the CS supports the SIPREC extensions relevant to > >>>>> the CS. In particular, it indicates that the UA would be able > >>>>> to understand SIP/SDP recording indications (slide 7 / > >>>>> section 6.2 of draft). It seems the recording awareness > >>>>> indication means that the SRC can rely on the recording > >>>>> indications in SIP/SDP to advise the user that recording is > >>>>> in progress, thereby avoiding the need for the SRC to provide > >>>>> suitable indications through non-SIP means (e.g., in-band > >>>>> audio announcements). > >>>>> > >>>>> Please continue this discussion. > >>>>> > >>>>> John (as chair) > >>>>> _______________________________________________ > >>>>> siprec mailing list > >>>>> siprec@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/siprec > >>>>> > >>>> _______________________________________________ > >>>> siprec mailing list > >>>> siprec@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/siprec > >>>> > >>> _______________________________________________ > >>> siprec mailing list > >>> siprec@ietf.org > >>> https://www.ietf.org/mailman/listinfo/siprec > >> _______________________________________________ > >> 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 Leon.Portman@nice.com Mon Apr 11 08:36:52 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77C9D3A6A72 for ; Mon, 11 Apr 2011 08:36: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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2oqR2NLSbjFU for ; Mon, 11 Apr 2011 08:36:51 -0700 (PDT) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by core3.amsl.com (Postfix) with ESMTP id 044423A697E for ; Mon, 11 Apr 2011 08:36:51 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Mon, 11 Apr 2011 18:36:50 +0300 From: Leon Portman To: Paul Kyzivat , "siprec@ietf.org" Date: Mon, 11 Apr 2011 18:36:50 +0300 Thread-Topic: [siprec] metadata model and persisent recording Thread-Index: Acv4XTAKi/ZJFIEdSLCuZF2ohpHgHAAAPlDg Message-ID: <07465C1D981ABC41A344374066AE1A2C38AB6E1E75@TLVMBX01.nice.com> References: <07465C1D981ABC41A344374066AE1A2C38AB6E1DC4@TLVMBX01.nice.com> <4DA31E2C.6080008@cisco.com> In-Reply-To: <4DA31E2C.6080008@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] metadata model and persisent recording X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 11 Apr 2011 15:36:52 -0000 Actually yes, because it is common for persistent session that SRS channel = are predefined per DN (participant) Leon -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Paul Kyzivat Sent: Monday, April 11, 2011 6:29 PM To: siprec@ietf.org Subject: Re: [siprec] metadata model and persisent recording Leon, Is it important that a persistent RS identify a participant when there is n= o CS? Isn't it sufficient to identify the participant at the time the CS is= reported? Thanks, Paul On 4/11/2011 9:24 AM, Leon Portman wrote: > Partha Hi > > I think we are missing in the metadata model support for persistent=20 > recording mode, where RS INVITE may be sent from SRC to SRC with=20 > participant info but without any communication session or group. For=20 > example where RS will be established when somebody logins to the phone. > > Regards > > Leon > > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From dburnett@voxeo.com Mon Apr 11 08:45:20 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78BDB3A697E for ; Mon, 11 Apr 2011 08:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5socK1ZfgOFk for ; Mon, 11 Apr 2011 08:45:19 -0700 (PDT) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with ESMTP id 9F2413A6937 for ; Mon, 11 Apr 2011 08:45:18 -0700 (PDT) Received: from [76.111.43.10] (account dburnett@voxeo.com HELO [192.168.15.101]) by voxeo.com (CommuniGate Pro SMTP 5.3.8) with ESMTPSA id 83976892; Mon, 11 Apr 2011 15:45:18 +0000 Message-Id: <48384EF2-73DD-4ECA-A87E-93847E995E80@voxeo.com> From: Dan Burnett To: Paul Kyzivat In-Reply-To: <4D9CDFC0.9070300@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 11 Apr 2011 11:45:17 -0400 References: <4D9CDFC0.9070300@cisco.com> X-Mailer: Apple Mail (2.936) Cc: siprec@ietf.org Subject: Re: [siprec] extensionData in XML X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 11 Apr 2011 15:45:20 -0000 As someone who works quite a bit with XML, I'll point out that there is an important distinction between data for extensibility and expected application-specific data. As an example of the latter, EMMA [1] is an XML format for representing the input of a user (human being, commonly) to an automated system, by speech, gesture, pen, etc. Since the way an input is interpreted is dependent upon its intended use, there was a need for a designated application-specific section to represent the semantics (meaning) of the input. To make it easier for machine consumers of this format that may be seeking the semantics, there is a designated element "interpretation" that holds this information. The contents of this element are arbitrary XML in an application-specific XML namespace. On the other hand, every XML specification I've worked on in W3C has needed a way for implementers to innovate via extensions. Traditionally this is handled via custom elements and attributes in an implementer-specific namespace to avoid name collision with the standard elements and attributes. Since these true innovation extensions can occur anywhere, there is no specific XML element established in most specifications for "extensions". Instead, the specification defines the expected behavior of a conformant processor upon encountering elements and attributes outside of the specification's standard namespace. The nice thing about this approach is that allows for innovation in a way that does not cause name collision but which could become part of the standard in the future (and be moved into the standard's namespace). For the specifications I worked on, we always required that a conformant processor had to do the behavior defined in the specification when it received a conformant document but that the behavior of the processor when it encountered non-standard elements and attributes was at its own discretion -- it could process the attributes, ignore them, or report an error, as it deemed appropriate. So the real question for us here is whether these extension elements are *extensions* (which do not require a custom element/location) or *expected application-specific information* (which can benefit from custom elements and prescribed locations in the XML tree). -- dan [1] http://www.w3.org/TR/emma/ On Apr 6, 2011, at 5:48 PM, Paul Kyzivat wrote: > > > On 4/6/2011 8:57 AM, Elwell, John wrote: >> Yes, I would be keen to hear Peter's or other opinions, but one >> other point. One of the properties of XML is that it is human- >> readable. Having extension data as a child element of the element >> representing the object to which it applies seems, in my opinion, >> to make it more readable. Having extension data as a separate >> element, with a link to the element to which it applies, seems hard >> for a human reader, particularly if the link is a long, random >> string. > > IMO human readability of the xml is a secondary/tertiary concern. > (SIP is in theory readable, but real sip on the wire tends to be > difficult to read due to need to match up non-ergonomic numeric > addresses and tags from one message to another.) > > I'm inclined to agree it would be better to embed extensions into > the basic elements, but not primarily due to readability. IMO > extensions should function as much like the predefined parts as > possible. (Today's extension may become common usage tomorrow.) > > I just don't know enough xml to define this "correctly". > > Thanks, > Paul > >> John (as individual) >> >> >>> -----Original Message----- >>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] >>> Sent: 06 April 2011 10:16 >>> To: Elwell, John; Hadriel Kaplan >>> Cc: siprec@ietf.org; Jain, Rajnish; Peter Saint-Andre (psaintan) >>> Subject: RE: [siprec] extensionData in XML >>> >>> John, >>> >>> Please read inline >>> >>> Thanks >>> Partha >>> >>> -----Original Message----- >>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>> Sent: Wednesday, April 06, 2011 2:02 PM >>> To: Parthasarathi R (partr); Hadriel Kaplan >>> Cc: siprec@ietf.org; Jain, Rajnish >>> Subject: RE: [siprec] extensionData in XML >>> >>> I already posted on this topic on the other thread. Partha >>> states below >>> an additional motivation for handling extension data in the way >>> specified in the current I-D. My counter argument is that anyone >>> specifying particular extension data could specify the expected >>> behaviour when extension data is present in an object and then >>> absent >>> when that object is updated. For some types of metadata it >>> could be that >>> absence means it no longer applies, and for other types of >>> metadata it >>> could be that absence means it has not changed. >>> >>> Currently, metadata format draft XML element is written >>> with >>> the basics that "it is no longer applies" in case specific element >>> is >>> absent in the update. The question is how the information of >>> extensiondata absence means "it is no longer applies" or "it has not >>> changed" has to be passed between SRC and SRS. Here, there is >>> a need of >>> common understanding between SRC and SRS or else the >>> information will be >>> misunderstand even though both parties understand the specific >>> extension. >>> >>> The current extensiondata is taken the route of all other >>> metadata block >>> XML element definition. There may be better way to represent in >>> extensiondata XML element apart from creating new metadata block >>> with >>> URN UUID. I'm including Peter for his advise on XML front. >>> >>> The latter approach would avoid the need for repeating large >>> quantities >>> of metadata each time there is a minor change to an object. >>> >>> John (as individual) >>> >>>> -----Original Message----- >>>> From: siprec-bounces@ietf.org >>>> [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi >>> R (partr) >>>> Sent: 03 April 2011 19:46 >>>> To: Hadriel Kaplan >>>> Cc: siprec@ietf.org; Jain, Rajnish >>>> Subject: Re: [siprec] extensionData in XML >>>> >>>> Hadriel, >>>> >>>> I guess we have common understaning to the extend that the >>> intention >>>> is to send some extensiondata (Unknown) attribute by SRC >>> which may or >>>> may not understand by SRS and also for the usage of xs:any as the >>>> solution. Few stuff are missing in yours proposal w.r.t >>> partial data >>>> passing of extensiondata: >>>> >>>> The question is whether there is a need to pass the extension data >>>> during every time the corresponding metadata block is passed or >>>> updated. For example, CS metadata block sends extension >>> data specific >>>> to call center data like Agent is remote or local, agent or >>> customer >>>> initiated call (direction) during the CS block creation >>> (INVITE) and >>>> these constant information in extensiondata is not required to be >>>> passed in each update of CS metadata like adding video >>> stream in the >>>> mid-session. >>>> >>>> The current model allows to pass extensiondata only during >>> the initial >>> >>>> CS block creation and there is no need to update or resend while CS >>>> block is getting updated with other CS information. IMO, >>> The current >>>> extensiondata mechanism is required as SIPREC puts lot of >>> call centre >>>> specific attributes proposed during metadata model draft review as >>>> outside the scope of SIPREC and most of the attributes >>> mentioned are >>>> constant within the scope of session. >>>> >>>> Also, it is possible to pass update only extension data within RS >>>> session without impacting parent element. Please let me >>> know your and >>>> others opinion whethter it is fine to continue with the current >>>> extension-data element or to move xs:any element to each of the >>>> metadata block. >>>> >>>> Thanks >>>> Partha >>>> ________________________________ >>>> >>>> From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] >>>> Sent: Sat 4/2/2011 6:19 PM >>>> To: Parthasarathi R (partr) >>>> Cc: Jain, Rajnish; siprec@ietf.org >>>> Subject: Re: [siprec] extensionData in XML >>>> >>>> >>>> >>>> Hi Partha, >>>> I think you're missing my point (or I'm missing yours) - you can do >>>> all of that without specifying an "extensionData" XML element. >>>> Unknown XML elements are simply ignored by the other side, so Cisco >>>> can add a "ciscoPrivateData" XML element wherever it wants >>> and send it >>> >>>> to an Acme; and that private element will be ignored by Acme while >>>> everything else will continue to work. Which I think is >>> the behavior >>>> you want, right? >>>> >>>> -hadriel >>>> >>>> >>>> On Apr 1, 2011, at 10:37 AM, Parthasarathi R (partr) wrote: >>>> >>>>> Hadriel/Raj, >>>>> >>>>> Extensiondata XML is provided as per Metadata model >>>> extensiondata block. >>>>> During the initial discussion of metadata model draft, we >>>> realized that >>>>> lot of attributes specified for recording are call center >>>> specific or >>>>> specific domain related and it is outside the scope of IETF >>>> SIPREC but >>>>> it is required for those specific solution to work. >>>> Extensiondata XML >>>>> element helps to meet those requirement. >>>>> >>>>> Extensiondata is provided with URN UUID to pass or not pass >>>>> independently in partial data. But it is open item whether >>>> extensiondata >>>>> has to be within specific metadatablock or not. >>>>> >>>>> Please read inline for more comments. >>>>> >>>>> Thanks >>>>> Partha >>>>> >>>>> -----Original Message----- >>>>> From: siprec-bounces@ietf.org >>>> [mailto:siprec-bounces@ietf.org] On Behalf >>>>> Of Jain, Rajnish >>>>> Sent: Friday, April 01, 2011 6:41 PM >>>>> To: Hadriel Kaplan; siprec@ietf.org >>>>> Subject: Re: [siprec] extensionData in XML >>>>> >>>>> There may be such motivation from how the CSTA standards >>>> are specified. >>>>> They have an element called privateData for each message. It is a >>>>> placeholder for any non-standardized extensions. This could >>>> be legacy >>>>> and may not mean much for the modern text based protocols. >>>>> >>>>> I really didn't get the reason why is it not >>>> require for modern >>>>> text based protocols. This is more like generic param in >>>> SIP or xs:any >>>>> in XML. RFC 6120 is a new RFC which has the similar usage. >>>>> >>>>> >>>>> That said, I think you're right (this generally applies >>> to any text >>>>> based protocols and is the fundamental basis for forward/backward >>>>> compatibility in such protocols). >>>>> >>>>> Raj >>>>> >>>>> >>>>> ----------------------------------------------------- >>>>> Please consider the environment before printing this email. >>>>> >>>>>> -----Original Message----- >>>>>> From: siprec-bounces@ietf.org >>> [mailto:siprec-bounces@ietf.org] On >>>>>> Behalf Of Hadriel Kaplan >>>>>> Sent: Thursday, March 31, 2011 8:43 PM >>>>>> To: siprec@ietf.org >>>>>> Subject: [siprec] extensionData in XML >>>>>> >>>>>> Howdy, >>>>>> With regards to the extensionData concept and XML, I have >>>> a few basic >>>>>> questions. I am by no means an XML expert so it could >>>> just be my lack >>>>> >>>>>> of knowledge which makes me confused. If so, just tell >>> me to RTFM. >>>>>> >>>>>> draft-ram-siprec-metadata-04 says in section 4.6: >>>>>> A recording metadata object contains additional data not >>>> specified >>>>>> as >>>>>> part of siprec. This is intended to accommodate >>> future standards >>>>>> track extensions, as well as vendor and user specific >>> extensions. >>>>>> The mechanism MUST provide a means of unambiguously >>>> distinguishing >>>>>> such extension data. >>>>>> >>>>>> What confuses me is I didn't think XML had to do such >>>> machinations to >>>>>> accommodate this need. I thought we could just specify >>> in our RFCs >>> >>>>>> that unknown XML elements and attributes MUST be >>> ignored, so that >>>>>> future RFCs could add them without having to leave >>>> specific "blob" XML >>>>> >>>>>> elements to carry such data. Or at least that's what >>> we've done so >>> >>>>>> far in SIP RFCs with XML bodies, afaik. >>>>>> namespace model that could be used to disambiguate proprietary >>>>>> elements from standard ones. If both of those theories >>>> are correct, >>>>>> why do we need to define an extensionData element? >>>>>> >>>>>> -hadriel >>>>>> >>>>>> _______________________________________________ >>>>>> siprec mailing list >>>>>> siprec@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>> >>>>> DISCLAIMER: This e-mail may contain information that is >>>> confidential, >>>>> privileged or otherwise protected from disclosure. If you >>> are not an >>> >>>>> intended recipient of this e-mail, do not duplicate or >>>> redistribute it >>>>> by any means. Please delete it and any attachments and >>>> notify the sender >>>>> that you have received it in error. Unintended recipients >>>> are prohibited >>>>> from taking action on the basis of information in this >>> e-mail.E-mail >>> >>>>> messages may contain computer viruses or other defects, >>> may not be >>>>> accurately replicated on other systems, or may be >>>> intercepted, deleted >>>>> or interfered with without the knowledge of the sender or >>>> the intended >>>>> recipient. If you are not comfortable with the risks >>> associated with >>> >>>>> e-mail messages, you may decide not to use e-mail to >>>> communicate with >>>>> IPC. IPC reserves the right, to the extent and under >>> circumstances >>>>> permitted by applicable law, to retain, monitor and >>> intercept e-mail >>> >>>>> messages to and from its systems. >>>>> _______________________________________________ >>>>> siprec mailing 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@cisco.com Mon Apr 11 08:56:40 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AD563A6B23 for ; Mon, 11 Apr 2011 08:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.526 X-Spam-Level: X-Spam-Status: No, score=-110.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vleCpDpusbEa for ; Mon, 11 Apr 2011 08:56:39 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 44F273A6A72 for ; Mon, 11 Apr 2011 08:56:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=1608; q=dns/txt; s=iport; t=1302537399; x=1303746999; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=O4uAiAElNUFGgxrLQxBTwcJ2CTzh1+kHEnNr8dYF4gY=; b=TrEXpDAAvzVvbKTBJ0HdfeLfVVu6aD1kpD/rYOT5SDzeDyCzV7J1rZn7 WkWJrr1Yfwn5OQTawncwlrVra2zi3uj6DcChq8JR7YH7l9IgoiEHwpHiu PvQgL7yYDFoNa2SrCIzd4egB/Kq+muNis2Q0bkzd5gi1RSybHjzsXa52j s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8BAPwjo02tJXG9/2dsb2JhbACYQI1ad4h6nWacDoJ+gnAEjViDag X-IronPort-AV: E=Sophos;i="4.63,339,1299456000"; d="scan'208";a="334730263" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by sj-iport-2.cisco.com with ESMTP; 11 Apr 2011 15:56:36 +0000 Received: from [161.44.174.125] (dhcp-161-44-174-125.cisco.com [161.44.174.125]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3BFuZCD032266; Mon, 11 Apr 2011 15:56:35 GMT Message-ID: <4DA324B3.2090803@cisco.com> Date: Mon, 11 Apr 2011 11:56:35 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Leon Portman References: <07465C1D981ABC41A344374066AE1A2C38AB6E1DC4@TLVMBX01.nice.com> <4DA31E2C.6080008@cisco.com> <07465C1D981ABC41A344374066AE1A2C38AB6E1E75@TLVMBX01.nice.com> In-Reply-To: <07465C1D981ABC41A344374066AE1A2C38AB6E1E75@TLVMBX01.nice.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "siprec@ietf.org" Subject: Re: [siprec] metadata model and persisent recording X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 11 Apr 2011 15:56:40 -0000 On 4/11/2011 11:36 AM, Leon Portman wrote: > Actually yes, because it is common for persistent session that SRS channel are predefined per DN (participant) That seems to require a model change. We then have a participant that is not participating in anything. Or are you saying that there is a media stream involving this participant, even if it is inactive or silent? And even though there is no CS containing that MS. Thanks, Paul > Leon > > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Monday, April 11, 2011 6:29 PM > To: siprec@ietf.org > Subject: Re: [siprec] metadata model and persisent recording > > Leon, > > Is it important that a persistent RS identify a participant when there is no CS? Isn't it sufficient to identify the participant at the time the CS is reported? > > Thanks, > Paul > > On 4/11/2011 9:24 AM, Leon Portman wrote: >> Partha Hi >> >> I think we are missing in the metadata model support for persistent >> recording mode, where RS INVITE may be sent from SRC to SRC with >> participant info but without any communication session or group. For >> example where RS will be established when somebody logins to the phone. >> >> Regards >> >> Leon >> >> >> >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From rmohanr@cisco.com Mon Apr 11 09:09:41 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CBAB28C135 for ; Mon, 11 Apr 2011 09:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.453 X-Spam-Level: X-Spam-Status: No, score=-10.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DGs+kw9SfXp8 for ; Mon, 11 Apr 2011 09:09:39 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 43B7428C12F for ; Mon, 11 Apr 2011 09:09:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=2796; q=dns/txt; s=iport; t=1302538180; x=1303747780; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=agxze9pBEzpMjbpCpXhsnRbHopFFktdXBFgNmk9u8eQ=; b=lbu4Qkt949U/NbhjKSWe5AX0SnbQq8RpxbDbK59rQttlTRA6RMAqe9Fi qvUHsSs1P5tRr1SmQinC/2VtuZ5Ejn9DnA9gROoX1d7uK82wpir3t/BL7 fjm+HAzFrXSEmmv66873i8+SfShOAxRrHZYPnDAzVZHWH/EF6eyudufnv 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0BAIwmo02Q/khLgWdsb2JhbACYQI1aFAEBFiYlpwmcD4J+gnAEhVmLcA X-IronPort-AV: E=Sophos;i="4.63,339,1299456000"; d="scan'208";a="83105197" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 11 Apr 2011 16:09:38 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3BG9bab002068; Mon, 11 Apr 2011 16:09:38 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); Mon, 11 Apr 2011 21:39:37 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 11 Apr 2011 21:39:34 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD06009205@XMB-BGL-417.cisco.com> In-Reply-To: <4DA324B3.2090803@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] metadata model and persisent recording Thread-Index: Acv4YRgN+6uMi8HmT5i0gPX6axNzHAAAIdPw References: <07465C1D981ABC41A344374066AE1A2C38AB6E1DC4@TLVMBX01.nice.com><4DA31E2C.6080008@cisco.com><07465C1D981ABC41A344374066AE1A2C38AB6E1E75@TLVMBX01.nice.com> <4DA324B3.2090803@cisco.com> From: "Ram Mohan R (rmohanr)" To: "Paul Kyzivat (pkyzivat)" , "Leon Portman" , X-OriginalArrivalTime: 11 Apr 2011 16:09:37.0100 (UTC) FILETIME=[DAC4B8C0:01CBF862] Subject: Re: [siprec] metadata model and persisent recording X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 11 Apr 2011 16:09:41 -0000 Leon, I have a question here:- I understand that end points setup a persistent session (SIP dialog) with SRS even before CS is present.=20 Why do we need to report metadata at a point even when there is no CS ? Doing this will end up in changing the meaning of metadata itself which currently is defined as [Taken from requirement doc]. Metadata: Information that describes recorded media and the CS to which they relate.=20 If we are to consider the below case we should change metadata definition as now we can have a participant info reported in metadata who is not doing anything. Regards, Ram > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Paul Kyzivat (pkyzivat) > Sent: Monday, April 11, 2011 9:27 PM > To: Leon Portman > Cc: siprec@ietf.org > Subject: Re: [siprec] metadata model and persisent recording >=20 >=20 >=20 > On 4/11/2011 11:36 AM, Leon Portman wrote: > > Actually yes, because it is common for persistent session that SRS > channel are predefined per DN (participant) >=20 > That seems to require a model change. We then have a participant that > is > not participating in anything. >=20 > Or are you saying that there is a media stream involving this > participant, even if it is inactive or silent? And even though there is > no CS containing that MS. >=20 > Thanks, > Paul >=20 > > Leon > > > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Paul Kyzivat > > Sent: Monday, April 11, 2011 6:29 PM > > To: siprec@ietf.org > > Subject: Re: [siprec] metadata model and persisent recording > > > > Leon, > > > > Is it important that a persistent RS identify a participant when > there is no CS? Isn't it sufficient to identify the participant at the > time the CS is reported? > > > > Thanks, > > Paul > > > > On 4/11/2011 9:24 AM, Leon Portman wrote: > >> Partha Hi > >> > >> I think we are missing in the metadata model support for persistent > >> recording mode, where RS INVITE may be sent from SRC to SRC with > >> participant info but without any communication session or group. For > >> example where RS will be established when somebody logins to the > phone. > >> > >> Regards > >> > >> Leon > >> > >> > >> > >> _______________________________________________ > >> siprec mailing list > >> siprec@ietf.org > >> https://www.ietf.org/mailman/listinfo/siprec > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From john.elwell@siemens-enterprise.com Mon Apr 11 09:45:35 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5391028C12F for ; Mon, 11 Apr 2011 09:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.732 X-Spam-Level: X-Spam-Status: No, score=-103.732 tagged_above=-999 required=5 tests=[AWL=1.067, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tRRwszcVoN0v for ; Mon, 11 Apr 2011 09:45:33 -0700 (PDT) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by core3.amsl.com (Postfix) with SMTP id 631B93A68DC for ; Mon, 11 Apr 2011 09:45:32 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1302540329!22047633!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 4539 invoked from network); 11 Apr 2011 16:45:29 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-13.tower-27.messagelabs.com with SMTP; 11 Apr 2011 16:45:29 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id A58B31EB83D8; Mon, 11 Apr 2011 18:45:31 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 11 Apr 2011 18:45:31 +0200 From: "Elwell, John" To: "Parthasarathi R (partr)" , "Paul Kyzivat (pkyzivat)" , "siprec@ietf.org" Date: Mon, 11 Apr 2011 18:45:30 +0200 Thread-Topic: [siprec] Partial updates and identifiers Thread-Index: Acv0jVXI4ji2YTo+SquJ6T6YR3i+lQAdOkDgAEETmvAAg54qsAADKDEgAADSn+AAEAO1UA== Message-ID: References: <4D9CB8E1.7030402@cisco.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: "Peter Saint-Andre \(psaintan\)" , "Joe Hildebrand \(jhildebr\)" , Hadriel Kaplan Subject: Re: [siprec] Partial updates and identifiers X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 11 Apr 2011 16:45:35 -0000 Partha, Thanks for reminding me - I now recall the discussion some weeks/months ago= about the participants obtained from the conference event package. I was n= ever particularly comfortable with the fact these were not considered part = of the CS. While that might be correct if we consider the CS to be the SIP = dialog between the SRC and the conference focus, taking a broader view of C= S those participants behind the focus could be considered part of the CS. I= don't particularly want to open up the old discussion if people are happy = with what we have, but something doesn't seem quite right to me. For example, if these "participants" are not considered part of the CS, and= if we don't have specific information about their involvement in media str= eams, do they really merit being considered Participant objects? In other words, two possible approaches are: 1) The CS extends only as far as the focus / mixer. The focus/mixer is a "P= articipant" and the users behind the focus are not separate Participants bu= t are just additional data associated with the focus/mixer Participant. The= only Media Streams we are concerned with are between the mixer and the SRC= . 2) The CS extends beyond the focus/mixer to users learned via the conferenc= e event package, each of those users is a separate Participant object, and = we are concerned with Media Stream objects that those participants send and= receive. I am not sure how feasible this approach is, because I am not sur= e that the SRC can obtain enough information about media streams at users b= ehind the focus/mixer. It seems the present solution is somewhere between the two, which is why I = am uncomfortable. Regards, John (as individual) > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > Sent: 11 April 2011 10:29 > To: Elwell, John; Paul Kyzivat (pkyzivat); siprec@ietf.org > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe > Hildebrand (jhildebr) > Subject: RE: [siprec] Partial updates and identifiers > > John, > > Please read inline. > > Thanks > Partha > > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Monday, April 11, 2011 2:11 PM > To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); siprec@ietf.org > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe Hildebrand > (jhildebr) > Subject: RE: [siprec] Partial updates and identifiers > > > > > -----Original Message----- > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > Sent: 11 April 2011 08:35 > > To: Elwell, John; Paul Kyzivat (pkyzivat); siprec@ietf.org > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe Hildebrand > > (jhildebr) > > Subject: RE: [siprec] Partial updates and identifiers > > > > John, > > > > As I mentioned below, stream block will be unique within CS, (not > > required to be unique across multiple CS) and so, xml:id or > enhancing > > the normative statement of RFC 4574 label attribute to be unique > > within CS will serve the purpose. I'm fine with any of the above > > mentioned id. > > Please note that RFC 4574 "label" attribute is the nature > data for RS > > dialog. > > > > In case participant within CS, xml:id will serve the purpose but we > > need to get more clarity about participants who are not > part of CS but > > > within RS. > [JRE] If I understand the figure in section 3 of metadata-04 > correctly, > a Participant can have a relationship with a CS, but no direct > relationship with an RS. > > Sorry, I mixed up my statement with the latest > update of making > CSG optional. As per Sec 3 of metadata-04, participant has direct > relationship with CSG in case CS is left completely > unattached. In case > CSG is optional, then participant will have direct > relationship with RS > in case there is no relationship between CS and participant. > > > So a participant that does not have a relationship with a CS is left > completely unattached, unless it has a relationship with a > Media Stream > (which always has a relationship with a CS). So to summarize: > - a Participant can have a direct relationship with a CS; or > - a Participant can have an indirect relationship with a CS > (via a Media > Stream); > agreed > - a Participant can have no relationship with a CS, and therefore no > relationship with an RS. > Do we really need this last case? > > I'm happy if the last case is not required because > it simplify > the solution and there is no need of unique id for > participant. But SRS > implementers may prefer to have relationship with participant > and RS. I > wish more opinion before taking decision whether to remove > the last case > > > > Because CS may span across different RS how about the > participant who > > are not part of CS? > [JRE] I don't understand the words "Because CS may span > across different > RS", because in the rest of the sentence you are talking about a > Participant that is not part of a CS. > > > Ex: One of the user in the conference acts as SRC, fetch > participant > > info using conferene package and new RS is created during initial > > conference creation and hold&resume of a user within CS. > [JRE] I am not sure what you are trying to say here. I would > consider a > user whose identity is obtained via a conference event > package as being > part of the CS. > > I'm trying to give the example where participant is not > associated with CS directly but related to CSG (/RS). This > scenario was > considered as a blocking in -03 version of metadata. I'm not > arguing to > have this scenario but it is major concern for few folks. > > CS is between focus and UA, UA acts as SRC, UA receives the > participant > info via conference event package but those participants are > not related > in CS directly (and only focus is related) but they > contributed for the > mixed stream. > > That user is sending/receiving Media Streams that are part > of a CS, or > if it isn't sending/receiving Media Streams, what is the relevance of > that Participant? > > Mixed media stream from focus to UA belongs to the Conference > event package participants. There participant are not > directly involved > as part of CS. > Why would we create a new RS for such a participant? > RS is not created for participant. Multiple RS shall > be created > the same CS during the different time frame as shown below > > <-------------------CS1-------------> > <---RS1--> <---RS2------> > > CS1 is between UA (SRC) and focus whereas RS1, RS2 is between UA (SRC) > and SRS. Here tangling (conference event package) participant > has to be > grouped together in RS1, RS2 by some means through given metadata. The > question whether this corner has to be solved ? > > John (as individual) > > > > > > > Thanks > > Partha > > > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Friday, April 08, 2011 9:36 PM > > To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); > siprec@ietf.org > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe Hildebrand > > (jhildebr) > > Subject: RE: [siprec] Partial updates and identifiers > > > > Focusing just on participant and stream for the time being, > do these > > need to be unique across multiple CSs or not? > > > > John > > > > > -----Original Message----- > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > Sent: 07 April 2011 10:51 > > > To: Paul Kyzivat (pkyzivat); siprec@ietf.org; Elwell, John > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe Hildebrand > > > (jhildebr) > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > John, > > > > > > Sorry for the lengthy mail but it contains lot of analysis and > > > reasoning for this id approach. > > > > > > Adding to Paul's point, I wish to give more background and > > reason for > > > these globally unique id. Initially I had the impression that the > > > single unique id (RS dialog-id) in the recording (session > > level) and > > > some relevant natural id for the rest of the element will > serve the > > > purpose. > > > There are usecases where this assumption fails. Even I have > > thought of > > > > > using "xml:id" instead of URN UUID to avoid long string but > > xml:id may > > > > > not end up with unique value always. Our analysis for URN > UUID for > > > each level is as follows and please provide your input in case id > > > shall be > > > tweaked: > > > > > > 1) Recording block: The reason for globally unique id is > > that multiple > > > > > SRC with same id to single SRS. > > > > > > Topology: > > > > > > SRC1 SRC2 > > > | | > > > | ----(RS1-ID1)-----SRS1 > > > | > > > ---(RS2-ID1)------------------SRS1 > > > > > > In the above topology, it is possible for ID1 is generated by both > > > SRC1 and SRC2 at the same time. > > > > > > 2) group (CSG) block: Grouping mechanism (Hadriel > session-id, Paul > > > Jones > > > Session-UUID) is outside the scope of SIPREC. URN UUID > > abstracts the > > > exact mechanism to SRS and provides the information only > about the > > > group of CS from SRC perspective. It possible that group may span > > > across multiple RS and It is up to SRS to group and view > as single > > > recording. > > > Here, the single level id in the top will fail. The counter > > argument > > > is to force the single RS having complete CSG but it*may not* be > > > possible in SRC implementation. Here, xml:id will not serve the > > > purpose > > > > > > 3) session (CS) block: At the immediate look, session > falls exactly > > > under recording block. Use case 3 of draft-ietf-siprec-req-09 > > > illustrates where CS span across multiple RS. This > > requirement calls > > > for unique id in session by which these session shall be > viewed as > > > single CS even though there is no group exists among > them. IMO, in > > > case session should not have globally unique id, then it is > > preferred > > > to remove usecase 3 in the requirement. > > > > > > 4) participant block: It needs some id which may be AOR but > > AOR is not > > > > > unique. IMO, xml:id may serve the purpose with session > > unique id. The > > > trick exists for participant who are not associated with > > CS. We shall > > > discuss and fine tune if required. > > > > > > 5) stream block: Label attribute shall be used as unique > > value but RFC > > > 4574 does not mandate label attribute has to be unique across the > > > dialog or CS and so, it may possible to change within RS and no > > > normative statement to stop this implementation. IMO, > > xml:id may serve > > > > > the purpose with session unique id. Here as well, We shall > > discuss and > > > > > fine tune if required. > > > > > > 6) extensiondata block: This is tracked in the separate > mail thread > > > whether unique id is required or not. Let us close this > as part of > > > that mail thread. > > > > > > Including explicitly Hadriel, Peter, Joe in this mail > > thread as they > > > have different view on this ID mechanism. > > > > > > I had offline discussion with Hadriel in Prague after > > SIPREC meeting > > > and my understanding of his major concern is that how SRS > > will be able > > > > > to design the database in case partial update does not have > > recording > > > (top) id information. I'll put more thought processing to close > > > Hadriel concern of how top id has to be tracked in case > > partial update > > > > > by which SRS implementation will be simplified in terms of > > aggregation > > > > > maintenance. > > > > > > Thanks > > > Partha > > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > > (pkyzivat) > > > Sent: Thursday, April 07, 2011 12:33 AM > > > To: siprec@ietf.org > > > Subject: Re: [siprec] Partial updates and identifiers > > > > > > John, > > > > > > For the moment we have proposed that the ids be conveyed in > > the form > > > of URIs that are globally unique, and specifically that > > they be UUID > > > URNs. > > > There is no dependency on the particular form of the URI, but > > > specifying they must be UUID URNs makes it possible to > perform some > > > internal optimizations for storage. > > > > > > The UUID URN is a pretty inefficient encoding. A UUID can > > be expressed > > > > > in 32 bits, so we could consider retaining UUIDs but alter the > > > encoding if its really an issue. However I am far from > > convinced that > > > the size of the IDs is going to be a major issue in the > > overall size > > > of messages, so I think its probably premature to worry about it. > > > > > > Because the ids can be expressed in 32 bits, the SRC and > > SRS can store > > > > > them internally that way, thus reducing the runtime cost of > > > maintaining the data. > > > > > > The use of unique ids is a significant part of the overall > > approach to > > > > > formatting updates. If somebody has a different concept > in mind it > > > could be useful to have an alternative proposal for the > > format. If we > > > had two worked out approaches we could compare the > > tradeoffs in each. > > > > > > Thanks, > > > Paul > > > > > > On 4/6/2011 10:24 AM, Elwell, John wrote: > > > > Much of the discussion on draft-ram-metadata-format in Prague > > > concerned the mechanism for performing partial updates and > > the use of > > > identifiers. The draft permits partial updates by allowing > > individual > > > objects (e.g., CS, participant, media stream) to be sent > > with updated > > > content, without having to send again other objects that have not > > > changed. So, for example, in a large conference, it would > > be possible > > > to add or modify an individual participant object without > having to > > > send all the other participant objects again. I do not recall any > > > opposition to this basic principle. > > > > > > > > However, to achieve this, every object requires an > > > identifier, and it > > > was asserted that these identifiers need to be globally > > unique for all > > > > > time. Although this might be efficient for updating an individual > > > object, when sending many objects (e.g., at the start of a > > CS or when > > > refreshing the entire metadata), this can make the metadata very > > > bulky. > > > It depends, of course, on the format of the identifiers, > and it was > > > stated that there could be alternatives to UUID. > Nevertheless, some > > > people had concerns. These concerns also extended to the > > impact on the > > > > > database where metadata is stored, since it might not be > > feasible to > > > convert to a database-friendly mechanism for linking > > objects together. > > > > > > > > One alternative proposal during the meeting was to have a single > > > unique identifier at the top level (for the RS) and use local > > > identifiers for other objects. Thus when updating a single > > object, it > > > would be necessary to include the top level identifier as > > well as one > > > or more local identifiers. However, there were also concerns this > > > might not fulfil actual or perceived future requirements. > > > > > > > > Please continue discussion on this. > > > > > > > > John (as chair) > > > > _______________________________________________ > > > > siprec mailing list > > > > siprec@ietf.org > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > _______________________________________________ > > > siprec mailing list > > > siprec@ietf.org > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > From john.elwell@siemens-enterprise.com Mon Apr 11 09:45:45 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADABF28C147 for ; Mon, 11 Apr 2011 09:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.74 X-Spam-Level: X-Spam-Status: No, score=-101.74 tagged_above=-999 required=5 tests=[AWL=-0.941, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_46=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zLuIcQjvN-gX for ; Mon, 11 Apr 2011 09:45:44 -0700 (PDT) Received: from mail216.messagelabs.com (mail216.messagelabs.com [85.158.143.99]) by core3.amsl.com (Postfix) with SMTP id 540DF28C13F for ; Mon, 11 Apr 2011 09:45:43 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-6.tower-216.messagelabs.com!1302540342!1738453!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 13808 invoked from network); 11 Apr 2011 16:45:42 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-6.tower-216.messagelabs.com with SMTP; 11 Apr 2011 16:45:42 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id A4EDF23F03DB; Mon, 11 Apr 2011 18:45:42 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Mon, 11 Apr 2011 18:45:42 +0200 From: "Elwell, John" To: Leon Portman , "Parthasarathi R (partr)" , "Paul Kyzivat (pkyzivat)" , "siprec@ietf.org" Date: Mon, 11 Apr 2011 18:45:40 +0200 Thread-Topic: [siprec] Partial updates and identifiers Thread-Index: Acv0jVXI4ji2YTo+SquJ6T6YR3i+lQAdOkDgAEETmvAAg54qsAADKDEgAADSn+AACl0k8AAGR8sA Message-ID: References: <4D9CB8E1.7030402@cisco.com> <07465C1D981ABC41A344374066AE1A2C38AB6E1DFC@TLVMBX01.nice.com> In-Reply-To: <07465C1D981ABC41A344374066AE1A2C38AB6E1DFC@TLVMBX01.nice.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Peter Saint-Andre \(psaintan\)" , Hadriel Kaplan , "Joe Hildebrand \(jhildebr\)" Subject: Re: [siprec] Partial updates and identifiers X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 11 Apr 2011 16:45:45 -0000 Yes, I can see the case for an RS without a CS, but I think any participant= object should be associated with a CS (so when there is no CS there is no = participant). So even for the persistent recording case, we can keep the RS= alive, but why do we need to keep a participant object alive? John (as individual) > -----Original Message----- > From: Leon Portman [mailto:Leon.Portman@nice.com] > Sent: 11 April 2011 14:45 > To: Parthasarathi R (partr); Elwell, John; Paul Kyzivat > (pkyzivat); siprec@ietf.org > Cc: Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr); > Hadriel Kaplan > Subject: RE: [siprec] Partial updates and identifiers > > Hello > > As I have mentioned in another thread, we also have a use > case of persistent recording of specific participant (between > login/logout events for example), where participant will not > have media, CS or CSG and will be connected directly to RS. > > We will have m-lines with label in RS SDP and SRC will update > SRS with metadata with CS and media streams that point to > these labels per CS. > > Leon > > -----Original Message----- > From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi R (partr) > Sent: Monday, April 11, 2011 12:29 PM > To: Elwell, John; Paul Kyzivat (pkyzivat); siprec@ietf.org > Cc: Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr); > Hadriel Kaplan > Subject: Re: [siprec] Partial updates and identifiers > > John, > > Please read inline. > > Thanks > Partha > > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Monday, April 11, 2011 2:11 PM > To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); siprec@ietf.org > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe Hildebrand > (jhildebr) > Subject: RE: [siprec] Partial updates and identifiers > > > > > -----Original Message----- > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > Sent: 11 April 2011 08:35 > > To: Elwell, John; Paul Kyzivat (pkyzivat); siprec@ietf.org > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe Hildebrand > > (jhildebr) > > Subject: RE: [siprec] Partial updates and identifiers > > > > John, > > > > As I mentioned below, stream block will be unique within CS, (not > > required to be unique across multiple CS) and so, xml:id or > enhancing > > the normative statement of RFC 4574 label attribute to be unique > > within CS will serve the purpose. I'm fine with any of the above > > mentioned id. > > Please note that RFC 4574 "label" attribute is the nature > data for RS > > dialog. > > > > In case participant within CS, xml:id will serve the purpose but we > > need to get more clarity about participants who are not > part of CS but > > > within RS. > [JRE] If I understand the figure in section 3 of metadata-04 > correctly, a Participant can have a relationship with a CS, > but no direct relationship with an RS. > > Sorry, I mixed up my statement with the latest > update of making CSG optional. As per Sec 3 of metadata-04, > participant has direct relationship with CSG in case CS is > left completely unattached. In case CSG is optional, then > participant will have direct relationship with RS in case > there is no relationship between CS and participant. > > So a participant that does not have a relationship with a CS > is left completely unattached, unless it has a relationship > with a Media Stream (which always has a relationship with a > CS). So to summarize: > - a Participant can have a direct relationship with a CS; or > - a Participant can have an indirect relationship with a CS > (via a Media Stream); agreed > - a Participant can have no relationship with a CS, and > therefore no relationship with an RS. > Do we really need this last case? > > I'm happy if the last case is not required because > it simplify the solution and there is no need of unique id > for participant. But SRS implementers may prefer to have > relationship with participant and RS. I wish more opinion > before taking decision whether to remove the last case > > > Because CS may span across different RS how about the > participant who > > are not part of CS? > [JRE] I don't understand the words "Because CS may span > across different RS", because in the rest of the sentence you > are talking about a Participant that is not part of a CS. > > > Ex: One of the user in the conference acts as SRC, fetch > participant > > info using conferene package and new RS is created during initial > > conference creation and hold&resume of a user within CS. > [JRE] I am not sure what you are trying to say here. I would > consider a user whose identity is obtained via a conference > event package as being part of the CS. > > I'm trying to give the example where participant is > not associated with CS directly but related to CSG (/RS). > This scenario was considered as a blocking in -03 version of > metadata. I'm not arguing to have this scenario but it is > major concern for few folks. > > CS is between focus and UA, UA acts as SRC, UA receives the > participant info via conference event package but those > participants are not related in CS directly (and only focus > is related) but they contributed for the mixed stream. > > That user is sending/receiving Media Streams that are part > of a CS, or if it isn't sending/receiving Media Streams, what > is the relevance of that Participant? > > Mixed media stream from focus to UA belongs to the > Conference event package participants. There participant are > not directly involved as part of CS. Why would we > create a new RS for such a participant? > RS is not created for participant. Multiple RS shall > be created the same CS during the different time frame as shown below > > <-------------------CS1-------------> > <---RS1--> <---RS2------> > > CS1 is between UA (SRC) and focus whereas RS1, RS2 is between > UA (SRC) and SRS. Here tangling (conference event package) > participant has to be grouped together in RS1, RS2 by some > means through given metadata. The question whether this > corner has to be solved ? > > John (as individual) > > > > > > > Thanks > > Partha > > > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Friday, April 08, 2011 9:36 PM > > To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); > siprec@ietf.org > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe Hildebrand > > (jhildebr) > > Subject: RE: [siprec] Partial updates and identifiers > > > > Focusing just on participant and stream for the time being, > do these > > need to be unique across multiple CSs or not? > > > > John > > > > > -----Original Message----- > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > Sent: 07 April 2011 10:51 > > > To: Paul Kyzivat (pkyzivat); siprec@ietf.org; Elwell, John > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe Hildebrand > > > (jhildebr) > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > John, > > > > > > Sorry for the lengthy mail but it contains lot of analysis and > > > reasoning for this id approach. > > > > > > Adding to Paul's point, I wish to give more background and > > reason for > > > these globally unique id. Initially I had the impression that the > > > single unique id (RS dialog-id) in the recording (session > > level) and > > > some relevant natural id for the rest of the element will > serve the > > > purpose. > > > There are usecases where this assumption fails. Even I have > > thought of > > > > > using "xml:id" instead of URN UUID to avoid long string but > > xml:id may > > > > > not end up with unique value always. Our analysis for URN > UUID for > > > each level is as follows and please provide your input in case id > > > shall be > > > tweaked: > > > > > > 1) Recording block: The reason for globally unique id is > > that multiple > > > > > SRC with same id to single SRS. > > > > > > Topology: > > > > > > SRC1 SRC2 > > > | | > > > | ----(RS1-ID1)-----SRS1 > > > | > > > ---(RS2-ID1)------------------SRS1 > > > > > > In the above topology, it is possible for ID1 is generated by both > > > SRC1 and SRC2 at the same time. > > > > > > 2) group (CSG) block: Grouping mechanism (Hadriel > session-id, Paul > > > Jones > > > Session-UUID) is outside the scope of SIPREC. URN UUID > > abstracts the > > > exact mechanism to SRS and provides the information only > about the > > > group of CS from SRC perspective. It possible that group may span > > > across multiple RS and It is up to SRS to group and view > as single > > > recording. > > > Here, the single level id in the top will fail. The counter > > argument > > > is to force the single RS having complete CSG but it*may not* be > > > possible in SRC implementation. Here, xml:id will not serve the > > > purpose > > > > > > 3) session (CS) block: At the immediate look, session > falls exactly > > > under recording block. Use case 3 of draft-ietf-siprec-req-09 > > > illustrates where CS span across multiple RS. This > > requirement calls > > > for unique id in session by which these session shall be > viewed as > > > single CS even though there is no group exists among > them. IMO, in > > > case session should not have globally unique id, then it is > > preferred > > > to remove usecase 3 in the requirement. > > > > > > 4) participant block: It needs some id which may be AOR but > > AOR is not > > > > > unique. IMO, xml:id may serve the purpose with session > > unique id. The > > > trick exists for participant who are not associated with > > CS. We shall > > > discuss and fine tune if required. > > > > > > 5) stream block: Label attribute shall be used as unique > > value but RFC > > > 4574 does not mandate label attribute has to be unique across the > > > dialog or CS and so, it may possible to change within RS and no > > > normative statement to stop this implementation. IMO, > > xml:id may serve > > > > > the purpose with session unique id. Here as well, We shall > > discuss and > > > > > fine tune if required. > > > > > > 6) extensiondata block: This is tracked in the separate > mail thread > > > whether unique id is required or not. Let us close this > as part of > > > that mail thread. > > > > > > Including explicitly Hadriel, Peter, Joe in this mail > > thread as they > > > have different view on this ID mechanism. > > > > > > I had offline discussion with Hadriel in Prague after > > SIPREC meeting > > > and my understanding of his major concern is that how SRS > > will be able > > > > > to design the database in case partial update does not have > > recording > > > (top) id information. I'll put more thought processing to close > > > Hadriel concern of how top id has to be tracked in case > > partial update > > > > > by which SRS implementation will be simplified in terms of > > aggregation > > > > > maintenance. > > > > > > Thanks > > > Partha > > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > > (pkyzivat) > > > Sent: Thursday, April 07, 2011 12:33 AM > > > To: siprec@ietf.org > > > Subject: Re: [siprec] Partial updates and identifiers > > > > > > John, > > > > > > For the moment we have proposed that the ids be conveyed in > > the form > > > of URIs that are globally unique, and specifically that > > they be UUID > > > URNs. > > > There is no dependency on the particular form of the URI, but > > > specifying they must be UUID URNs makes it possible to > perform some > > > internal optimizations for storage. > > > > > > The UUID URN is a pretty inefficient encoding. A UUID can > > be expressed > > > > > in 32 bits, so we could consider retaining UUIDs but alter the > > > encoding if its really an issue. However I am far from > > convinced that > > > the size of the IDs is going to be a major issue in the > > overall size > > > of messages, so I think its probably premature to worry about it. > > > > > > Because the ids can be expressed in 32 bits, the SRC and > > SRS can store > > > > > them internally that way, thus reducing the runtime cost of > > > maintaining the data. > > > > > > The use of unique ids is a significant part of the overall > > approach to > > > > > formatting updates. If somebody has a different concept > in mind it > > > could be useful to have an alternative proposal for the > > format. If we > > > had two worked out approaches we could compare the > > tradeoffs in each. > > > > > > Thanks, > > > Paul > > > > > > On 4/6/2011 10:24 AM, Elwell, John wrote: > > > > Much of the discussion on draft-ram-metadata-format in Prague > > > concerned the mechanism for performing partial updates and > > the use of > > > identifiers. The draft permits partial updates by allowing > > individual > > > objects (e.g., CS, participant, media stream) to be sent > > with updated > > > content, without having to send again other objects that have not > > > changed. So, for example, in a large conference, it would > > be possible > > > to add or modify an individual participant object without > having to > > > send all the other participant objects again. I do not recall any > > > opposition to this basic principle. > > > > > > > > However, to achieve this, every object requires an > > > identifier, and it > > > was asserted that these identifiers need to be globally > > unique for all > > > > > time. Although this might be efficient for updating an individual > > > object, when sending many objects (e.g., at the start of a > > CS or when > > > refreshing the entire metadata), this can make the metadata very > > > bulky. > > > It depends, of course, on the format of the identifiers, > and it was > > > stated that there could be alternatives to UUID. > Nevertheless, some > > > people had concerns. These concerns also extended to the > > impact on the > > > > > database where metadata is stored, since it might not be > > feasible to > > > convert to a database-friendly mechanism for linking > > objects together. > > > > > > > > One alternative proposal during the meeting was to have a single > > > unique identifier at the top level (for the RS) and use local > > > identifiers for other objects. Thus when updating a single > > object, it > > > would be necessary to include the top level identifier as > > well as one > > > or more local identifiers. However, there were also concerns this > > > might not fulfil actual or perceived future requirements. > > > > > > > > Please continue discussion on this. > > > > > > > > John (as chair) > > > > _______________________________________________ > > > > siprec mailing list > > > > siprec@ietf.org > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > _______________________________________________ > > > siprec mailing list > > > siprec@ietf.org > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From john.elwell@siemens-enterprise.com Mon Apr 11 09:52:09 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B58C83A6B25 for ; Mon, 11 Apr 2011 09:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.633 X-Spam-Level: X-Spam-Status: No, score=-104.633 tagged_above=-999 required=5 tests=[AWL=1.966, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wxfla1BXZeL2 for ; Mon, 11 Apr 2011 09:52:08 -0700 (PDT) Received: from mail174.messagelabs.com (mail174.messagelabs.com [85.158.138.51]) by core3.amsl.com (Postfix) with SMTP id 6246B3A6A72 for ; Mon, 11 Apr 2011 09:52:08 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1302540727!16745806!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 21091 invoked from network); 11 Apr 2011 16:52:07 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-12.tower-174.messagelabs.com with SMTP; 11 Apr 2011 16:52:07 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id BEDF923F03DF; Mon, 11 Apr 2011 18:52:07 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 11 Apr 2011 18:52:07 +0200 From: "Elwell, John" To: Leon Portman , Paul Kyzivat , "siprec@ietf.org" Date: Mon, 11 Apr 2011 18:52:05 +0200 Thread-Topic: [siprec] metadata model and persisent recording Thread-Index: Acv4XTAKi/ZJFIEdSLCuZF2ohpHgHAAAPlDgAAKLluA= Message-ID: References: <07465C1D981ABC41A344374066AE1A2C38AB6E1DC4@TLVMBX01.nice.com> <4DA31E2C.6080008@cisco.com> <07465C1D981ABC41A344374066AE1A2C38AB6E1E75@TLVMBX01.nice.com> In-Reply-To: <07465C1D981ABC41A344374066AE1A2C38AB6E1E75@TLVMBX01.nice.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] metadata model and persisent recording X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 11 Apr 2011 16:52:09 -0000 Perhaps this is an attribute of the RS metadata object (let's call it the "= target" attribute, i.e., the target of recording) rather than a participant= . When a CS starts, one of the participant objects associated with the CS w= ill happen to match the target. John (as individual) > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Leon Portman > Sent: 11 April 2011 16:37 > To: Paul Kyzivat; siprec@ietf.org > Subject: Re: [siprec] metadata model and persisent recording >=20 > Actually yes, because it is common for persistent session=20 > that SRS channel are predefined per DN (participant) >=20 > Leon >=20 > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Monday, April 11, 2011 6:29 PM > To: siprec@ietf.org > Subject: Re: [siprec] metadata model and persisent recording >=20 > Leon, >=20 > Is it important that a persistent RS identify a participant=20 > when there is no CS? Isn't it sufficient to identify the=20 > participant at the time the CS is reported? >=20 > Thanks, > Paul >=20 > On 4/11/2011 9:24 AM, Leon Portman wrote: > > Partha Hi > > > > I think we are missing in the metadata model support for persistent=20 > > recording mode, where RS INVITE may be sent from SRC to SRC with=20 > > participant info but without any communication session or=20 > group. For=20 > > example where RS will be established when somebody logins=20 > to the phone. > > > > Regards > > > > Leon > > > > > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > = From pkyzivat@cisco.com Mon Apr 11 10:05:56 2011 Return-Path: X-Original-To: siprec@core3.amsl.com Delivered-To: siprec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04D353A6938 for ; Mon, 11 Apr 2011 10:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.527 X-Spam-Level: X-Spam-Status: No, score=-110.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06IbkdD9YCtM for ; Mon, 11 Apr 2011 10:05:54 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 4C7E53A68DC for ; Mon, 11 Apr 2011 10:05:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=7717; q=dns/txt; s=iport; t=1302541555; x=1303751155; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=KkdIWHkv+/bRzbLoJkp8/fN4UGPgGp4oJeXD+L0xthA=; b=RrYBuJQjkGFxESGWKrCw+jKfASPzI3CLzcmm8D7zcysQHrLuPvTZOWen KWhNZaarJfkDOEH9g5bfH1M6w5jv9TA8GWMTENcGHFuCbZndhwtve5EP4 ocdhjATag7rknXzlPILiypJpTvEg8EEfm1kSvPQFx5DIezZZ/iybqjbSa E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYBAL8zo02tJXG+/2dsb2JhbACYQo1bd4h6nlScGYVuBI1Yg2o X-IronPort-AV: E=Sophos;i="4.63,339,1299456000"; d="scan'208";a="293831996" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by sj-iport-3.cisco.com with ESMTP; 11 Apr 2011 17:05:53 +0000 Received: from [161.44.174.125] (dhcp-161-44-174-125.cisco.com [161.44.174.125]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3BH5rpu003537; Mon, 11 Apr 2011 17:05:53 GMT Message-ID: <4DA334F0.9050301@cisco.com> Date: Mon, 11 Apr 2011 13:05:52 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Leon Portman References: <4D9CDADD.1020403@cisco.com> <4DA2FC17.1060100@cisco.com> <07465C1D981ABC41A344374066AE1A2C38AB6E1DE4@TLVMBX01.nice.com> In-Reply-To: <07465C1D981ABC41A344374066AE1A2C38AB6E1DE4@TLVMBX01.nice.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "siprec@ietf.org" Subject: Re: [siprec] start/stop times & the metamodel X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.9 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, 11 Apr 2011 17:05:56 -0000 On 4/11/2011 9:36 AM, Leon Portman wrote: > Paul Hi > > I agree with proposed method of time stamping metadata elements with SRC clock (it is like a wall clock from the requirement document). > About RTP time synchronization to metadata events, we either should have some low latency event from SRC to SRS with SRC time that will allow SRS to maintain time difference between its clock and SRC clock and then apply it also to receive time of RTP packet (assuming no buffering) ISTM the issue isn't the latency of the event - it is what it is - but rather how to correlate a sip message containing metadata with a particular RTP packet. I suspect that needs to be tied into the discussion of the various models for how the SRC might handle RDP. Thanks, Paul > Leon > > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Monday, April 11, 2011 4:03 PM > To: Elwell, John > Cc: siprec@ietf.org > Subject: Re: [siprec] start/stop times& the metamodel > > > > On 4/8/2011 11:53 AM, Elwell, John wrote: >> Paul, >> >> I think much of what you say makes sense. I was concerned that we probably need to record when a participant stops or starts sending or receiving a stream, which seems to be covered by your statement: "Changes to media streams should similarly be tagged with the time they occurred in the CS signaling. Each participant relationship change (send, receive, inactive,) will be there." That doesn't seem to be in the model at present. > > John, > > I agree the current model doesn't reflect this - it was a private thought by me, provoked by the work and discussion to date. It is a bit of a change of direction, so I'm interested in what others think about it. > > Thanks, > Paul > >> John (as individual) >> >> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org >>> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat >>> Sent: 06 April 2011 22:28 >>> To: siprec@ietf.org >>> Subject: [siprec] start/stop times& the metamodel >>> >>> In Prague, one of the open issues was around start/stop times. The >>> format draft floated the possibility of having explicit start/stop >>> times signaled for each of the metatdata elements. But then we asked >>> for feedback on which make sense. >>> >>> IMO explicit start/stop times make more sense for some things than >>> others. >>> >>> One place where we potentially have explicit times to report with the >>> dialogs that constitute a CS. Each such dialog presumably has a start >>> and stop time observable by the SRC, which might differ, at least a >>> bit, from the corresponding signaling on the RS. >>> >>> We might want to report those times. Or, since we abstract the CS >>> away from the dialog, we might want to report the start time of the >>> first dialog in the CS as the CS start time, and the stop time of the >>> last dialog in the CS as the CS stop time. >>> >>> Similarly, we have abstracted media streams away from the media >>> streams in the sip dialogs that make up the CS. We might want to >>> report the start time of a media stream as the time (according to the >>> CS) of the first participant to a new media stream, and the stop time >>> as the time that the last participant leaves the media stream. >>> >>> There are several things that complicate this: >>> >>> - Do we consider the case of a stream that starts with recvonly >>> or inactive participants, and only later gets a sender? If so, >>> is the start time of the stream when the first participant arrived, >>> or when the first sender arrived? >>> >>> - How do we get the clock times for the media streams? >>> IIUC the correct ones are in the RTP/RTCP, but the reporting of >>> these events is driven by the signaling, and we don't have good >>> sync between those. (E.g. media could start flowing before the >>> corresponding signaling, and we would like to include that if we >>> can figure it out.) So, even if the clocks used for media and >>> signaling are in sync, we might see media packets arrive with >>> a timestamp prior to the timestamp for the signaling that >>> indicates the send state of the participant. This could cause >>> trouble in playback. >>> >>> - There isn't any guarantee that the clock used for signaling >>> messages is synchronized with the clock used in RTP/RTCP. >>> >>> - There isn't any guarantee that there will be any RTCP at all, >>> to provide correlation of the RTP to clocktime. >>> >>> The best I can see to deal with all of this is: >>> >>> - All the metadata messages should be timestamped by the SRC >>> using its local clock. This is easily achieved by the Date >>> header in the sip message. >>> >>> - Changes to a CS, including changes of participants, should >>> be explicitly tagged with the time they occurred in the >>> CS signaling, according to the SRC's clock. (If that is >>> unavailable for some reason, then use the time the SRC >>> became aware of it.) >>> >>> - We could provide a metadata update element to indicate end >>> of a CS, but I suggest this just be shorthand for indicating >>> removal of all participants from it. (While its possible to >>> mark that the CS is truly ended, that simply introduces an >>> error case if added metadata about it is subsequently sent.) >>> The actual start/stop time would be determined by the SRS >>> based on the timestamps of first and last data about it. >>> >>> - Changes to media streams should similarly be tagged with >>> the time they occurred in the CS signaling. Each participant >>> relationship change (send, receive, inactive,) will be there. >>> The actual start/stop time of the media stream again would be >>> derived by the SRS. >>> >>> - CS-Groups can simply be tagged by the timestamps of the >>> updates that put CSs into them. Explicit start/stop times don't >>> seem useful. If desired, the SRS can derive start/stop times >>> from the start/stop times of the contained stuff. >>> >>> - I now think that CS-Groups should not be "contained" within >>> a recording. This just seems to introduce unnecessary error >>> conditions, and limitations on future enhancements. The >>> lifetime of CS-Groups will probably be naturally limited by >>> the ability of the SRC to remember the IDs of old ones. >>> For instance, if a CS-G is created during one Recording, >>> and then another CS is added to it from a different recording >>> session, would we prefer to fail that, or just allow it? >>> (I think allow.) >>> >>> - Rather, I think every update transmitted during a recording >>> session can be tagged with a link to the metadata of the >>> recording session it came from. This need not be explicit - the >>> SRS can do it automatically. The recording session entity >>> itself will also have a start/stop time which is the start/ >>> stop of the RS dialog as observed by the SRS. >>> >>> (Note the above doesn't solve the problem of getting correct clock >>> times for RTP media. If anyone has a suggestion for this I'm all >>> ears.) >>> >>> Thanks, >>> Paul >>> _______________________________________________ >>> siprec mailing list >>> siprec@ietf.org >>> https://www.ietf.org/mailman/listinfo/siprec >>> > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From Henry.Lum@alcatel-lucent.com Mon Apr 11 15:15:47 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 089E6E0672 for ; Mon, 11 Apr 2011 15:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=1.250, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TI22l4MJP4DM for ; Mon, 11 Apr 2011 15:15:45 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfc.amsl.com (Postfix) with ESMTP id 31A2DE066F for ; Mon, 11 Apr 2011 15:15:41 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p3BKWQ8p011065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 11 Apr 2011 15:32:27 -0500 (CDT) Received: from relay-out1.wc.genesyslab.com (relay-out1.wc.genesyslab.com [172.22.70.114]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p3BKWO2Q031716 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 11 Apr 2011 15:32:26 -0500 Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out1.wc.genesyslab.com (8.13.8+Sun/8.13.8) with ESMTP id p3BKWODc013566; Mon, 11 Apr 2011 13:32:24 -0700 (PDT) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.93]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 11 Apr 2011 13:32:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: K6WT LAiP OeQt Vgt0 fyZP ounM rz7V sel1 sosR vQ+m xE/8 xvWf 2wlw AAIv2Q== AAfNNA== ABELRQ==; 8; aABrAGEAcABsAGEAbgBAAGEAYwBtAGUAcABhAGMAawBlAHQALgBjAG8AbQA7AGoAaABpAGwAZABlAGIAcgBAAGMAaQBzAGMAbwAuAGMAbwBtADsAagBvAGgAbgAuAGUAbAB3AGUAbABsAEAAcwBpAGUAbQBlAG4AcwAtAGUAbgB0AGUAcgBwAHIAaQBzAGUALgBjAG8AbQA7AGwAZQBvAG4ALgBwAG8AcgB0AG0AYQBuAEAAbgBpAGMAZQAuAGMAbwBtADsAcABhAHIAdAByAEAAYwBpAHMAYwBvAC4AYwBvAG0AOwBwAGsAeQB6AGkAdgBhAHQAQABjAGkAcwBjAG8ALgBjAG8AbQA7AHAAcwBhAGkAbgB0AGEAbgBAAGMAaQBzAGMAbwAuAGMAbwBtADsAcwBpAHAAcgBlAGMAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {A6B788D9-23EA-4823-9184-B2F37C6588D3}; aABlAG4AcgB5AC4AbAB1AG0AQABnAGUAbgBlAHMAeQBzAGwAYQBiAC4AYwBvAG0A; Mon, 11 Apr 2011 20:32:10 GMT; UgBFADoAIABbAHMAaQBwAHIAZQBjAF0AIABQAGEAcgB0AGkAYQBsACAAdQBwAGQAYQB0AGUAcwAgAGEAbgBkACAAaQBkAGUAbgB0AGkAZgBpAGUAcgBzAA== MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {A6B788D9-23EA-4823-9184-B2F37C6588D3} Content-class: urn:content-classes:message Date: Mon, 11 Apr 2011 13:32:10 -0700 Message-ID: <059AF07365DC474393A19A3AF187DF7406E67C8E@NAHALD.us.int.genesyslab.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Partial updates and identifiers Thread-Index: Acv0jVXI4ji2YTo+SquJ6T6YR3i+lQAdOkDgAEETmvAAg54qsAADKDEgAADSn+AACl0k8AAGR8sAAAeUfZA= References: <4D9CB8E1.7030402@cisco.com><07465C1D981ABC41A344374066AE1A2C38AB6E1DFC@TLVMBX01.nice.com> From: "Henry Lum" To: "Elwell, John" , "Leon Portman" , "Parthasarathi R (partr)" , "Paul Kyzivat (pkyzivat)" , X-OriginalArrivalTime: 11 Apr 2011 20:32:23.0303 (UTC) FILETIME=[90286170:01CBF887] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: "Peter Saint-Andre \(psaintan\)" , "Joe Hildebrand\(jhildebr\)" Subject: Re: [siprec] Partial updates and identifiers X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 11 Apr 2011 22:15:47 -0000 I am having trouble understanding why we would have a participant with no association to a CS. I get the impression that we call the terminology a participant because it is a participant of a CS. For the use case of agent login/logout, would this belong to extension data of a recording session rather than modeling it as a participant with/without a CS since there is no call anyways? Henry > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Elwell, John > Sent: Monday, April 11, 2011 12:46 PM > To: Leon Portman; Parthasarathi R (partr); Paul Kyzivat (pkyzivat); > siprec@ietf.org > Cc: Peter Saint-Andre (psaintan); Hadriel Kaplan; Joe > Hildebrand(jhildebr) > Subject: Re: [siprec] Partial updates and identifiers >=20 > Yes, I can see the case for an RS without a CS, but I think any > participant object should be associated with a CS (so when there is no > CS there is no participant). So even for the persistent recording case, > we can keep the RS alive, but why do we need to keep a participant > object alive? >=20 > John (as individual) >=20 > > -----Original Message----- > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > Sent: 11 April 2011 14:45 > > To: Parthasarathi R (partr); Elwell, John; Paul Kyzivat > > (pkyzivat); siprec@ietf.org > > Cc: Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr); > > Hadriel Kaplan > > Subject: RE: [siprec] Partial updates and identifiers > > > > Hello > > > > As I have mentioned in another thread, we also have a use > > case of persistent recording of specific participant (between > > login/logout events for example), where participant will not > > have media, CS or CSG and will be connected directly to RS. > > > > We will have m-lines with label in RS SDP and SRC will update > > SRS with metadata with CS and media streams that point to > > these labels per CS. > > > > Leon > > > > -----Original Message----- > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi R (partr) > > Sent: Monday, April 11, 2011 12:29 PM > > To: Elwell, John; Paul Kyzivat (pkyzivat); siprec@ietf.org > > Cc: Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr); > > Hadriel Kaplan > > Subject: Re: [siprec] Partial updates and identifiers > > > > John, > > > > Please read inline. > > > > Thanks > > Partha > > > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Monday, April 11, 2011 2:11 PM > > To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); siprec@ietf.org > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe Hildebrand > > (jhildebr) > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > > > > -----Original Message----- > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > Sent: 11 April 2011 08:35 > > > To: Elwell, John; Paul Kyzivat (pkyzivat); siprec@ietf.org > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe Hildebrand > > > (jhildebr) > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > John, > > > > > > As I mentioned below, stream block will be unique within CS, (not > > > required to be unique across multiple CS) and so, xml:id or > > enhancing > > > the normative statement of RFC 4574 label attribute to be unique > > > within CS will serve the purpose. I'm fine with any of the above > > > mentioned id. > > > Please note that RFC 4574 "label" attribute is the nature > > data for RS > > > dialog. > > > > > > In case participant within CS, xml:id will serve the purpose but we > > > need to get more clarity about participants who are not > > part of CS but > > > > > within RS. > > [JRE] If I understand the figure in section 3 of metadata-04 > > correctly, a Participant can have a relationship with a CS, > > but no direct relationship with an RS. > > > > Sorry, I mixed up my statement with the latest > > update of making CSG optional. As per Sec 3 of metadata-04, > > participant has direct relationship with CSG in case CS is > > left completely unattached. In case CSG is optional, then > > participant will have direct relationship with RS in case > > there is no relationship between CS and participant. > > > > So a participant that does not have a relationship with a CS > > is left completely unattached, unless it has a relationship > > with a Media Stream (which always has a relationship with a > > CS). So to summarize: > > - a Participant can have a direct relationship with a CS; or > > - a Participant can have an indirect relationship with a CS > > (via a Media Stream); agreed > > - a Participant can have no relationship with a CS, and > > therefore no relationship with an RS. > > Do we really need this last case? > > > > I'm happy if the last case is not required because > > it simplify the solution and there is no need of unique id > > for participant. But SRS implementers may prefer to have > > relationship with participant and RS. I wish more opinion > > before taking decision whether to remove the last case > > > > > Because CS may span across different RS how about the > > participant who > > > are not part of CS? > > [JRE] I don't understand the words "Because CS may span > > across different RS", because in the rest of the sentence you > > are talking about a Participant that is not part of a CS. > > > > > Ex: One of the user in the conference acts as SRC, fetch > > participant > > > info using conferene package and new RS is created during initial > > > conference creation and hold&resume of a user within CS. > > [JRE] I am not sure what you are trying to say here. I would > > consider a user whose identity is obtained via a conference > > event package as being part of the CS. > > > > I'm trying to give the example where participant is > > not associated with CS directly but related to CSG (/RS). > > This scenario was considered as a blocking in -03 version of > > metadata. I'm not arguing to have this scenario but it is > > major concern for few folks. > > > > CS is between focus and UA, UA acts as SRC, UA receives the > > participant info via conference event package but those > > participants are not related in CS directly (and only focus > > is related) but they contributed for the mixed stream. > > > > That user is sending/receiving Media Streams that are part > > of a CS, or if it isn't sending/receiving Media Streams, what > > is the relevance of that Participant? > > > > Mixed media stream from focus to UA belongs to the > > Conference event package participants. There participant are > > not directly involved as part of CS. Why would we > > create a new RS for such a participant? > > RS is not created for participant. Multiple RS shall > > be created the same CS during the different time frame as shown below > > > > <-------------------CS1-------------> > > <---RS1--> <---RS2------> > > > > CS1 is between UA (SRC) and focus whereas RS1, RS2 is between > > UA (SRC) and SRS. Here tangling (conference event package) > > participant has to be grouped together in RS1, RS2 by some > > means through given metadata. The question whether this > > corner has to be solved ? > > > > John (as individual) > > > > > > > > > > > > Thanks > > > Partha > > > > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > Sent: Friday, April 08, 2011 9:36 PM > > > To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); > > siprec@ietf.org > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe Hildebrand > > > (jhildebr) > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > Focusing just on participant and stream for the time being, > > do these > > > need to be unique across multiple CSs or not? > > > > > > John > > > > > > > -----Original Message----- > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > Sent: 07 April 2011 10:51 > > > > To: Paul Kyzivat (pkyzivat); siprec@ietf.org; Elwell, John > > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe Hildebrand > > > > (jhildebr) > > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > > > John, > > > > > > > > Sorry for the lengthy mail but it contains lot of analysis and > > > > reasoning for this id approach. > > > > > > > > Adding to Paul's point, I wish to give more background and > > > reason for > > > > these globally unique id. Initially I had the impression that the > > > > single unique id (RS dialog-id) in the recording (session > > > level) and > > > > some relevant natural id for the rest of the element will > > serve the > > > > purpose. > > > > There are usecases where this assumption fails. Even I have > > > thought of > > > > > > > using "xml:id" instead of URN UUID to avoid long string but > > > xml:id may > > > > > > > not end up with unique value always. Our analysis for URN > > UUID for > > > > each level is as follows and please provide your input in case id > > > > shall be > > > > tweaked: > > > > > > > > 1) Recording block: The reason for globally unique id is > > > that multiple > > > > > > > SRC with same id to single SRS. > > > > > > > > Topology: > > > > > > > > SRC1 SRC2 > > > > | | > > > > | ----(RS1-ID1)-----SRS1 > > > > | > > > > ---(RS2-ID1)------------------SRS1 > > > > > > > > In the above topology, it is possible for ID1 is generated by > both > > > > SRC1 and SRC2 at the same time. > > > > > > > > 2) group (CSG) block: Grouping mechanism (Hadriel > > session-id, Paul > > > > Jones > > > > Session-UUID) is outside the scope of SIPREC. URN UUID > > > abstracts the > > > > exact mechanism to SRS and provides the information only > > about the > > > > group of CS from SRC perspective. It possible that group may span > > > > across multiple RS and It is up to SRS to group and view > > as single > > > > recording. > > > > Here, the single level id in the top will fail. The counter > > > argument > > > > is to force the single RS having complete CSG but it*may not* be > > > > possible in SRC implementation. Here, xml:id will not serve the > > > > purpose > > > > > > > > 3) session (CS) block: At the immediate look, session > > falls exactly > > > > under recording block. Use case 3 of draft-ietf-siprec-req-09 > > > > illustrates where CS span across multiple RS. This > > > requirement calls > > > > for unique id in session by which these session shall be > > viewed as > > > > single CS even though there is no group exists among > > them. IMO, in > > > > case session should not have globally unique id, then it is > > > preferred > > > > to remove usecase 3 in the requirement. > > > > > > > > 4) participant block: It needs some id which may be AOR but > > > AOR is not > > > > > > > unique. IMO, xml:id may serve the purpose with session > > > unique id. The > > > > trick exists for participant who are not associated with > > > CS. We shall > > > > discuss and fine tune if required. > > > > > > > > 5) stream block: Label attribute shall be used as unique > > > value but RFC > > > > 4574 does not mandate label attribute has to be unique across the > > > > dialog or CS and so, it may possible to change within RS and no > > > > normative statement to stop this implementation. IMO, > > > xml:id may serve > > > > > > > the purpose with session unique id. Here as well, We shall > > > discuss and > > > > > > > fine tune if required. > > > > > > > > 6) extensiondata block: This is tracked in the separate > > mail thread > > > > whether unique id is required or not. Let us close this > > as part of > > > > that mail thread. > > > > > > > > Including explicitly Hadriel, Peter, Joe in this mail > > > thread as they > > > > have different view on this ID mechanism. > > > > > > > > I had offline discussion with Hadriel in Prague after > > > SIPREC meeting > > > > and my understanding of his major concern is that how SRS > > > will be able > > > > > > > to design the database in case partial update does not have > > > recording > > > > (top) id information. I'll put more thought processing to close > > > > Hadriel concern of how top id has to be tracked in case > > > partial update > > > > > > > by which SRS implementation will be simplified in terms of > > > aggregation > > > > > > > maintenance. > > > > > > > > Thanks > > > > Partha > > > > > > > > -----Original Message----- > > > > From: siprec-bounces@ietf.org > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > > > (pkyzivat) > > > > Sent: Thursday, April 07, 2011 12:33 AM > > > > To: siprec@ietf.org > > > > Subject: Re: [siprec] Partial updates and identifiers > > > > > > > > John, > > > > > > > > For the moment we have proposed that the ids be conveyed in > > > the form > > > > of URIs that are globally unique, and specifically that > > > they be UUID > > > > URNs. > > > > There is no dependency on the particular form of the URI, but > > > > specifying they must be UUID URNs makes it possible to > > perform some > > > > internal optimizations for storage. > > > > > > > > The UUID URN is a pretty inefficient encoding. A UUID can > > > be expressed > > > > > > > in 32 bits, so we could consider retaining UUIDs but alter the > > > > encoding if its really an issue. However I am far from > > > convinced that > > > > the size of the IDs is going to be a major issue in the > > > overall size > > > > of messages, so I think its probably premature to worry about it. > > > > > > > > Because the ids can be expressed in 32 bits, the SRC and > > > SRS can store > > > > > > > them internally that way, thus reducing the runtime cost of > > > > maintaining the data. > > > > > > > > The use of unique ids is a significant part of the overall > > > approach to > > > > > > > formatting updates. If somebody has a different concept > > in mind it > > > > could be useful to have an alternative proposal for the > > > format. If we > > > > had two worked out approaches we could compare the > > > tradeoffs in each. > > > > > > > > Thanks, > > > > Paul > > > > > > > > On 4/6/2011 10:24 AM, Elwell, John wrote: > > > > > Much of the discussion on draft-ram-metadata-format in Prague > > > > concerned the mechanism for performing partial updates and > > > the use of > > > > identifiers. The draft permits partial updates by allowing > > > individual > > > > objects (e.g., CS, participant, media stream) to be sent > > > with updated > > > > content, without having to send again other objects that have not > > > > changed. So, for example, in a large conference, it would > > > be possible > > > > to add or modify an individual participant object without > > having to > > > > send all the other participant objects again. I do not recall any > > > > opposition to this basic principle. > > > > > > > > > > However, to achieve this, every object requires an > > > > identifier, and it > > > > was asserted that these identifiers need to be globally > > > unique for all > > > > > > > time. Although this might be efficient for updating an individual > > > > object, when sending many objects (e.g., at the start of a > > > CS or when > > > > refreshing the entire metadata), this can make the metadata very > > > > bulky. > > > > It depends, of course, on the format of the identifiers, > > and it was > > > > stated that there could be alternatives to UUID. > > Nevertheless, some > > > > people had concerns. These concerns also extended to the > > > impact on the > > > > > > > database where metadata is stored, since it might not be > > > feasible to > > > > convert to a database-friendly mechanism for linking > > > objects together. > > > > > > > > > > One alternative proposal during the meeting was to have a > single > > > > unique identifier at the top level (for the RS) and use local > > > > identifiers for other objects. Thus when updating a single > > > object, it > > > > would be necessary to include the top level identifier as > > > well as one > > > > or more local identifiers. However, there were also concerns this > > > > might not fulfil actual or perceived future requirements. > > > > > > > > > > Please continue discussion on this. > > > > > > > > > > John (as chair) > > > > > _______________________________________________ > > > > > siprec mailing list > > > > > siprec@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > > _______________________________________________ > > > > siprec mailing list > > > > siprec@ietf.org > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > > _______________________________________________ > > siprec mailing 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 sorton@broadsoft.com Mon Apr 11 15:16:05 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BDB20E0677 for ; Mon, 11 Apr 2011 15:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.123 X-Spam-Level: X-Spam-Status: No, score=0.123 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_210=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_29=0.6] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zwcA3aLhPcrN for ; Mon, 11 Apr 2011 15:16:04 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtpedge.partnerhosted.com [173.225.22.21]) by ietfc.amsl.com (Postfix) with ESMTP id AEC80E066F for ; Mon, 11 Apr 2011 15:16:03 -0700 (PDT) Received: from EXMBXCLUS01.citservers.local ([fe80::a488:d1ec:a706:3a6d]) by CASUMHUB02.citservers.local ([::1]) with mapi; Mon, 11 Apr 2011 13:21:15 -0700 From: Scott Orton To: Paul Kyzivat Date: Mon, 11 Apr 2011 13:16:51 -0700 Thread-Topic: [siprec] draft-ram-siprec-metadata-format-01 Thread-Index: Acv4QvrNi//XBrihSrmquIW4jyeE6QAQAdvQ Message-ID: <21866C7FE177A4449B9136B5B24B1B130BCA52E93C@EXMBXCLUS01.citservers.local> References: <4D93ADCB.2050106@stpeter.im> <4D94416E.7070102@cisco.com><4D944429.10607@stpeter.im> <4D94714B.8010102@cisco.com> <21866C7FE177A4449B9136B5B24B1B130BC01128BC@EXMBXCLUS01.citservers.local> <21866C7FE177A4449B9136B5B24B1B130BC01128FB@EXMBXCLUS01.citservers.local> <4D9631BB.5060104@cisco.com> In-Reply-To: <4D9631BB.5060104@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 Cc: "siprec@ietf.org" Subject: Re: [siprec] draft-ram-siprec-metadata-format-01 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 11 Apr 2011 22:16:05 -0000 Paul, It does. I cannot see a reason why anyone who is recording a call would = not want to see the changes in the metadata as part of the history of the r= ecorded call.=20 Scott -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: Friday, April 01, 2011 3:13 PM To: Scott Orton Cc: Parthasarathi R (partr); Peter Saint-Andre; siprec@ietf.org Subject: Re: [siprec] draft-ram-siprec-metadata-format-01 Scott, One general principle (IMO): metadata is *never* deleted as a=20 consequence of the mechanisms we are defining - the database is=20 essentially write-only. But everything will be timestamped. (If the SRS=20 wants to delete metadata by policy it may.) For some things the interpretation of transmitting the same thing again=20 is that there is a single value at any point in time - sending a new=20 value affects what the value is considered to be for subsequent times. For other things, (and this needs to be discussed) it may be that values=20 just accumulate as received, and all apply to the thing they attach to=20 for all time. Does that sound right? Thanks, Paul On 3/31/2011 12:21 PM, Scott Orton wrote: > Inline comments. > > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > Sent: Thursday, March 31, 2011 10:42 AM > To: Scott Orton; Paul Kyzivat (pkyzivat); Peter Saint-Andre > Cc: siprec@ietf.org > Subject: RE: [siprec] draft-ram-siprec-metadata-format-01 > > Scott, > > Thanks for the feedback. > > Thanks > Partha > > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf > Of Scott Orton > Sent: Thursday, March 31, 2011 8:59 PM > To: Paul Kyzivat (pkyzivat); Peter Saint-Andre > Cc: siprec@ietf.org > Subject: Re: [siprec] draft-ram-siprec-metadata-format-01 > > Here is some feedback on draft-ram-siprec-metadata-format-01. > > In the xml schema, the group is not listed as an element in the sequence > for the recording-metadata, which conflicts with the example in 5.1. > > Agreed. I'll update in the next revision > > In addition, I found it confusing that the extension data is included in > the participant type but not included in any of the other defined > elements in the recording-metadata. I think it might be good idea to > include the extension data as last element in the sequences for the > group, session, etc. As that would eliminate the need for the parent > attribute in the extension data assuming it stays close to its current > format. > > It purely depend on whether extension-data has to be partially > passed across separately or not. Currently mechanism allows to pass > extension data partially within RS whereas in case it is an element > within any of the metadata block element like participant, stream then > it has to be passed across with any change in that particular metadata > block element. > > > I see the advantages of it being separate for the partial update= . I would just like it to be consistent. Either in each element or in none = of the elements. I think the key to deciding where to include the extension= data is how a partial update should treat the data. If for example in the = initial metadata you send to the SRS there is extensiondata associated with= the participant. Then in an UPDATE the partial metadata for the participan= t update the stop-time, but does not include the extensiondata. How is the = SRS expected to handle the lack of extensiondata? Should it treat it as the= extensiondata is no longer relevant and delete it or should it assume it i= s not changed. If it should treat it as unchanged then how do you delete th= e extension data if it is no longer relevant. Since the definition of the e= xtension data requires at least one string there is no way to remove it. Al= l this leads me to believe that the extension data should be part of each e= lement and the re should be no generic extensiondata element in the recording-metadata. > > In case everyone feels that there is no need to pass extensiondata > explicitly, it realy simply the solution as there is no need another > open item like parent id within extensiondata > > > Regards, > Scott > > > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf > Of Paul Kyzivat > Sent: Thursday, March 31, 2011 7:19 AM > To: Peter Saint-Andre > Cc: siprec@ietf.org > Subject: Re: [siprec] draft-ram-siprec-metadata-format-01 > > > > On 3/31/2011 5:06 AM, Peter Saint-Andre wrote: >> I am booked through 11 PM tonight. >> >> Tomorrow I have the following windows of time: >> >> 07:00-07:30 >> 15:15-16:00 >> >> Naturally that time might get filled if issues come up in some of my >> working groups. :) > > But you also have 11-12pm tonite? :-) > (That is much better for me than the others.) > > Maybe its just too late in the week to hope for this. > We can take it to the list. > > Thanks, > Paul > >> On 3/31/11 10:55 AM, Paul Kyzivat wrote: >>> Peter/Joe, >>> >>> Do either of you have any time in the remainder of the week when some > >>> of us could sit and try to sort out the right way to do the extension > data? >>> I doubt it would take very long. >>> >>> Thanks, >>> Paul >>> >>> On 3/30/2011 6:25 PM, Peter Saint-Andre wrote: >>>> Here is some quick feedback on draft-ram-siprec-metadata-format-01. >>>> I hope to review it more fully soon. >>>> >>>> 1. I would change application/recording to application/recording+xml > >>>> in accordance with RFC 3023 (many specs illustrate the use of XML >>>> media types -- see for example RFC 4287). >>>> >>>> 2. The large number of elements is a bit confusing > in >>>> the examples. >>>> >>>> 3. In Section 5.1, the example has one element >>>> qualified by the 'urn:ietf:params:xml:ns:siprec' namespace (no other >>>> namespace is defined) and then multiple elements >>>> qualified by other namespaces ('http://example.com/groupapp', >>>> 'http://example.com/sessionapp', etc.). Although those other >>>> namespaces are certainly *allowed* to use "extensiondata" as an >>>> element name (that's the beauty of namespaces), it is confusing in > this document. >>>> Perhaps you even meant to have elements qualified > by >>>> the 'urn:ietf:params:xml:ns:siprec' and then child elements >>>> qualified by other namespaces (in accordance with the schema). >>>> However, that is not clear in the spec. >>>> >>>> 4. There is no built-in datatype for xs:urnuuid, xs:streamMode, >>>> xs:requester, and so on. See W3C XML Schema Part 2: >>>> >>>> http://www.w3.org/TR/xmlschema-2/#built-in-datatypes >>>> >>>> 5. The data in the elements with xml:lang=3D"it" really > should be >>>> Giulietta Capuleti and Romeo Montecchi. ;-) >>>> >>>> Peter >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> siprec mailing 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 Henry.Lum@alcatel-lucent.com Mon Apr 11 15:16:24 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 140BEE066B for ; Mon, 11 Apr 2011 15:16:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.866 X-Spam-Level: X-Spam-Status: No, score=-4.866 tagged_above=-999 required=5 tests=[AWL=1.733, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mGGgEEH9NuDJ for ; Mon, 11 Apr 2011 15:16:22 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfc.amsl.com (Postfix) with ESMTP id 90F00E0676 for ; Mon, 11 Apr 2011 15:16:17 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p3BLQKDn015233 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 11 Apr 2011 16:26:20 -0500 (CDT) Received: from relay-out1.wc.genesyslab.com (relay-out1.wc.genesyslab.com [172.22.70.114]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p3BLQHko019128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 11 Apr 2011 16:26:19 -0500 Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out1.wc.genesyslab.com (8.13.8+Sun/8.13.8) with ESMTP id p3BLQHva019085; Mon, 11 Apr 2011 14:26:17 -0700 (PDT) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.93]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 11 Apr 2011 14:26:17 -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, 11 Apr 2011 14:26:19 -0700 Message-ID: <059AF07365DC474393A19A3AF187DF7406E67CB4@NAHALD.us.int.genesyslab.com> In-Reply-To: <4DA334F0.9050301@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] start/stop times & the metamodel Thread-Index: Acv4ar9mNRoQAPkwSImkiZlfghuuTgAIWrig References: <4D9CDADD.1020403@cisco.com> <4DA2FC17.1060100@cisco.com><07465C1D981ABC41A344374066AE1A2C38AB6E1DE4@TLVMBX01.nice.com> <4DA334F0.9050301@cisco.com> From: "Henry Lum" To: "Paul Kyzivat" , "Leon Portman" X-OriginalArrivalTime: 11 Apr 2011 21:26:17.0204 (UTC) FILETIME=[17B68340:01CBF88F] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: siprec@ietf.org Subject: Re: [siprec] start/stop times & the metamodel X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 11 Apr 2011 22:16:24 -0000 A related question on the RTP model is that if the SRC as an RTP translator chooses to relay the RTP timestamps, then how would the SRC synchronize the timestamps between the SIP messages the multiple RTP streams? Henry=20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Monday, April 11, 2011 1:06 PM > To: Leon Portman > Cc: siprec@ietf.org > Subject: Re: [siprec] start/stop times & the metamodel >=20 >=20 >=20 > On 4/11/2011 9:36 AM, Leon Portman wrote: > > Paul Hi > > > > I agree with proposed method of time stamping metadata elements with > SRC clock (it is like a wall clock from the requirement document). > > About RTP time synchronization to metadata events, we either should > have some low latency event from SRC to SRS with SRC time that will > allow SRS to maintain time difference between its clock and SRC clock > and then apply it also to receive time of RTP packet (assuming no > buffering) >=20 > ISTM the issue isn't the latency of the event - it is what it is - but > rather how to correlate a sip message containing metadata with a > particular RTP packet. I suspect that needs to be tied into the > discussion of the various models for how the SRC might handle RDP. >=20 > Thanks, > Paul >=20 > > Leon > > > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Paul Kyzivat > > Sent: Monday, April 11, 2011 4:03 PM > > To: Elwell, John > > Cc: siprec@ietf.org > > Subject: Re: [siprec] start/stop times& the metamodel > > > > > > > > On 4/8/2011 11:53 AM, Elwell, John wrote: > >> Paul, > >> > >> I think much of what you say makes sense. I was concerned that we > probably need to record when a participant stops or starts sending or > receiving a stream, which seems to be covered by your statement: > "Changes to media streams should similarly be tagged with the time they > occurred in the CS signaling. Each participant relationship change > (send, receive, inactive,) will be there." That doesn't seem to be in > the model at present. > > > > John, > > > > I agree the current model doesn't reflect this - it was a private > thought by me, provoked by the work and discussion to date. It is a bit > of a change of direction, so I'm interested in what others think about > it. > > > > Thanks, > > Paul > > > >> John (as individual) > >> > >> > >>> -----Original Message----- > >>> From: siprec-bounces@ietf.org > >>> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > >>> Sent: 06 April 2011 22:28 > >>> To: siprec@ietf.org > >>> Subject: [siprec] start/stop times& the metamodel > >>> > >>> In Prague, one of the open issues was around start/stop times. The > >>> format draft floated the possibility of having explicit start/stop > >>> times signaled for each of the metatdata elements. But then we > asked > >>> for feedback on which make sense. > >>> > >>> IMO explicit start/stop times make more sense for some things than > >>> others. > >>> > >>> One place where we potentially have explicit times to report with > the > >>> dialogs that constitute a CS. Each such dialog presumably has a > start > >>> and stop time observable by the SRC, which might differ, at least a > >>> bit, from the corresponding signaling on the RS. > >>> > >>> We might want to report those times. Or, since we abstract the CS > >>> away from the dialog, we might want to report the start time of the > >>> first dialog in the CS as the CS start time, and the stop time of > the > >>> last dialog in the CS as the CS stop time. > >>> > >>> Similarly, we have abstracted media streams away from the media > >>> streams in the sip dialogs that make up the CS. We might want to > >>> report the start time of a media stream as the time (according to > the > >>> CS) of the first participant to a new media stream, and the stop > time > >>> as the time that the last participant leaves the media stream. > >>> > >>> There are several things that complicate this: > >>> > >>> - Do we consider the case of a stream that starts with recvonly > >>> or inactive participants, and only later gets a sender? If so, > >>> is the start time of the stream when the first participant > arrived, > >>> or when the first sender arrived? > >>> > >>> - How do we get the clock times for the media streams? > >>> IIUC the correct ones are in the RTP/RTCP, but the reporting > of > >>> these events is driven by the signaling, and we don't have > good > >>> sync between those. (E.g. media could start flowing before the > >>> corresponding signaling, and we would like to include that if > we > >>> can figure it out.) So, even if the clocks used for media and > >>> signaling are in sync, we might see media packets arrive with > >>> a timestamp prior to the timestamp for the signaling that > >>> indicates the send state of the participant. This could cause > >>> trouble in playback. > >>> > >>> - There isn't any guarantee that the clock used for signaling > >>> messages is synchronized with the clock used in RTP/RTCP. > >>> > >>> - There isn't any guarantee that there will be any RTCP at all, > >>> to provide correlation of the RTP to clocktime. > >>> > >>> The best I can see to deal with all of this is: > >>> > >>> - All the metadata messages should be timestamped by the SRC > >>> using its local clock. This is easily achieved by the Date > >>> header in the sip message. > >>> > >>> - Changes to a CS, including changes of participants, should > >>> be explicitly tagged with the time they occurred in the > >>> CS signaling, according to the SRC's clock. (If that is > >>> unavailable for some reason, then use the time the SRC > >>> became aware of it.) > >>> > >>> - We could provide a metadata update element to indicate end > >>> of a CS, but I suggest this just be shorthand for indicating > >>> removal of all participants from it. (While its possible to > >>> mark that the CS is truly ended, that simply introduces an > >>> error case if added metadata about it is subsequently sent.) > >>> The actual start/stop time would be determined by the SRS > >>> based on the timestamps of first and last data about it. > >>> > >>> - Changes to media streams should similarly be tagged with > >>> the time they occurred in the CS signaling. Each participant > >>> relationship change (send, receive, inactive,) will be there. > >>> The actual start/stop time of the media stream again would be > >>> derived by the SRS. > >>> > >>> - CS-Groups can simply be tagged by the timestamps of the > >>> updates that put CSs into them. Explicit start/stop times > don't > >>> seem useful. If desired, the SRS can derive start/stop times > >>> from the start/stop times of the contained stuff. > >>> > >>> - I now think that CS-Groups should not be "contained" within > >>> a recording. This just seems to introduce unnecessary error > >>> conditions, and limitations on future enhancements. The > >>> lifetime of CS-Groups will probably be naturally limited by > >>> the ability of the SRC to remember the IDs of old ones. > >>> For instance, if a CS-G is created during one Recording, > >>> and then another CS is added to it from a different recording > >>> session, would we prefer to fail that, or just allow it? > >>> (I think allow.) > >>> > >>> - Rather, I think every update transmitted during a recording > >>> session can be tagged with a link to the metadata of the > >>> recording session it came from. This need not be explicit - > the > >>> SRS can do it automatically. The recording session entity > >>> itself will also have a start/stop time which is the start/ > >>> stop of the RS dialog as observed by the SRS. > >>> > >>> (Note the above doesn't solve the problem of getting correct clock > >>> times for RTP media. If anyone has a suggestion for this I'm all > >>> ears.) > >>> > >>> Thanks, > >>> Paul > >>> _______________________________________________ > >>> siprec mailing 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 =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 eckelcu@cisco.com Mon Apr 11 15:52:56 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9C7CAE0669 for ; Mon, 11 Apr 2011 15:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.514 X-Spam-Level: X-Spam-Status: No, score=-9.514 tagged_above=-999 required=5 tests=[AWL=-0.715, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PtdYwRpYuxgy for ; Mon, 11 Apr 2011 15:52:54 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfc.amsl.com (Postfix) with ESMTP id 523F5E0666 for ; Mon, 11 Apr 2011 15:52:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=24212; q=dns/txt; s=iport; t=1302562373; x=1303771973; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=Je63QDj3KxaXdwNY1Cc2+ol8SNESi0a69Wa22hg2t3w=; b=QHU8FXlhx0nzr+hC5puzclg3sAfX7Qd5q0Pizo3fnlCvDoMCwF8JuCjj 8AyTYLft+HaHGeOvszeo21rK5LKKzs1jWnEsU6/lIb7scHjWZd9ZCeYxz 4Xs+ycTQoncjPY5qcZipAJAp7aRdVab5ekA0TLSX6AUW1ZuxjjdKlfl9Y 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8BALmFo02rRDoI/2dsb2JhbACYRY1bd4h6nUOcSoJ/gm8EhVuLbg X-IronPort-AV: E=Sophos;i="4.64,193,1301875200"; d="scan'208";a="294065270" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-3.cisco.com with ESMTP; 11 Apr 2011 22:52:52 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3BMqq9i010963; Mon, 11 Apr 2011 22:52:52 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 11 Apr 2011 15:52:52 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CBF89B.2FD50164" x-cr-hashedpuzzle: B1YY Cpjs DXks Jo5Z KF2F MgFs Mxdi N+k8 PjTx Pj0K P6I4 TFHt WonO cTH1 dDAQ eD3l; 3; aABrAGEAcABsAGEAbgBAAGEAYwBtAGUAcABhAGMAawBlAHQALgBjAG8AbQA7AGoAbwBoAG4ALgBlAGwAdwBlAGwAbABAAHMAaQBlAG0AZQBuAHMALQBlAG4AdABlAHIAcAByAGkAcwBlAC4AYwBvAG0AOwBzAGkAcAByAGUAYwBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {D09E20AD-2645-4AC9-BD65-AC5FBDE998C0}; ZQBjAGsAZQBsAGMAdQBAAGMAaQBzAGMAbwAuAGMAbwBtAA==; Mon, 11 Apr 2011 22:52:45 GMT; UgBFADoAIABbAHMAaQBwAHIAZQBjAF0AIABQAGEAcgB0AGkAYQBsACAAdQBwAGQAYQB0AGUAcwAgAGEAbgBkACAAaQBkAGUAbgB0AGkAZgBpAGUAcgBzAA== x-cr-puzzleid: {D09E20AD-2645-4AC9-BD65-AC5FBDE998C0} Content-class: urn:content-classes:message Date: Mon, 11 Apr 2011 15:52:45 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Partial updates and identifiers Thread-Index: Acv0jVXI4ji2YTo+SquJ6T6YR3i+lQAdOkDgAEETmvAAg54qsAADKDEgAADSn+AAEAO1UAANZylQ References: <4D9CB8E1.7030402@cisco.com> From: "Charles Eckel (eckelcu)" To: "Elwell, John" , "Parthasarathi R (partr)" , "Paul Kyzivat (pkyzivat)" , X-OriginalArrivalTime: 11 Apr 2011 22:52:52.0416 (UTC) FILETIME=[304CF400:01CBF89B] Cc: "Peter Saint-Andre \(psaintan\)" , "Joe Hildebrand \(jhildebr\)" Subject: Re: [siprec] Partial updates and identifiers X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 11 Apr 2011 22:52:56 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBF89B.2FD50164 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi John, I have attached the last e-mail I have from the thread in which I first raised this issue. Unfortunately, I do not have the e-mail with the ultimate agreement, but maybe someone else does or this will help prompt some memories. Cheers, Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > Sent: Monday, April 11, 2011 9:46 AM > To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); siprec@ietf.org > Cc: Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr); Hadriel Kaplan > Subject: Re: [siprec] Partial updates and identifiers >=20 > Partha, >=20 > Thanks for reminding me - I now recall the discussion some weeks/months ago about the participants > obtained from the conference event package. I was never particularly comfortable with the fact these > were not considered part of the CS. While that might be correct if we consider the CS to be the SIP > dialog between the SRC and the conference focus, taking a broader view of CS those participants behind > the focus could be considered part of the CS. I don't particularly want to open up the old discussion > if people are happy with what we have, but something doesn't seem quite right to me. >=20 > For example, if these "participants" are not considered part of the CS, and if we don't have specific > information about their involvement in media streams, do they really merit being considered > Participant objects? >=20 > In other words, two possible approaches are: >=20 > 1) The CS extends only as far as the focus / mixer. The focus/mixer is a "Participant" and the users > behind the focus are not separate Participants but are just additional data associated with the > focus/mixer Participant. The only Media Streams we are concerned with are between the mixer and the > SRC. >=20 > 2) The CS extends beyond the focus/mixer to users learned via the conference event package, each of > those users is a separate Participant object, and we are concerned with Media Stream objects that > those participants send and receive. I am not sure how feasible this approach is, because I am not > sure that the SRC can obtain enough information about media streams at users behind the focus/mixer. >=20 > It seems the present solution is somewhere between the two, which is why I am uncomfortable. >=20 > Regards, >=20 > John (as individual) >=20 >=20 > > -----Original Message----- > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > Sent: 11 April 2011 10:29 > > To: Elwell, John; Paul Kyzivat (pkyzivat); siprec@ietf.org > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe > > Hildebrand (jhildebr) > > Subject: RE: [siprec] Partial updates and identifiers > > > > John, > > > > Please read inline. > > > > Thanks > > Partha > > > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Monday, April 11, 2011 2:11 PM > > To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); siprec@ietf.org > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe Hildebrand > > (jhildebr) > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > > > > -----Original Message----- > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > Sent: 11 April 2011 08:35 > > > To: Elwell, John; Paul Kyzivat (pkyzivat); siprec@ietf.org > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe Hildebrand > > > (jhildebr) > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > John, > > > > > > As I mentioned below, stream block will be unique within CS, (not > > > required to be unique across multiple CS) and so, xml:id or > > enhancing > > > the normative statement of RFC 4574 label attribute to be unique > > > within CS will serve the purpose. I'm fine with any of the above > > > mentioned id. > > > Please note that RFC 4574 "label" attribute is the nature > > data for RS > > > dialog. > > > > > > In case participant within CS, xml:id will serve the purpose but we > > > need to get more clarity about participants who are not > > part of CS but > > > > > within RS. > > [JRE] If I understand the figure in section 3 of metadata-04 > > correctly, > > a Participant can have a relationship with a CS, but no direct > > relationship with an RS. > > > > Sorry, I mixed up my statement with the latest > > update of making > > CSG optional. As per Sec 3 of metadata-04, participant has direct > > relationship with CSG in case CS is left completely > > unattached. In case > > CSG is optional, then participant will have direct > > relationship with RS > > in case there is no relationship between CS and participant. > > > > > > So a participant that does not have a relationship with a CS is left > > completely unattached, unless it has a relationship with a > > Media Stream > > (which always has a relationship with a CS). So to summarize: > > - a Participant can have a direct relationship with a CS; or > > - a Participant can have an indirect relationship with a CS > > (via a Media > > Stream); > > agreed > > - a Participant can have no relationship with a CS, and therefore no > > relationship with an RS. > > Do we really need this last case? > > > > I'm happy if the last case is not required because > > it simplify > > the solution and there is no need of unique id for > > participant. But SRS > > implementers may prefer to have relationship with participant > > and RS. I > > wish more opinion before taking decision whether to remove > > the last case > > > > > > > Because CS may span across different RS how about the > > participant who > > > are not part of CS? > > [JRE] I don't understand the words "Because CS may span > > across different > > RS", because in the rest of the sentence you are talking about a > > Participant that is not part of a CS. > > > > > Ex: One of the user in the conference acts as SRC, fetch > > participant > > > info using conferene package and new RS is created during initial > > > conference creation and hold&resume of a user within CS. > > [JRE] I am not sure what you are trying to say here. I would > > consider a > > user whose identity is obtained via a conference event > > package as being > > part of the CS. > > > > I'm trying to give the example where participant is not > > associated with CS directly but related to CSG (/RS). This > > scenario was > > considered as a blocking in -03 version of metadata. I'm not > > arguing to > > have this scenario but it is major concern for few folks. > > > > CS is between focus and UA, UA acts as SRC, UA receives the > > participant > > info via conference event package but those participants are > > not related > > in CS directly (and only focus is related) but they > > contributed for the > > mixed stream. > > > > That user is sending/receiving Media Streams that are part > > of a CS, or > > if it isn't sending/receiving Media Streams, what is the relevance of > > that Participant? > > > > Mixed media stream from focus to UA belongs to the Conference > > event package participants. There participant are not > > directly involved > > as part of CS. > > Why would we create a new RS for such a participant? > > RS is not created for participant. Multiple RS shall > > be created > > the same CS during the different time frame as shown below > > > > <-------------------CS1-------------> > > <---RS1--> <---RS2------> > > > > CS1 is between UA (SRC) and focus whereas RS1, RS2 is between UA (SRC) > > and SRS. Here tangling (conference event package) participant > > has to be > > grouped together in RS1, RS2 by some means through given metadata. The > > question whether this corner has to be solved ? > > > > John (as individual) > > > > > > > > > > > > Thanks > > > Partha > > > > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > Sent: Friday, April 08, 2011 9:36 PM > > > To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); > > siprec@ietf.org > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe Hildebrand > > > (jhildebr) > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > Focusing just on participant and stream for the time being, > > do these > > > need to be unique across multiple CSs or not? > > > > > > John > > > > > > > -----Original Message----- > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > Sent: 07 April 2011 10:51 > > > > To: Paul Kyzivat (pkyzivat); siprec@ietf.org; Elwell, John > > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe Hildebrand > > > > (jhildebr) > > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > > > John, > > > > > > > > Sorry for the lengthy mail but it contains lot of analysis and > > > > reasoning for this id approach. > > > > > > > > Adding to Paul's point, I wish to give more background and > > > reason for > > > > these globally unique id. Initially I had the impression that the > > > > single unique id (RS dialog-id) in the recording (session > > > level) and > > > > some relevant natural id for the rest of the element will > > serve the > > > > purpose. > > > > There are usecases where this assumption fails. Even I have > > > thought of > > > > > > > using "xml:id" instead of URN UUID to avoid long string but > > > xml:id may > > > > > > > not end up with unique value always. Our analysis for URN > > UUID for > > > > each level is as follows and please provide your input in case id > > > > shall be > > > > tweaked: > > > > > > > > 1) Recording block: The reason for globally unique id is > > > that multiple > > > > > > > SRC with same id to single SRS. > > > > > > > > Topology: > > > > > > > > SRC1 SRC2 > > > > | | > > > > | ----(RS1-ID1)-----SRS1 > > > > | > > > > ---(RS2-ID1)------------------SRS1 > > > > > > > > In the above topology, it is possible for ID1 is generated by both > > > > SRC1 and SRC2 at the same time. > > > > > > > > 2) group (CSG) block: Grouping mechanism (Hadriel > > session-id, Paul > > > > Jones > > > > Session-UUID) is outside the scope of SIPREC. URN UUID > > > abstracts the > > > > exact mechanism to SRS and provides the information only > > about the > > > > group of CS from SRC perspective. It possible that group may span > > > > across multiple RS and It is up to SRS to group and view > > as single > > > > recording. > > > > Here, the single level id in the top will fail. The counter > > > argument > > > > is to force the single RS having complete CSG but it*may not* be > > > > possible in SRC implementation. Here, xml:id will not serve the > > > > purpose > > > > > > > > 3) session (CS) block: At the immediate look, session > > falls exactly > > > > under recording block. Use case 3 of draft-ietf-siprec-req-09 > > > > illustrates where CS span across multiple RS. This > > > requirement calls > > > > for unique id in session by which these session shall be > > viewed as > > > > single CS even though there is no group exists among > > them. IMO, in > > > > case session should not have globally unique id, then it is > > > preferred > > > > to remove usecase 3 in the requirement. > > > > > > > > 4) participant block: It needs some id which may be AOR but > > > AOR is not > > > > > > > unique. IMO, xml:id may serve the purpose with session > > > unique id. The > > > > trick exists for participant who are not associated with > > > CS. We shall > > > > discuss and fine tune if required. > > > > > > > > 5) stream block: Label attribute shall be used as unique > > > value but RFC > > > > 4574 does not mandate label attribute has to be unique across the > > > > dialog or CS and so, it may possible to change within RS and no > > > > normative statement to stop this implementation. IMO, > > > xml:id may serve > > > > > > > the purpose with session unique id. Here as well, We shall > > > discuss and > > > > > > > fine tune if required. > > > > > > > > 6) extensiondata block: This is tracked in the separate > > mail thread > > > > whether unique id is required or not. Let us close this > > as part of > > > > that mail thread. > > > > > > > > Including explicitly Hadriel, Peter, Joe in this mail > > > thread as they > > > > have different view on this ID mechanism. > > > > > > > > I had offline discussion with Hadriel in Prague after > > > SIPREC meeting > > > > and my understanding of his major concern is that how SRS > > > will be able > > > > > > > to design the database in case partial update does not have > > > recording > > > > (top) id information. I'll put more thought processing to close > > > > Hadriel concern of how top id has to be tracked in case > > > partial update > > > > > > > by which SRS implementation will be simplified in terms of > > > aggregation > > > > > > > maintenance. > > > > > > > > Thanks > > > > Partha > > > > > > > > -----Original Message----- > > > > From: siprec-bounces@ietf.org > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > > > (pkyzivat) > > > > Sent: Thursday, April 07, 2011 12:33 AM > > > > To: siprec@ietf.org > > > > Subject: Re: [siprec] Partial updates and identifiers > > > > > > > > John, > > > > > > > > For the moment we have proposed that the ids be conveyed in > > > the form > > > > of URIs that are globally unique, and specifically that > > > they be UUID > > > > URNs. > > > > There is no dependency on the particular form of the URI, but > > > > specifying they must be UUID URNs makes it possible to > > perform some > > > > internal optimizations for storage. > > > > > > > > The UUID URN is a pretty inefficient encoding. A UUID can > > > be expressed > > > > > > > in 32 bits, so we could consider retaining UUIDs but alter the > > > > encoding if its really an issue. However I am far from > > > convinced that > > > > the size of the IDs is going to be a major issue in the > > > overall size > > > > of messages, so I think its probably premature to worry about it. > > > > > > > > Because the ids can be expressed in 32 bits, the SRC and > > > SRS can store > > > > > > > them internally that way, thus reducing the runtime cost of > > > > maintaining the data. > > > > > > > > The use of unique ids is a significant part of the overall > > > approach to > > > > > > > formatting updates. If somebody has a different concept > > in mind it > > > > could be useful to have an alternative proposal for the > > > format. If we > > > > had two worked out approaches we could compare the > > > tradeoffs in each. > > > > > > > > Thanks, > > > > Paul > > > > > > > > On 4/6/2011 10:24 AM, Elwell, John wrote: > > > > > Much of the discussion on draft-ram-metadata-format in Prague > > > > concerned the mechanism for performing partial updates and > > > the use of > > > > identifiers. The draft permits partial updates by allowing > > > individual > > > > objects (e.g., CS, participant, media stream) to be sent > > > with updated > > > > content, without having to send again other objects that have not > > > > changed. So, for example, in a large conference, it would > > > be possible > > > > to add or modify an individual participant object without > > having to > > > > send all the other participant objects again. I do not recall any > > > > opposition to this basic principle. > > > > > > > > > > However, to achieve this, every object requires an > > > > identifier, and it > > > > was asserted that these identifiers need to be globally > > > unique for all > > > > > > > time. Although this might be efficient for updating an individual > > > > object, when sending many objects (e.g., at the start of a > > > CS or when > > > > refreshing the entire metadata), this can make the metadata very > > > > bulky. > > > > It depends, of course, on the format of the identifiers, > > and it was > > > > stated that there could be alternatives to UUID. > > Nevertheless, some > > > > people had concerns. These concerns also extended to the > > > impact on the > > > > > > > database where metadata is stored, since it might not be > > > feasible to > > > > convert to a database-friendly mechanism for linking > > > objects together. > > > > > > > > > > One alternative proposal during the meeting was to have a single > > > > unique identifier at the top level (for the RS) and use local > > > > identifiers for other objects. Thus when updating a single > > > object, it > > > > would be necessary to include the top level identifier as > > > well as one > > > > or more local identifiers. However, there were also concerns this > > > > might not fulfil actual or perceived future requirements. > > > > > > > > > > Please continue discussion on this. > > > > > > > > > > John (as chair) > > > > > _______________________________________________ > > > > > siprec mailing list > > > > > siprec@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > > _______________________________________________ > > > > siprec mailing list > > > > siprec@ietf.org > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec ------_=_NextPart_001_01CBF89B.2FD50164 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit 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 Subject: RE: [siprec] metadata model for participant that is not part of CS Date: Thu, 27 Jan 2011 11:07:46 -0700 In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD0512507C@XMB-BGL-417.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] metadata model for participant that is not part of CS Thread-Index: Acu9iqr7ynF7z4Y5QUaRyQBZjCoEsQAaTiAQAAqEFKAAC3gkwA== References: <35BCE99A477D6A4986FB2216D8CF2CFD0512507C@XMB-BGL-417.cisco.com> From: "Charles Eckel (eckelcu)" To: "Ram Mohan R (rmohanr)" , "Elwell, John" , Hi Ram, If all CS participants are required to support the conference event package and provide sufficient info about each non-CS participant in order to be allowed to bring them in, then I am ok with it. My concern is that the SRS will not be able to get sufficient info about non-CS participant in all cases. In such cases, it seems to me the media streams should be associated with the CS participant responsible for the non-CS participant, rather than allowing media from incompletely described non-CS participants to exist on its own. You mention the case of the conference focus, in which everything may be fine, but there are other cases, as mentioned by Jon, for which this may not be the case. Cheers, Charles > -----Original Message----- > From: Ram Mohan R (rmohanr) > Sent: Thursday, January 27, 2011 4:35 AM > To: Elwell, John; Charles Eckel (eckelcu); siprec@ietf.org > Subject: RE: [siprec] metadata model for participant that is not part of CS >=20 > Hi Charles/John, >=20 > In the current model, a media stream is always associated with at least one participant. Here is the > snippet of the associations between CS and Participant and Participant and Media Streams taken from > the draft > https://datatracker.ietf.org/doc/draft-ram-siprec-metadata >=20 > Section 4.3.2 has the associations between CS and Participant > Section 4.4.2 has the associations between media stream and participant >=20 > The current model allows participants who are not part of CS to be part of the model. > A example of such a case is: > - participants in a premixed media stream. The SRC may have knowledge of such Participants, yet not > have any signaling relationship with them. This might arise if one participant in CS is a conf focus. >=20 > In those case, if the metadata for non-CS participants is incomplete, the SRC can use other mechanisms > like subscribing to conference event package to retrieve the information about non-CS participants. >=20 > To summarize the model allows representing of non-CS participants who contribute media to CS. >=20 > Charles, > The use case section is at the end of this document > https://datatracker.ietf.org/doc/draft-ram-siprec-metadata >=20 > Please note the case where Focus is acting as SRC is simpler as all participants of conference which > are connected to focus will in turn become participants of CS too. >=20 > Thanks, > Ram >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Elwell, John > > Sent: Thursday, January 27, 2011 1:09 PM > > To: Charles Eckel (eckelcu); siprec@ietf.org > > Subject: Re: [siprec] metadata model for participant that is not part > > of CS > > > > I am starting to see Charles's point. For a participant behind a > > bridge, you don't really know what media he is contributing or what > > media he is receiving. All you know for certain is that the bridge is a > > participant. Perhaps we could assign multiple user identities to a > > bridge participant, thereby reflecting users behind the bridge that may > > or may not be contributing to the media the bridge sends and may or may > > not be recipients of media the bridge receives. > > > > Note that the model when the SRC is at the bridge, rather than outside > > the bridge, is quite different. Also the model where the bridge is > > switching, rather than mixing, might be different. > > > > John (as individual) > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Charles Eckel (eckelcu) > > > Sent: 26 January 2011 18:56 > > > To: siprec@ietf.org > > > Subject: [siprec] metadata model for participant that is not > > > part of CS > > > > > > This is to follow up on some questions I raised regarding the > > metadata > > > model during the interim meeting Tuesday. > > > My initial concern was that I thought we were allowing media > > > streams to > > > be defined without any participant. I now understand that is not the > > > case; rather, a media stream is always associated with at least one > > > participant, but that participant need not necessary be > > > associated with > > > the CS. > > > Now I have some concern about participants that are not part > > > of the CS. > > > My concern is that the level of metadata we have for such > > participants > > > will be inconsistent at best. If the metadata for a non-CS > > participant > > > is incomplete, what do we plan to do? > > > Also, I believe there was reference to a document that contains the > > > model and some use cases. Which document is that? > > > > > > Thanks, > > > Charles > > > _______________________________________________ > > > siprec mailing list > > > siprec@ietf.org > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec ------_=_NextPart_001_01CBF89B.2FD50164-- From eckelcu@cisco.com Mon Apr 11 16:02:47 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 92B9DE06BC for ; Mon, 11 Apr 2011 16:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.363 X-Spam-Level: X-Spam-Status: No, score=-10.363 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-9MRIieio7c for ; Mon, 11 Apr 2011 16:02:46 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfc.amsl.com (Postfix) with ESMTP id 70043E0674 for ; Mon, 11 Apr 2011 16:02:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=3058; q=dns/txt; s=iport; t=1302562942; x=1303772542; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=1vJ8t1ubmBC4OmHxwNUoS3NUwPX1ck8MK/ajxqEGB5Y=; b=BbffnccuFilIN8SZDwZuytkW7NUdOpwlU6jDEBQ1pQqm8ZCU2x7j5dZR fB3i/OQ9Y4/tPQQ/AetfZd+5QC4YRpN/tsgZnsfMLDe7oD1z4tLrxm4VB Ng8IaT+Q2dULqMREx4HliuWtE23REqKFyLUdvDzukVxXtBdGhh89QvoPy k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8BAJuHo02tJV2b/2dsb2JhbACYRY1bd6ZDnEqCfoJwBIVbi24 X-IronPort-AV: E=Sophos;i="4.64,193,1301875200"; d="scan'208";a="335003366" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by sj-iport-2.cisco.com with ESMTP; 11 Apr 2011 23:02:21 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3BN1wjX017782; Mon, 11 Apr 2011 23:02:21 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 11 Apr 2011 16:02:21 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 11 Apr 2011 16:02:20 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] metadata model and persisent recording Thread-Index: Acv4XTAKi/ZJFIEdSLCuZF2ohpHgHAAAPlDgAAKLluAADOhI8A== References: <07465C1D981ABC41A344374066AE1A2C38AB6E1DC4@TLVMBX01.nice.com><4DA31E2C.6080008@cisco.com><07465C1D981ABC41A344374066AE1A2C38AB6E1E75@TLVMBX01.nice.com> From: "Charles Eckel (eckelcu)" To: "Elwell, John" , "Leon Portman" , "Paul Kyzivat (pkyzivat)" , X-OriginalArrivalTime: 11 Apr 2011 23:02:21.0053 (UTC) FILETIME=[833C12D0:01CBF89C] Subject: Re: [siprec] metadata model and persisent recording X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 23:02:47 -0000 If I understand correctly, this is the case in which the URL is: 1) dialed to add a recorder to a conference or 2) a recorder dials into a conference using a given URL as its caller ID In either case, I see the URL as being a property of the recorder, not a participant. I support if the record injects media into the conference, then it could be a participant as well. Is this the reason for having URL presented both as a participant and as the "target" of the RS? Thanks, Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > Sent: Monday, April 11, 2011 9:52 AM > To: Leon Portman; Paul Kyzivat (pkyzivat); siprec@ietf.org > Subject: Re: [siprec] metadata model and persisent recording >=20 > Perhaps this is an attribute of the RS metadata object (let's call it the "target" attribute, i.e., > the target of recording) rather than a participant. When a CS starts, one of the participant objects > associated with the CS will happen to match the target. >=20 > John (as individual) >=20 >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf Of Leon Portman > > Sent: 11 April 2011 16:37 > > To: Paul Kyzivat; siprec@ietf.org > > Subject: Re: [siprec] metadata model and persisent recording > > > > Actually yes, because it is common for persistent session > > that SRS channel are predefined per DN (participant) > > > > Leon > > > > -----Original Message----- > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > > Sent: Monday, April 11, 2011 6:29 PM > > To: siprec@ietf.org > > Subject: Re: [siprec] metadata model and persisent recording > > > > Leon, > > > > Is it important that a persistent RS identify a participant > > when there is no CS? Isn't it sufficient to identify the > > participant at the time the CS is reported? > > > > Thanks, > > Paul > > > > On 4/11/2011 9:24 AM, Leon Portman wrote: > > > Partha Hi > > > > > > I think we are missing in the metadata model support for persistent > > > recording mode, where RS INVITE may be sent from SRC to SRC with > > > participant info but without any communication session or > > group. For > > > example where RS will be established when somebody logins > > to the phone. > > > > > > Regards > > > > > > Leon > > > > > > > > > > > > _______________________________________________ > > > siprec mailing list > > > siprec@ietf.org > > > https://www.ietf.org/mailman/listinfo/siprec > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > > _______________________________________________ > > siprec mailing 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 mperumal@cisco.com Mon Apr 11 19:44:40 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2F42DE0696 for ; Mon, 11 Apr 2011 19:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.898 X-Spam-Level: X-Spam-Status: No, score=-8.898 tagged_above=-999 required=5 tests=[AWL=1.701, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yapfLJnNEHJg for ; Mon, 11 Apr 2011 19:44:38 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfc.amsl.com (Postfix) with ESMTP id 2D06FE0675 for ; Mon, 11 Apr 2011 19:44:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=10769; q=dns/txt; s=iport; t=1302576278; x=1303785878; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=waRRx849w9AvjCjzF+jSxR03bxws4GTuC4EdB/QpKxI=; b=YWn7poMz7EPUgcf7lMeGsrSm7BlJe59SQppxbz0lKUgdZaUbpbRM/spQ iCa2TlAU2vaaCS3GB4p1C+kNvRdBgv0ML5YcdFERSoiXuKiV93KsDjI0F kI/WJonna9iL2Dv2kN3i7meGA8PljwlHvvnvP3+dmm7hxta6wMumIASTe k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8BAHW7o02Q/khR/2dsb2JhbACYRo1cd6RPnGqFbgSFWYtw X-IronPort-AV: E=Sophos;i="4.64,193,1301875200"; d="scan'208";a="83155098" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 12 Apr 2011 02:44:37 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3C2iajQ006086; Tue, 12 Apr 2011 02:44:36 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Apr 2011 08:14:35 +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, 12 Apr 2011 08:14:30 +0530 Message-ID: <1D062974A4845E4D8A343C65380492020533B45B@XMB-BGL-414.cisco.com> In-Reply-To: <059AF07365DC474393A19A3AF187DF7406E67CB4@NAHALD.us.int.genesyslab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] start/stop times & the metamodel Thread-Index: Acv4ar9mNRoQAPkwSImkiZlfghuuTgAIWrigAApMiDA= References: <4D9CDADD.1020403@cisco.com> <4DA2FC17.1060100@cisco.com><07465C1D981ABC41A344374066AE1A2C38AB6E1DE4@TLVMBX01.nice.com><4DA334F0.9050301@cisco.com> <059AF07365DC474393A19A3AF187DF7406E67CB4@NAHALD.us.int.genesyslab.com> From: "Muthu ArulMozhi Perumal (mperumal)" To: "Henry Lum" , "Paul Kyzivat (pkyzivat)" , "Leon Portman" X-OriginalArrivalTime: 12 Apr 2011 02:44:35.0287 (UTC) FILETIME=[8F0EB670:01CBF8BB] Cc: siprec@ietf.org Subject: Re: [siprec] start/stop times & the metamodel X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2011 02:44:40 -0000 While I see it may be useful for the SRS to know when certain things happened in CS signaling (participant joining, leaving, going mute etc) I don't see how useful it would be for it know how those things are related to when the participant actually sent/received (or stopped sending/receiving) RTP. If we see any use, one way to do it is using the NTP timestamp carried in RTCP SR reports, provided the SRC, SRS and the participants have access to the same reference wallclock. Muthu |-----Original Message----- |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Henry Lum |Sent: Tuesday, April 12, 2011 2:56 AM |To: Paul Kyzivat (pkyzivat); Leon Portman |Cc: siprec@ietf.org |Subject: Re: [siprec] start/stop times & the metamodel | |A related question on the RTP model is that if the SRC as an RTP |translator chooses to relay the RTP timestamps, then how would the SRC |synchronize the timestamps between the SIP messages the multiple RTP |streams? | |Henry | |> -----Original Message----- |> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On |> Behalf Of Paul Kyzivat |> Sent: Monday, April 11, 2011 1:06 PM |> To: Leon Portman |> Cc: siprec@ietf.org |> Subject: Re: [siprec] start/stop times & the metamodel |> |> |> |> On 4/11/2011 9:36 AM, Leon Portman wrote: |> > Paul Hi |> > |> > I agree with proposed method of time stamping metadata elements with |> SRC clock (it is like a wall clock from the requirement document). |> > About RTP time synchronization to metadata events, we either should |> have some low latency event from SRC to SRS with SRC time that will |> allow SRS to maintain time difference between its clock and SRC clock |> and then apply it also to receive time of RTP packet (assuming no |> buffering) |> |> ISTM the issue isn't the latency of the event - it is what it is - but |> rather how to correlate a sip message containing metadata with a |> particular RTP packet. I suspect that needs to be tied into the |> discussion of the various models for how the SRC might handle RDP. |> |> Thanks, |> Paul |> |> > Leon |> > |> > -----Original Message----- |> > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On |> Behalf Of Paul Kyzivat |> > Sent: Monday, April 11, 2011 4:03 PM |> > To: Elwell, John |> > Cc: siprec@ietf.org |> > Subject: Re: [siprec] start/stop times& the metamodel |> > |> > |> > |> > On 4/8/2011 11:53 AM, Elwell, John wrote: |> >> Paul, |> >> |> >> I think much of what you say makes sense. I was concerned that we |> probably need to record when a participant stops or starts sending or |> receiving a stream, which seems to be covered by your statement: |> "Changes to media streams should similarly be tagged with the time |they |> occurred in the CS signaling. Each participant relationship change |> (send, receive, inactive,) will be there." That doesn't seem to be in |> the model at present. |> > |> > John, |> > |> > I agree the current model doesn't reflect this - it was a private |> thought by me, provoked by the work and discussion to date. It is a |bit |> of a change of direction, so I'm interested in what others think about |> it. |> > |> > Thanks, |> > Paul |> > |> >> John (as individual) |> >> |> >> |> >>> -----Original Message----- |> >>> From: siprec-bounces@ietf.org |> >>> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat |> >>> Sent: 06 April 2011 22:28 |> >>> To: siprec@ietf.org |> >>> Subject: [siprec] start/stop times& the metamodel |> >>> |> >>> In Prague, one of the open issues was around start/stop times. The |> >>> format draft floated the possibility of having explicit start/stop |> >>> times signaled for each of the metatdata elements. But then we |> asked |> >>> for feedback on which make sense. |> >>> |> >>> IMO explicit start/stop times make more sense for some things than |> >>> others. |> >>> |> >>> One place where we potentially have explicit times to report with |> the |> >>> dialogs that constitute a CS. Each such dialog presumably has a |> start |> >>> and stop time observable by the SRC, which might differ, at least |a |> >>> bit, from the corresponding signaling on the RS. |> >>> |> >>> We might want to report those times. Or, since we abstract the CS |> >>> away from the dialog, we might want to report the start time of |the |> >>> first dialog in the CS as the CS start time, and the stop time of |> the |> >>> last dialog in the CS as the CS stop time. |> >>> |> >>> Similarly, we have abstracted media streams away from the media |> >>> streams in the sip dialogs that make up the CS. We might want to |> >>> report the start time of a media stream as the time (according to |> the |> >>> CS) of the first participant to a new media stream, and the stop |> time |> >>> as the time that the last participant leaves the media stream. |> >>> |> >>> There are several things that complicate this: |> >>> |> >>> - Do we consider the case of a stream that starts with recvonly |> >>> or inactive participants, and only later gets a sender? If |so, |> >>> is the start time of the stream when the first participant |> arrived, |> >>> or when the first sender arrived? |> >>> |> >>> - How do we get the clock times for the media streams? |> >>> IIUC the correct ones are in the RTP/RTCP, but the reporting |> of |> >>> these events is driven by the signaling, and we don't have |> good |> >>> sync between those. (E.g. media could start flowing before |the |> >>> corresponding signaling, and we would like to include that if |> we |> >>> can figure it out.) So, even if the clocks used for media and |> >>> signaling are in sync, we might see media packets arrive with |> >>> a timestamp prior to the timestamp for the signaling that |> >>> indicates the send state of the participant. This could cause |> >>> trouble in playback. |> >>> |> >>> - There isn't any guarantee that the clock used for signaling |> >>> messages is synchronized with the clock used in RTP/RTCP. |> >>> |> >>> - There isn't any guarantee that there will be any RTCP at all, |> >>> to provide correlation of the RTP to clocktime. |> >>> |> >>> The best I can see to deal with all of this is: |> >>> |> >>> - All the metadata messages should be timestamped by the SRC |> >>> using its local clock. This is easily achieved by the Date |> >>> header in the sip message. |> >>> |> >>> - Changes to a CS, including changes of participants, should |> >>> be explicitly tagged with the time they occurred in the |> >>> CS signaling, according to the SRC's clock. (If that is |> >>> unavailable for some reason, then use the time the SRC |> >>> became aware of it.) |> >>> |> >>> - We could provide a metadata update element to indicate end |> >>> of a CS, but I suggest this just be shorthand for indicating |> >>> removal of all participants from it. (While its possible to |> >>> mark that the CS is truly ended, that simply introduces an |> >>> error case if added metadata about it is subsequently sent.) |> >>> The actual start/stop time would be determined by the SRS |> >>> based on the timestamps of first and last data about it. |> >>> |> >>> - Changes to media streams should similarly be tagged with |> >>> the time they occurred in the CS signaling. Each participant |> >>> relationship change (send, receive, inactive,) will be there. |> >>> The actual start/stop time of the media stream again would be |> >>> derived by the SRS. |> >>> |> >>> - CS-Groups can simply be tagged by the timestamps of the |> >>> updates that put CSs into them. Explicit start/stop times |> don't |> >>> seem useful. If desired, the SRS can derive start/stop times |> >>> from the start/stop times of the contained stuff. |> >>> |> >>> - I now think that CS-Groups should not be "contained" within |> >>> a recording. This just seems to introduce unnecessary error |> >>> conditions, and limitations on future enhancements. The |> >>> lifetime of CS-Groups will probably be naturally limited by |> >>> the ability of the SRC to remember the IDs of old ones. |> >>> For instance, if a CS-G is created during one Recording, |> >>> and then another CS is added to it from a different recording |> >>> session, would we prefer to fail that, or just allow it? |> >>> (I think allow.) |> >>> |> >>> - Rather, I think every update transmitted during a recording |> >>> session can be tagged with a link to the metadata of the |> >>> recording session it came from. This need not be explicit - |> the |> >>> SRS can do it automatically. The recording session entity |> >>> itself will also have a start/stop time which is the start/ |> >>> stop of the RS dialog as observed by the SRS. |> >>> |> >>> (Note the above doesn't solve the problem of getting correct clock |> >>> times for RTP media. If anyone has a suggestion for this I'm all |> >>> ears.) |> >>> |> >>> Thanks, |> >>> Paul |> >>> _______________________________________________ |> >>> siprec mailing 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 | | |----------------------------------------------------------------------- ------------------------------- |------------- |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. | |_______________________________________________ |siprec mailing list |siprec@ietf.org |https://www.ietf.org/mailman/listinfo/siprec From partr@cisco.com Mon Apr 11 22:20:10 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4C208E0719 for ; Mon, 11 Apr 2011 22:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.905 X-Spam-Level: X-Spam-Status: No, score=-8.905 tagged_above=-999 required=5 tests=[AWL=-0.106, BAYES_00=-2.599, J_CHICKENPOX_210=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nxd1S8ZXfZYD for ; Mon, 11 Apr 2011 22:20:09 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfc.amsl.com (Postfix) with ESMTP id 7AA52E0718 for ; Mon, 11 Apr 2011 22:20:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=8379; q=dns/txt; s=iport; t=1302585608; x=1303795208; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=MhvMliagCsY7nBCPpCHK6lBVYctbmoEFlkJmoCb1ISE=; b=Q2Rsut8+RUwFnNaA0+ZEhMqlK9xK424z6yU781ZE2e4g8Vr8Ksvp7FB8 Ap3KI3YpCaRmvmKSJCZyjEJSGb9MB1/RC5zMmvYyoCLdfMkS3x/aNqlws nUWMnCSp0Cx4MMjSGFB0MAz8+DxypMvKjM/nyEoR1NA1u0PRYneeiCwGX k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4AANDfo02Q/khNgWdsb2JhbACYRY1cFAEBFiYliHqcFJxjhW4EhVmLew X-IronPort-AV: E=Sophos;i="4.64,194,1301875200"; d="scan'208";a="83167822" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 12 Apr 2011 05:20:07 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3C5K3GG006018; Tue, 12 Apr 2011 05:20:07 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Apr 2011 10:50:05 +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, 12 Apr 2011 10:50:03 +0530 Message-ID: In-Reply-To: <21866C7FE177A4449B9136B5B24B1B130BCA52E93C@EXMBXCLUS01.citservers.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] draft-ram-siprec-metadata-format-01 Thread-Index: Acv4QvrNi//XBrihSrmquIW4jyeE6QAQAdvQABNmJVA= References: <4D93ADCB.2050106@stpeter.im> <4D94416E.7070102@cisco.com><4D944429.10607@stpeter.im> <4D94714B.8010102@cisco.com> <21866C7FE177A4449B9136B5B24B1B130BC01128BC@EXMBXCLUS01.citservers.local> <21866C7FE177A4449B9136B5B24B1B130BC01128FB@EXMBXCLUS01.citservers.local> <4D9631BB.5060104@cisco.com> <21866C7FE177A4449B9136B5B24B1B130BCA52E93C@EXMBXCLUS01.citservers.local> From: "Parthasarathi R (partr)" To: "Scott Orton" , "Paul Kyzivat (pkyzivat)" X-OriginalArrivalTime: 12 Apr 2011 05:20:05.0581 (UTC) FILETIME=[485897D0:01CBF8D1] Cc: siprec@ietf.org Subject: Re: [siprec] draft-ram-siprec-metadata-format-01 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2011 05:20:10 -0000 Scott, Your requirement for changing the metadata was discussed as "retention policy" attribute during the metadata model draft review. It was decided to be considered as outside the scope of SIPREC because it is no possible for SRC to dictate SRS policy in the standard manner. =20 Thanks Partha -----Original Message----- From: Scott Orton [mailto:sorton@broadsoft.com]=20 Sent: Tuesday, April 12, 2011 1:47 AM To: Paul Kyzivat (pkyzivat) Cc: Parthasarathi R (partr); Peter Saint-Andre; siprec@ietf.org Subject: RE: [siprec] draft-ram-siprec-metadata-format-01 Paul, It does. I cannot see a reason why anyone who is recording a call would not want to see the changes in the metadata as part of the history of the recorded call.=20 Scott -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Friday, April 01, 2011 3:13 PM To: Scott Orton Cc: Parthasarathi R (partr); Peter Saint-Andre; siprec@ietf.org Subject: Re: [siprec] draft-ram-siprec-metadata-format-01 Scott, One general principle (IMO): metadata is *never* deleted as a consequence of the mechanisms we are defining - the database is essentially write-only. But everything will be timestamped. (If the SRS wants to delete metadata by policy it may.) For some things the interpretation of transmitting the same thing again is that there is a single value at any point in time - sending a new value affects what the value is considered to be for subsequent times. For other things, (and this needs to be discussed) it may be that values just accumulate as received, and all apply to the thing they attach to for all time. Does that sound right? Thanks, Paul On 3/31/2011 12:21 PM, Scott Orton wrote: > Inline comments. > > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > Sent: Thursday, March 31, 2011 10:42 AM > To: Scott Orton; Paul Kyzivat (pkyzivat); Peter Saint-Andre > Cc: siprec@ietf.org > Subject: RE: [siprec] draft-ram-siprec-metadata-format-01 > > Scott, > > Thanks for the feedback. > > Thanks > Partha > > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > Behalf Of Scott Orton > Sent: Thursday, March 31, 2011 8:59 PM > To: Paul Kyzivat (pkyzivat); Peter Saint-Andre > Cc: siprec@ietf.org > Subject: Re: [siprec] draft-ram-siprec-metadata-format-01 > > Here is some feedback on draft-ram-siprec-metadata-format-01. > > In the xml schema, the group is not listed as an element in the=20 > sequence for the recording-metadata, which conflicts with the example in 5.1. > > Agreed. I'll update in the next revision > > In addition, I found it confusing that the extension data is included=20 > in the participant type but not included in any of the other defined=20 > elements in the recording-metadata. I think it might be good idea to=20 > include the extension data as last element in the sequences for the=20 > group, session, etc. As that would eliminate the need for the parent=20 > attribute in the extension data assuming it stays close to its current > format. > > It purely depend on whether extension-data has to be=20 > partially passed across separately or not. Currently mechanism allows=20 > to pass extension data partially within RS whereas in case it is an=20 > element within any of the metadata block element like participant,=20 > stream then it has to be passed across with any change in that=20 > particular metadata block element. > > > I see the advantages of it being separate for the partial=20 > update. I would just like it to be consistent. Either in each element=20 > or in none of the elements. I think the key to deciding where to=20 > include the extension data is how a partial update should treat the=20 > data. If for example in the initial metadata you send to the SRS there > is extensiondata associated with the participant. Then in an UPDATE=20 > the partial metadata for the participant update the stop-time, but=20 > does not include the extensiondata. How is the SRS expected to handle=20 > the lack of extensiondata? Should it treat it as the extensiondata is=20 > no longer relevant and delete it or should it assume it is not=20 > changed. If it should treat it as unchanged then how do you delete the > extension data if it is no longer relevant. Since the definition of=20 > the extension data requires at least one string there is no way to=20 > remove it. All this leads me to believe that the extension data should > be part of each element and the re should be no generic extensiondata element in the recording-metadata. > > In case everyone feels that there is no need to pass extensiondata=20 > explicitly, it realy simply the solution as there is no need another=20 > open item like parent id within extensiondata > > > Regards, > Scott > > > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > Behalf Of Paul Kyzivat > Sent: Thursday, March 31, 2011 7:19 AM > To: Peter Saint-Andre > Cc: siprec@ietf.org > Subject: Re: [siprec] draft-ram-siprec-metadata-format-01 > > > > On 3/31/2011 5:06 AM, Peter Saint-Andre wrote: >> I am booked through 11 PM tonight. >> >> Tomorrow I have the following windows of time: >> >> 07:00-07:30 >> 15:15-16:00 >> >> Naturally that time might get filled if issues come up in some of my=20 >> working groups. :) > > But you also have 11-12pm tonite? :-) > (That is much better for me than the others.) > > Maybe its just too late in the week to hope for this. > We can take it to the list. > > Thanks, > Paul > >> On 3/31/11 10:55 AM, Paul Kyzivat wrote: >>> Peter/Joe, >>> >>> Do either of you have any time in the remainder of the week when=20 >>> some > >>> of us could sit and try to sort out the right way to do the=20 >>> extension > data? >>> I doubt it would take very long. >>> >>> Thanks, >>> Paul >>> >>> On 3/30/2011 6:25 PM, Peter Saint-Andre wrote: >>>> Here is some quick feedback on draft-ram-siprec-metadata-format-01. >>>> I hope to review it more fully soon. >>>> >>>> 1. I would change application/recording to=20 >>>> application/recording+xml > >>>> in accordance with RFC 3023 (many specs illustrate the use of XML=20 >>>> media types -- see for example RFC 4287). >>>> >>>> 2. The large number of elements is a bit confusing > in >>>> the examples. >>>> >>>> 3. In Section 5.1, the example has one element >>>> qualified by the 'urn:ietf:params:xml:ns:siprec' namespace (no other >>>> namespace is defined) and then multiple elements >>>> qualified by other namespaces ('http://example.com/groupapp',=20 >>>> 'http://example.com/sessionapp', etc.). Although those other=20 >>>> namespaces are certainly *allowed* to use "extensiondata" as an=20 >>>> element name (that's the beauty of namespaces), it is confusing in > this document. >>>> Perhaps you even meant to have elements qualified > by >>>> the 'urn:ietf:params:xml:ns:siprec' and then child elements=20 >>>> qualified by other namespaces (in accordance with the schema). >>>> However, that is not clear in the spec. >>>> >>>> 4. There is no built-in datatype for xs:urnuuid, xs:streamMode,=20 >>>> xs:requester, and so on. See W3C XML Schema Part 2: >>>> >>>> http://www.w3.org/TR/xmlschema-2/#built-in-datatypes >>>> >>>> 5. The data in the elements with xml:lang=3D"it" really > should be >>>> Giulietta Capuleti and Romeo Montecchi. ;-) >>>> >>>> Peter >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> siprec mailing 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 Apr 11 23:28:47 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1F2EEE0749 for ; Mon, 11 Apr 2011 23:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.502 X-Spam-Level: X-Spam-Status: No, score=-104.502 tagged_above=-999 required=5 tests=[AWL=2.097, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-2JihplxWDf for ; Mon, 11 Apr 2011 23:28:45 -0700 (PDT) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfc.amsl.com (Postfix) with SMTP id 5FAACE0742 for ; Mon, 11 Apr 2011 23:28:42 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1302589718!35982702!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 31158 invoked from network); 12 Apr 2011 06:28:39 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-6.tower-27.messagelabs.com with SMTP; 12 Apr 2011 06:28:39 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 2E7B323F03DB; Tue, 12 Apr 2011 08:28:41 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 12 Apr 2011 08:28:41 +0200 From: "Elwell, John" To: "Charles Eckel (eckelcu)" , "Paul Kyzivat (pkyzivat)" , Henry Lum Date: Tue, 12 Apr 2011 08:28:39 +0200 Thread-Topic: [siprec] Recording awareness indication Thread-Index: Acv4TeQi+KylUoLKQ8aqVd4Ks0+vxQADzIHAAB9a6OA= Message-ID: References: <4D9CBB90.4080804@cisco.com> <059AF07365DC474393A19A3AF187DF7406E677EF@NAHALD.us.int.genesyslab.com> <4DA3048E.5000103@cisco.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] Recording awareness indication X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2011 06:28:47 -0000 I am curious why a media feature tag is being considered, rather than an op= tion tag (in the Supported header field). John=20 > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Charles Eckel (eckelcu) > Sent: 11 April 2011 16:33 > To: Paul Kyzivat (pkyzivat); Henry Lum > Cc: siprec@ietf.org > Subject: Re: [siprec] Recording awareness indication >=20 > My thinking on this is that recording awareness indication=20 > may be useful > to indicate an ability to request and/or provide recording. As such, I > may place a call and see in the response that I have the ability to > request this call, or not. I also thought this indication may=20 > be useful > to help a SRC determine how best to indicate to a UA that its media is > being recorded. In both case, but especially in the former, the > indication is not tied to the media, so I think it makes more sense to > signal it as a feature tag than as an SDP attribute.=20 >=20 > Cheers, > Charles >=20 > > -----Original Message----- > > From: Paul Kyzivat (pkyzivat) > > Sent: Monday, April 11, 2011 6:39 AM > > To: Henry Lum > > Cc: Charles Eckel (eckelcu); siprec@ietf.org > > Subject: Re: [siprec] Recording awareness indication > >=20 > >=20 > >=20 > > On 4/8/2011 10:46 AM, Henry Lum wrote: > > > Currently in the draft we propose to use an SDP attribute=20 > to declare > the > > > awareness. I saw comments that this should be changed to a feature > tag > > > instead. I am okay either way; are there arguments against using a > > > feature tag? > >=20 > > IIUC the main argument has been to use SDP attributes to=20 > indicate that > > recording is being done. And there it *is* important for it to be in > SDP > > so it can be indicated on a per-media basis. > >=20 > > For the awareness indicator its not so clear cut. Certainly we could > > define awareness so that it applies to all media, and then=20 > it *could* > be > > in the SIP rather than the SDP. It then comes down to taste - for > > consistency it might be preferable to indicate it in SDP. I=20 > don't have > a > > strong preference one way or the other. > >=20 > > Thanks, > > Paul > >=20 > > > Regards, > > > Henry > > > > > >> -----Original Message----- > > >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > >> Behalf Of Charles Eckel (eckelcu) > > >> Sent: Thursday, April 07, 2011 3:45 PM > > >> To: Paul Kyzivat (pkyzivat); siprec@ietf.org > > >> Subject: Re: [siprec] Recording awareness indication > > >> > > >> I agree with Paul. I would hate to force the addition of=20 > an audible > > >> beep > > >> or a red dot to all participants when a less intrusive=20 > mechanism is > > >> supported. > > >> > > >> Cheers, > > >> Charles > > >> > > >>> -----Original Message----- > > >>> From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On > > >> Behalf Of Paul Kyzivat (pkyzivat) > > >>> Sent: Wednesday, April 06, 2011 12:14 PM > > >>> To: siprec@ietf.org > > >>> Subject: Re: [siprec] Recording awareness indication > > >>> > > >>> I liked this concept of an overt "opt-out" of the in-band > > > indication. > > >>> ISTM that if the UA has a "better" way of doing the=20 > indication it > > > may > > >>> not want the default mechanism. (E.g. The UA may want=20 > to apply its > > >> own > > >>> in-band indication. But that won't work well if a different one > has > > >>> already been applied.) > > >>> > > >>> If we can agree on the *concept* of opt-out, then we=20 > can determine > > >> the > > >>> exact form as a subsequent step. > > >>> > > >>> I suppose some SRCs may feel they are obliged to do their own > > >> indication > > >>> even if a participant desires to opt-out, and we ought to allow > that > > >>> too. In that case there should probably be some indication that > the > > >>> opt-out has been ignored, so that the UA can behave accordingly. > > >>> > > >>> Thanks, > > >>> Paul > > >>> > > >>> On 4/6/2011 11:08 AM, Elwell, John wrote: > > >>>> My own thoughts on this are that the SIP/SDP indication that > > >> recording is in progress, even if sent > > >>> to a UA known to be recording-aware, should not be used as a > > >> substitute for other non-SIP/SDP means of > > >>> notification that might otherwise be needed (e.g., an in-band > audio > > >> announcement). I think recording > > >>> indicators should be used to complement other means.=20 > For example, > an > > >> in-band audio announcement would > > >>> be able to reach all users (although might be problematic for > > >> hearing-impaired users or for users > > >>> speaking a different language). Despite such limitations, an > in-band > > >> announcement is often sufficient > > >>> to satisfy legal requirements. On the other hand, a SIP/SDP > > >> indication > > >> that recording is in progress > > >>> could be rendered in different ways and in different=20 > languages at > > > the > > >> user interface of a recording- > > >>> aware UA. > > >>>> > > >>>> For this reason, I don't see a need for the recording-aware > > >> indication in SIP/SDP. Recording > > >>> indications can be sent without knowing whether they will be > > >> understood by the receiving UA - if they > > >>> are understood the user might get an enhanced=20 > indication - if not > > >> they > > >> will be discarded and the user > > >>> will get only the basic (non-SIP/SDP) indication. > > >>>> > > >>>> John (as individual) > > >>>> > > >>>> > > >>>>> -----Original Message----- > > >>>>> From: siprec-bounces@ietf.org > > >>>>> [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > > >>>>> Sent: 06 April 2011 15:55 > > >>>>> To: siprec@ietf.org > > >>>>> Subject: [siprec] Recording awareness indication > > >>>>> > > >>>>> There was an inconclusive discussion in Prague on the > > >>>>> recording awareness signalling indication in > > >>>>> draft-portman-siprec-protocol (slide 6 / section 6.1 of > > >>>>> draft). If I understand correctly, it indicates that a UA > > >>>>> involved in the CS supports the SIPREC extensions relevant to > > >>>>> the CS. In particular, it indicates that the UA would be able > > >>>>> to understand SIP/SDP recording indications (slide 7 / > > >>>>> section 6.2 of draft). It seems the recording awareness > > >>>>> indication means that the SRC can rely on the recording > > >>>>> indications in SIP/SDP to advise the user that recording is > > >>>>> in progress, thereby avoiding the need for the SRC to provide > > >>>>> suitable indications through non-SIP means (e.g., in-band > > >>>>> audio announcements). > > >>>>> > > >>>>> Please continue this discussion. > > >>>>> > > >>>>> John (as chair) > > >>>>> _______________________________________________ > > >>>>> siprec mailing list > > >>>>> siprec@ietf.org > > >>>>> https://www.ietf.org/mailman/listinfo/siprec > > >>>>> > > >>>> _______________________________________________ > > >>>> siprec mailing list > > >>>> siprec@ietf.org > > >>>> https://www.ietf.org/mailman/listinfo/siprec > > >>>> > > >>> _______________________________________________ > > >>> siprec mailing list > > >>> siprec@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/siprec > > >> _______________________________________________ > > >> 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=20 > 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=20 > store or copy > the information in any medium. > > Copyright in this e-mail and any attachments belongs to=20 > Alcatel-Lucent > and/or its affiliated entities. > > > > > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > = From yuepeiyu@huawei.com Mon Apr 11 23:31:07 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4F99DE074D for ; Mon, 11 Apr 2011 23:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.194 X-Spam-Level: X-Spam-Status: No, score=-102.194 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MANGLED_VIDEO=2.3, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9S6O7jV1h3uU for ; Mon, 11 Apr 2011 23:31:06 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by ietfc.amsl.com (Postfix) with ESMTP id D5661E0742 for ; Mon, 11 Apr 2011 23:31:05 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJJ007AT0OEAJ@szxga03-in.huawei.com> for siprec@ietf.org; Tue, 12 Apr 2011 14:29:02 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJJ00FB00OERP@szxga03-in.huawei.com> for siprec@ietf.org; Tue, 12 Apr 2011 14:29:02 +0800 (CST) Received: from Y58865A ([10.138.73.89]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LJJ00EJO0O9HY@szxml04-in.huawei.com> for siprec@ietf.org; Tue, 12 Apr 2011 14:29:02 +0800 (CST) Date: Tue, 12 Apr 2011 14:28:57 +0800 From: Roy To: siprec@ietf.org Message-id: <007b01cbf8da$e72ff570$b58fe050$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_Efszl4kNcQQ5pGmGCR64RQ)" Content-language: zh-cn Thread-index: Acv42ubXHfPE7b2ZSIutkk8YPChNPg== Subject: [siprec] Question on the scope X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2011 06:31:07 -0000 This is a multi-part message in MIME format. --Boundary_(ID_Efszl4kNcQQ5pGmGCR64RQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hello I find this work group during Prague meeting. The work here is quite interesting although I have some questions as below: All through the architecture and requirement document, we are talking about recording a media session between two UA. However, there is also use cases that a UA1 requests a recording server (SRS) to record a media content in media server (UA2) while there is not any direct media session between UA1 and media server. Following is a general architecture. +-----------+ (Recording Session) | | +-------SIP--------->| Recording | | | Server | | +---MetaData---->| | | | +-----------+ | | ^ | | | | | RTP V V unicast or multicast +------------------+ | | B2BUA | | +--------+ | Service Control | +---------+ | |<- SIP ->| Function |<- SIP ->| | | UA-A | +------------------+ | Media | | | | Server | +--------+ +---------+ This case is very common in IPTV industry, known as Network Personal Video Record (NPVR). I feel this is very similar with the work here. Does current document cover this use case already or did you discussed similar case ever? Many thanks and best regards, Roy --Boundary_(ID_Efszl4kNcQQ5pGmGCR64RQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hello

 

I find this work group during Prague meeting. The work here is quite interesting although I have some questions as below:

 

All through the architecture and requirement document, we are talking about recording a media session between two UA.

However, there is also use cases that a UA1 requests a recording server (SRS) to record a media content in media server (UA2) while there is not any direct media session between UA1 and media server. Following is a general architecture.

 

                                                  +-----------+

                          (Recording Session)     |           |

                             ; +----- ding |

                             |                    |  Server   |

                             |   +---MetaData---->|           |

                           &n |                +-----------+

                             |   |                     ^

                             |   |                     |

     &n sp;                    |   |                    RTP

                             V   V            unicast or multicast

                        +------------------+           |

nbsp;                   |      B2BUA       |           |

     +--------+         | Service Control  |         +---------+

     |        |<- SIP ->|   Function       |<- SIP ->|         |

     |  UA-A  |         +--------- -------- ;     |  Media  |

     |        |                                      |  Server |

     +--------+                                      +---------+

 

This case is very common in IPTV industry, known as Network Personal Vide o Record ery similar with the work here.

Does current document cover this use case already or did you discussed similar case ever?

 

Many thanks and best regards,

Roy

--Boundary_(ID_Efszl4kNcQQ5pGmGCR64RQ)-- From partr@cisco.com Mon Apr 11 23:41:05 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 10459E0753 for ; Mon, 11 Apr 2011 23:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.793 X-Spam-Level: X-Spam-Status: No, score=-9.793 tagged_above=-999 required=5 tests=[AWL=0.806, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qA7wCdc7Yfb2 for ; Mon, 11 Apr 2011 23:41:03 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfc.amsl.com (Postfix) with ESMTP id F4096E074D for ; Mon, 11 Apr 2011 23:41:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=11783; q=dns/txt; s=iport; t=1302590463; x=1303800063; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=mdV+o2WjB5WdviI4D60XOhz3eWTAPNlDS825Wf4hO9w=; b=QaR/AwngnVf1m5MIeqjmpoHdRsCCXabi+GrmeilU5UFwQy9nRwJIKX9j kEz6TnMuOhx9iuDGzu6thfTVq00ORFeu6cmSSGTXjfZ8yGs4CyrR0e/Zo LSeZwDzVk3SDFM4Fcx6tJGh29+LoumdVP7V0wia2VZF9ImR6XBd9x+Cso c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjkBAOHzo02Q/khR/2dsb2JhbACYRY1cd6UlnGeFbgSFWYt7 X-IronPort-AV: E=Sophos;i="4.64,194,1301875200"; d="scan'208";a="83177626" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 12 Apr 2011 06:40:45 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3C6ePtb008091; Tue, 12 Apr 2011 06:40:45 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Apr 2011 12:10:39 +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, 12 Apr 2011 12:10:39 +0530 Message-ID: In-Reply-To: <1D062974A4845E4D8A343C65380492020533B45B@XMB-BGL-414.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] start/stop times & the metamodel Thread-Index: Acv4ar9mNRoQAPkwSImkiZlfghuuTgAIWrigAApMiDAABxSCkA== References: <4D9CDADD.1020403@cisco.com> <4DA2FC17.1060100@cisco.com><07465C1D981ABC41A344374066AE1A2C38AB6E1DE4@TLVMBX01.nice.com><4DA334F0.9050301@cisco.com><059AF07365DC474393A19A3AF187DF7406E67CB4@NAHALD.us.int.genesyslab.com> <1D062974A4845E4D8A343C65380492020533B45B@XMB-BGL-414.cisco.com> From: "Parthasarathi R (partr)" To: "Muthu ArulMozhi Perumal (mperumal)" , "Henry Lum" , "Paul Kyzivat (pkyzivat)" , "Leon Portman" X-OriginalArrivalTime: 12 Apr 2011 06:40:39.0653 (UTC) FILETIME=[89AD7150:01CBF8DC] Cc: siprec@ietf.org Subject: Re: [siprec] start/stop times & the metamodel X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2011 06:41:05 -0000 This is one of the usecase wherein I'm interested in SRC architecture with Application server (AS) & Media server (MS) as a different logical entity. In case AS & MS are two different physical devices, it is highly tough to sync CS RTP timestamp with RS metadata timestamp because the delay between AS & MS communication for RTP timestamp has to be considered. IMO, AS has to aware of the change in the signaling plane and inform in RS metadata with timestamp rather than depend upon media (RTP). =20 Thanks Partha -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Muthu ArulMozhi Perumal (mperumal) Sent: Tuesday, April 12, 2011 8:15 AM To: Henry Lum; Paul Kyzivat (pkyzivat); Leon Portman Cc: siprec@ietf.org Subject: Re: [siprec] start/stop times & the metamodel While I see it may be useful for the SRS to know when certain things happened in CS signaling (participant joining, leaving, going mute etc) I don't see how useful it would be for it know how those things are related to when the participant actually sent/received (or stopped sending/receiving) RTP. If we see any use, one way to do it is using the NTP timestamp carried in RTCP SR reports, provided the SRC, SRS and the participants have access to the same reference wallclock. Muthu |-----Original Message----- |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Henry Lum |Sent: Tuesday, April 12, 2011 2:56 AM |To: Paul Kyzivat (pkyzivat); Leon Portman |Cc: siprec@ietf.org |Subject: Re: [siprec] start/stop times & the metamodel | |A related question on the RTP model is that if the SRC as an RTP=20 |translator chooses to relay the RTP timestamps, then how would the SRC=20 |synchronize the timestamps between the SIP messages the multiple RTP=20 |streams? | |Henry | |> -----Original Message----- |> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 |> Behalf Of Paul Kyzivat |> Sent: Monday, April 11, 2011 1:06 PM |> To: Leon Portman |> Cc: siprec@ietf.org |> Subject: Re: [siprec] start/stop times & the metamodel |> |> |> |> On 4/11/2011 9:36 AM, Leon Portman wrote: |> > Paul Hi |> > |> > I agree with proposed method of time stamping metadata elements with |> SRC clock (it is like a wall clock from the requirement document). |> > About RTP time synchronization to metadata events, we either should |> have some low latency event from SRC to SRS with SRC time that will=20 |> allow SRS to maintain time difference between its clock and SRC clock |> and then apply it also to receive time of RTP packet (assuming no |> buffering) |> |> ISTM the issue isn't the latency of the event - it is what it is - but |> rather how to correlate a sip message containing metadata with a=20 |> particular RTP packet. I suspect that needs to be tied into the=20 |> discussion of the various models for how the SRC might handle RDP. |> |> Thanks, |> Paul |> |> > Leon |> > |> > -----Original Message----- |> > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On |> Behalf Of Paul Kyzivat |> > Sent: Monday, April 11, 2011 4:03 PM |> > To: Elwell, John |> > Cc: siprec@ietf.org |> > Subject: Re: [siprec] start/stop times& the metamodel |> > |> > |> > |> > On 4/8/2011 11:53 AM, Elwell, John wrote: |> >> Paul, |> >> |> >> I think much of what you say makes sense. I was concerned that we |> probably need to record when a participant stops or starts sending or |> receiving a stream, which seems to be covered by your statement: |> "Changes to media streams should similarly be tagged with the time |they |> occurred in the CS signaling. Each participant relationship change=20 |> (send, receive, inactive,) will be there." That doesn't seem to be in |> the model at present. |> > |> > John, |> > |> > I agree the current model doesn't reflect this - it was a private |> thought by me, provoked by the work and discussion to date. It is a |bit |> of a change of direction, so I'm interested in what others think about |> it. |> > |> > Thanks, |> > Paul |> > |> >> John (as individual) |> >> |> >> |> >>> -----Original Message----- |> >>> From: siprec-bounces@ietf.org |> >>> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat |> >>> Sent: 06 April 2011 22:28 |> >>> To: siprec@ietf.org |> >>> Subject: [siprec] start/stop times& the metamodel |> >>> |> >>> In Prague, one of the open issues was around start/stop times. The |> >>> format draft floated the possibility of having explicit start/stop |> >>> times signaled for each of the metatdata elements. But then we |> asked |> >>> for feedback on which make sense. |> >>> |> >>> IMO explicit start/stop times make more sense for some things than |> >>> others. |> >>> |> >>> One place where we potentially have explicit times to report with |> the |> >>> dialogs that constitute a CS. Each such dialog presumably has a |> start |> >>> and stop time observable by the SRC, which might differ, at least |a |> >>> bit, from the corresponding signaling on the RS. |> >>> |> >>> We might want to report those times. Or, since we abstract the CS |> >>> away from the dialog, we might want to report the start time of |the |> >>> first dialog in the CS as the CS start time, and the stop time of |> the |> >>> last dialog in the CS as the CS stop time. |> >>> |> >>> Similarly, we have abstracted media streams away from the media=20 |> >>> streams in the sip dialogs that make up the CS. We might want to=20 |> >>> report the start time of a media stream as the time (according to |> the |> >>> CS) of the first participant to a new media stream, and the stop |> time |> >>> as the time that the last participant leaves the media stream. |> >>> |> >>> There are several things that complicate this: |> >>> |> >>> - Do we consider the case of a stream that starts with recvonly |> >>> or inactive participants, and only later gets a sender? If |so, |> >>> is the start time of the stream when the first participant |> arrived, |> >>> or when the first sender arrived? |> >>> |> >>> - How do we get the clock times for the media streams? |> >>> IIUC the correct ones are in the RTP/RTCP, but the reporting |> of |> >>> these events is driven by the signaling, and we don't have |> good |> >>> sync between those. (E.g. media could start flowing before |the |> >>> corresponding signaling, and we would like to include that if |> we |> >>> can figure it out.) So, even if the clocks used for media and |> >>> signaling are in sync, we might see media packets arrive with |> >>> a timestamp prior to the timestamp for the signaling that |> >>> indicates the send state of the participant. This could cause |> >>> trouble in playback. |> >>> |> >>> - There isn't any guarantee that the clock used for signaling |> >>> messages is synchronized with the clock used in RTP/RTCP. |> >>> |> >>> - There isn't any guarantee that there will be any RTCP at all, |> >>> to provide correlation of the RTP to clocktime. |> >>> |> >>> The best I can see to deal with all of this is: |> >>> |> >>> - All the metadata messages should be timestamped by the SRC |> >>> using its local clock. This is easily achieved by the Date |> >>> header in the sip message. |> >>> |> >>> - Changes to a CS, including changes of participants, should |> >>> be explicitly tagged with the time they occurred in the |> >>> CS signaling, according to the SRC's clock. (If that is |> >>> unavailable for some reason, then use the time the SRC |> >>> became aware of it.) |> >>> |> >>> - We could provide a metadata update element to indicate end |> >>> of a CS, but I suggest this just be shorthand for indicating |> >>> removal of all participants from it. (While its possible to |> >>> mark that the CS is truly ended, that simply introduces an |> >>> error case if added metadata about it is subsequently sent.) |> >>> The actual start/stop time would be determined by the SRS |> >>> based on the timestamps of first and last data about it. |> >>> |> >>> - Changes to media streams should similarly be tagged with |> >>> the time they occurred in the CS signaling. Each participant |> >>> relationship change (send, receive, inactive,) will be there. |> >>> The actual start/stop time of the media stream again would be |> >>> derived by the SRS. |> >>> |> >>> - CS-Groups can simply be tagged by the timestamps of the |> >>> updates that put CSs into them. Explicit start/stop times |> don't |> >>> seem useful. If desired, the SRS can derive start/stop times |> >>> from the start/stop times of the contained stuff. |> >>> |> >>> - I now think that CS-Groups should not be "contained" within |> >>> a recording. This just seems to introduce unnecessary error |> >>> conditions, and limitations on future enhancements. The |> >>> lifetime of CS-Groups will probably be naturally limited by |> >>> the ability of the SRC to remember the IDs of old ones. |> >>> For instance, if a CS-G is created during one Recording, |> >>> and then another CS is added to it from a different recording |> >>> session, would we prefer to fail that, or just allow it? |> >>> (I think allow.) |> >>> |> >>> - Rather, I think every update transmitted during a recording |> >>> session can be tagged with a link to the metadata of the |> >>> recording session it came from. This need not be explicit - |> the |> >>> SRS can do it automatically. The recording session entity |> >>> itself will also have a start/stop time which is the start/ |> >>> stop of the RS dialog as observed by the SRS. |> >>> |> >>> (Note the above doesn't solve the problem of getting correct clock |> >>> times for RTP media. If anyone has a suggestion for this I'm all |> >>> ears.) |> >>> |> >>> Thanks, |> >>> Paul |> >>> _______________________________________________ |> >>> siprec mailing 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 | | |----------------------------------------------------------------------- ------------------------------- |------------- |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. | |_______________________________________________ |siprec mailing 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 Apr 11 23:43:27 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6D307E074A for ; Mon, 11 Apr 2011 23:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.647 X-Spam-Level: X-Spam-Status: No, score=-103.647 tagged_above=-999 required=5 tests=[AWL=1.152, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKlYoHc3kdyh for ; Mon, 11 Apr 2011 23:43:24 -0700 (PDT) Received: from mail174.messagelabs.com (mail174.messagelabs.com [85.158.138.51]) by ietfc.amsl.com (Postfix) with SMTP id 78B0DE0760 for ; Mon, 11 Apr 2011 23:43:23 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-14.tower-174.messagelabs.com!1302590602!16780025!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 13795 invoked from network); 12 Apr 2011 06:43:22 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-14.tower-174.messagelabs.com with SMTP; 12 Apr 2011 06:43:22 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 502491EB83DB; Tue, 12 Apr 2011 08:43:22 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 12 Apr 2011 08:43:22 +0200 From: "Elwell, John" To: "Charles Eckel (eckelcu)" , "Parthasarathi R (partr)" , "Paul Kyzivat (pkyzivat)" , "siprec@ietf.org" Date: Tue, 12 Apr 2011 08:43:20 +0200 Thread-Topic: [siprec] Partial updates and identifiers Thread-Index: Acv0jVXI4ji2YTo+SquJ6T6YR3i+lQAdOkDgAEETmvAAg54qsAADKDEgAADSn+AAEAO1UAANZylQABBzW2A= Message-ID: References: <4D9CB8E1.7030402@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_002_A444A0F8084434499206E78C106220CA0875E32DCCMCHP058Agloba_" MIME-Version: 1.0 Cc: "Peter Saint-Andre \(psaintan\)" , "Joe Hildebrand \(jhildebr\)" Subject: Re: [siprec] Partial updates and identifiers X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2011 06:43:27 -0000 --_002_A444A0F8084434499206E78C106220CA0875E32DCCMCHP058Agloba_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think the attached message was the last in that thread. So I don't really= think we had closure. John > -----Original Message----- > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > Sent: 11 April 2011 23:53 > To: Elwell, John; Parthasarathi R (partr); Paul Kyzivat > (pkyzivat); siprec@ietf.org > Cc: Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr); > Hadriel Kaplan > Subject: RE: [siprec] Partial updates and identifiers > > Hi John, > > I have attached the last e-mail I have from the thread in > which I first > raised this issue. Unfortunately, I do not have the e-mail with the > ultimate agreement, but maybe someone else does or this will > help prompt > some memories. > > Cheers, > Charles > > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Elwell, John > > Sent: Monday, April 11, 2011 9:46 AM > > To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); > siprec@ietf.org > > Cc: Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr); Hadriel > Kaplan > > Subject: Re: [siprec] Partial updates and identifiers > > > > Partha, > > > > Thanks for reminding me - I now recall the discussion some > weeks/months ago about the participants > > obtained from the conference event package. I was never particularly > comfortable with the fact these > > were not considered part of the CS. While that might be > correct if we > consider the CS to be the SIP > > dialog between the SRC and the conference focus, taking a > broader view > of CS those participants behind > > the focus could be considered part of the CS. I don't particularly > want to open up the old discussion > > if people are happy with what we have, but something doesn't seem > quite right to me. > > > > For example, if these "participants" are not considered part of the > CS, and if we don't have specific > > information about their involvement in media streams, do they really > merit being considered > > Participant objects? > > > > In other words, two possible approaches are: > > > > 1) The CS extends only as far as the focus / mixer. The > focus/mixer is > a "Participant" and the users > > behind the focus are not separate Participants but are just > additional > data associated with the > > focus/mixer Participant. The only Media Streams we are > concerned with > are between the mixer and the > > SRC. > > > > 2) The CS extends beyond the focus/mixer to users learned via the > conference event package, each of > > those users is a separate Participant object, and we are concerned > with Media Stream objects that > > those participants send and receive. I am not sure how feasible this > approach is, because I am not > > sure that the SRC can obtain enough information about media > streams at > users behind the focus/mixer. > > > > It seems the present solution is somewhere between the two, which is > why I am uncomfortable. > > > > Regards, > > > > John (as individual) > > > > > > > -----Original Message----- > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > Sent: 11 April 2011 10:29 > > > To: Elwell, John; Paul Kyzivat (pkyzivat); siprec@ietf.org > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe > > > Hildebrand (jhildebr) > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > John, > > > > > > Please read inline. > > > > > > Thanks > > > Partha > > > > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > Sent: Monday, April 11, 2011 2:11 PM > > > To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); > siprec@ietf.org > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe Hildebrand > > > (jhildebr) > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > > > > > > > > -----Original Message----- > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > Sent: 11 April 2011 08:35 > > > > To: Elwell, John; Paul Kyzivat (pkyzivat); siprec@ietf.org > > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe Hildebrand > > > > (jhildebr) > > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > > > John, > > > > > > > > As I mentioned below, stream block will be unique > within CS, (not > > > > required to be unique across multiple CS) and so, xml:id or > > > enhancing > > > > the normative statement of RFC 4574 label attribute to be unique > > > > within CS will serve the purpose. I'm fine with any of the above > > > > mentioned id. > > > > Please note that RFC 4574 "label" attribute is the nature > > > data for RS > > > > dialog. > > > > > > > > In case participant within CS, xml:id will serve the purpose but > we > > > > need to get more clarity about participants who are not > > > part of CS but > > > > > > > within RS. > > > [JRE] If I understand the figure in section 3 of metadata-04 > > > correctly, > > > a Participant can have a relationship with a CS, but no direct > > > relationship with an RS. > > > > > > Sorry, I mixed up my statement with the latest > > > update of making > > > CSG optional. As per Sec 3 of metadata-04, participant has direct > > > relationship with CSG in case CS is left completely > > > unattached. In case > > > CSG is optional, then participant will have direct > > > relationship with RS > > > in case there is no relationship between CS and participant. > > > > > > > > > So a participant that does not have a relationship with a CS is > left > > > completely unattached, unless it has a relationship with a > > > Media Stream > > > (which always has a relationship with a CS). So to summarize: > > > - a Participant can have a direct relationship with a CS; or > > > - a Participant can have an indirect relationship with a CS > > > (via a Media > > > Stream); > > > agreed > > > - a Participant can have no relationship with a CS, and > therefore no > > > relationship with an RS. > > > Do we really need this last case? > > > > > > I'm happy if the last case is not required because > > > it simplify > > > the solution and there is no need of unique id for > > > participant. But SRS > > > implementers may prefer to have relationship with participant > > > and RS. I > > > wish more opinion before taking decision whether to remove > > > the last case > > > > > > > > > > Because CS may span across different RS how about the > > > participant who > > > > are not part of CS? > > > [JRE] I don't understand the words "Because CS may span > > > across different > > > RS", because in the rest of the sentence you are talking about a > > > Participant that is not part of a CS. > > > > > > > Ex: One of the user in the conference acts as SRC, fetch > > > participant > > > > info using conferene package and new RS is created > during initial > > > > conference creation and hold&resume of a user within CS. > > > [JRE] I am not sure what you are trying to say here. I would > > > consider a > > > user whose identity is obtained via a conference event > > > package as being > > > part of the CS. > > > > > > I'm trying to give the example where participant is not > > > associated with CS directly but related to CSG (/RS). This > > > scenario was > > > considered as a blocking in -03 version of metadata. I'm not > > > arguing to > > > have this scenario but it is major concern for few folks. > > > > > > CS is between focus and UA, UA acts as SRC, UA receives the > > > participant > > > info via conference event package but those participants are > > > not related > > > in CS directly (and only focus is related) but they > > > contributed for the > > > mixed stream. > > > > > > That user is sending/receiving Media Streams that are part > > > of a CS, or > > > if it isn't sending/receiving Media Streams, what is the relevance > of > > > that Participant? > > > > > > Mixed media stream from focus to UA belongs to the > Conference > > > event package participants. There participant are not > > > directly involved > > > as part of CS. > > > Why would we create a new RS for such a participant? > > > RS is not created for participant. Multiple RS shall > > > be created > > > the same CS during the different time frame as shown below > > > > > > <-------------------CS1-------------> > > > <---RS1--> <---RS2------> > > > > > > CS1 is between UA (SRC) and focus whereas RS1, RS2 is between UA > (SRC) > > > and SRS. Here tangling (conference event package) participant > > > has to be > > > grouped together in RS1, RS2 by some means through given metadata. > The > > > question whether this corner has to be solved ? > > > > > > John (as individual) > > > > > > > > > > > > > > > > > Thanks > > > > Partha > > > > > > > > -----Original Message----- > > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > Sent: Friday, April 08, 2011 9:36 PM > > > > To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); > > > siprec@ietf.org > > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe Hildebrand > > > > (jhildebr) > > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > > > Focusing just on participant and stream for the time being, > > > do these > > > > need to be unique across multiple CSs or not? > > > > > > > > John > > > > > > > > > -----Original Message----- > > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > > Sent: 07 April 2011 10:51 > > > > > To: Paul Kyzivat (pkyzivat); siprec@ietf.org; Elwell, John > > > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe > Hildebrand > > > > > (jhildebr) > > > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > > > > > John, > > > > > > > > > > Sorry for the lengthy mail but it contains lot of analysis and > > > > > reasoning for this id approach. > > > > > > > > > > Adding to Paul's point, I wish to give more background and > > > > reason for > > > > > these globally unique id. Initially I had the impression that > the > > > > > single unique id (RS dialog-id) in the recording (session > > > > level) and > > > > > some relevant natural id for the rest of the element will > > > serve the > > > > > purpose. > > > > > There are usecases where this assumption fails. Even I have > > > > thought of > > > > > > > > > using "xml:id" instead of URN UUID to avoid long string but > > > > xml:id may > > > > > > > > > not end up with unique value always. Our analysis for URN > > > UUID for > > > > > each level is as follows and please provide your input in case > id > > > > > shall be > > > > > tweaked: > > > > > > > > > > 1) Recording block: The reason for globally unique id is > > > > that multiple > > > > > > > > > SRC with same id to single SRS. > > > > > > > > > > Topology: > > > > > > > > > > SRC1 SRC2 > > > > > | | > > > > > | ----(RS1-ID1)-----SRS1 > > > > > | > > > > > ---(RS2-ID1)------------------SRS1 > > > > > > > > > > In the above topology, it is possible for ID1 is generated by > both > > > > > SRC1 and SRC2 at the same time. > > > > > > > > > > 2) group (CSG) block: Grouping mechanism (Hadriel > > > session-id, Paul > > > > > Jones > > > > > Session-UUID) is outside the scope of SIPREC. URN UUID > > > > abstracts the > > > > > exact mechanism to SRS and provides the information only > > > about the > > > > > group of CS from SRC perspective. It possible that group may > span > > > > > across multiple RS and It is up to SRS to group and view > > > as single > > > > > recording. > > > > > Here, the single level id in the top will fail. The counter > > > > argument > > > > > is to force the single RS having complete CSG but > it*may not* be > > > > > possible in SRC implementation. Here, xml:id will not > serve the > > > > > purpose > > > > > > > > > > 3) session (CS) block: At the immediate look, session > > > falls exactly > > > > > under recording block. Use case 3 of draft-ietf-siprec-req-09 > > > > > illustrates where CS span across multiple RS. This > > > > requirement calls > > > > > for unique id in session by which these session shall be > > > viewed as > > > > > single CS even though there is no group exists among > > > them. IMO, in > > > > > case session should not have globally unique id, then it is > > > > preferred > > > > > to remove usecase 3 in the requirement. > > > > > > > > > > 4) participant block: It needs some id which may be AOR but > > > > AOR is not > > > > > > > > > unique. IMO, xml:id may serve the purpose with session > > > > unique id. The > > > > > trick exists for participant who are not associated with > > > > CS. We shall > > > > > discuss and fine tune if required. > > > > > > > > > > 5) stream block: Label attribute shall be used as unique > > > > value but RFC > > > > > 4574 does not mandate label attribute has to be unique across > the > > > > > dialog or CS and so, it may possible to change within > RS and no > > > > > normative statement to stop this implementation. IMO, > > > > xml:id may serve > > > > > > > > > the purpose with session unique id. Here as well, We shall > > > > discuss and > > > > > > > > > fine tune if required. > > > > > > > > > > 6) extensiondata block: This is tracked in the separate > > > mail thread > > > > > whether unique id is required or not. Let us close this > > > as part of > > > > > that mail thread. > > > > > > > > > > Including explicitly Hadriel, Peter, Joe in this mail > > > > thread as they > > > > > have different view on this ID mechanism. > > > > > > > > > > I had offline discussion with Hadriel in Prague after > > > > SIPREC meeting > > > > > and my understanding of his major concern is that how SRS > > > > will be able > > > > > > > > > to design the database in case partial update does not have > > > > recording > > > > > (top) id information. I'll put more thought > processing to close > > > > > Hadriel concern of how top id has to be tracked in case > > > > partial update > > > > > > > > > by which SRS implementation will be simplified in terms of > > > > aggregation > > > > > > > > > maintenance. > > > > > > > > > > Thanks > > > > > Partha > > > > > > > > > > -----Original Message----- > > > > > From: siprec-bounces@ietf.org > > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > > > > (pkyzivat) > > > > > Sent: Thursday, April 07, 2011 12:33 AM > > > > > To: siprec@ietf.org > > > > > Subject: Re: [siprec] Partial updates and identifiers > > > > > > > > > > John, > > > > > > > > > > For the moment we have proposed that the ids be conveyed in > > > > the form > > > > > of URIs that are globally unique, and specifically that > > > > they be UUID > > > > > URNs. > > > > > There is no dependency on the particular form of the URI, but > > > > > specifying they must be UUID URNs makes it possible to > > > perform some > > > > > internal optimizations for storage. > > > > > > > > > > The UUID URN is a pretty inefficient encoding. A UUID can > > > > be expressed > > > > > > > > > in 32 bits, so we could consider retaining UUIDs but alter the > > > > > encoding if its really an issue. However I am far from > > > > convinced that > > > > > the size of the IDs is going to be a major issue in the > > > > overall size > > > > > of messages, so I think its probably premature to worry about > it. > > > > > > > > > > Because the ids can be expressed in 32 bits, the SRC and > > > > SRS can store > > > > > > > > > them internally that way, thus reducing the runtime cost of > > > > > maintaining the data. > > > > > > > > > > The use of unique ids is a significant part of the overall > > > > approach to > > > > > > > > > formatting updates. If somebody has a different concept > > > in mind it > > > > > could be useful to have an alternative proposal for the > > > > format. If we > > > > > had two worked out approaches we could compare the > > > > tradeoffs in each. > > > > > > > > > > Thanks, > > > > > Paul > > > > > > > > > > On 4/6/2011 10:24 AM, Elwell, John wrote: > > > > > > Much of the discussion on draft-ram-metadata-format > in Prague > > > > > concerned the mechanism for performing partial updates and > > > > the use of > > > > > identifiers. The draft permits partial updates by allowing > > > > individual > > > > > objects (e.g., CS, participant, media stream) to be sent > > > > with updated > > > > > content, without having to send again other objects that have > not > > > > > changed. So, for example, in a large conference, it would > > > > be possible > > > > > to add or modify an individual participant object without > > > having to > > > > > send all the other participant objects again. I do not recall > any > > > > > opposition to this basic principle. > > > > > > > > > > > > However, to achieve this, every object requires an > > > > > identifier, and it > > > > > was asserted that these identifiers need to be globally > > > > unique for all > > > > > > > > > time. Although this might be efficient for updating an > individual > > > > > object, when sending many objects (e.g., at the start of a > > > > CS or when > > > > > refreshing the entire metadata), this can make the > metadata very > > > > > bulky. > > > > > It depends, of course, on the format of the identifiers, > > > and it was > > > > > stated that there could be alternatives to UUID. > > > Nevertheless, some > > > > > people had concerns. These concerns also extended to the > > > > impact on the > > > > > > > > > database where metadata is stored, since it might not be > > > > feasible to > > > > > convert to a database-friendly mechanism for linking > > > > objects together. > > > > > > > > > > > > One alternative proposal during the meeting was to have a > single > > > > > unique identifier at the top level (for the RS) and use local > > > > > identifiers for other objects. Thus when updating a single > > > > object, it > > > > > would be necessary to include the top level identifier as > > > > well as one > > > > > or more local identifiers. However, there were also concerns > this > > > > > might not fulfil actual or perceived future requirements. > > > > > > > > > > > > Please continue discussion on this. > > > > > > > > > > > > John (as chair) > > > > > > _______________________________________________ > > > > > > siprec mailing list > > > > > > siprec@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > > > > _______________________________________________ > > > > > siprec mailing list > > > > > siprec@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > > > > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > --_002_A444A0F8084434499206E78C106220CA0875E32DCCMCHP058Agloba_ Content-Type: message/rfc822 Received: from senmx11-mx (172.28.12.35) by mchp063a.global-ad.net (172.29.37.61) with Microsoft SMTP Server id 8.3.106.1; Mon, 14 Feb 2011 20:25:55 +0100 Received: from ms01.m0019.fra.mmp.de.bt.com (unknown [62.180.227.30]) by senmx11-mx (Server) with ESMTP id 412551EB82C6 for ; Mon, 14 Feb 2011 20:25:55 +0100 (CET) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ms01.m0019.fra.mmp.de.bt.com with ESMTP id BT-MMP-4475670 for john.elwell@siemens-enterprise.com; Mon, 14 Feb 2011 20:25:54 +0100 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 14 Feb 2011 19:25:52 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1EJPqIp020512; Mon, 14 Feb 2011 19:25:52 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, 14 Feb 2011 11:25:52 -0800 From: "Charles Eckel (eckelcu)" To: "Elwell, John" , Leon Portman , "Paul Kyzivat (pkyzivat)" , "siprec@ietf.org" Content-Class: urn:content-classes:message Date: Mon, 14 Feb 2011 20:25:44 +0100 Subject: RE: [siprec] metadata model for participant that is not part of CS Thread-Topic: [siprec] metadata model for participant that is not part of CS Thread-Index: Acu+VBWN/0UhnZhoTuyG1XfePuGXDwLo0uGQAG7QqQAAGceTsAAYVW7A Message-ID: References: <35BCE99A477D6A4986FB2216D8CF2CFD0512507C@XMB-BGL-417.cisco.com><4D41C01C.4050205@cisco.com><07465C1D981ABC41A344374066AE1A2C38A68075BE@TLVMBX01.nice.com> Keywords: SIPREC In-Reply-To: X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AuthSource: MCHP063A.global-ad.net X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: 0 X-MS-TNEF-Correlator: x-originalarrivaltime: 14 Feb 2011 19:25:52.0478 (UTC) FILETIME=[FE4ECFE0:01CBCC7C] x-ironport-av: E=Sophos;i="4.60,469,1291593600"; d="scan'208";a="263365933" x-ironport-anti-spam-result: Ag4BAJcQWU2rR7Ht/2dsb2JhbACXMo5dc6AhmyWFXgSFBIoz x-ironport-anti-spam-filtered: true authentication-results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none x-cr-hashedpuzzle: Ho1i I8zT KMzZ Oj2P Oljt PjEe PugR R1PX TM3G WuKc YxIZ cyMC dbL1 d6ws j0DV kIme;3;agBvAGgAbgAuAGUAbAB3AGUAbABsAEAAcwBpAGUAbQBlAG4AcwAtAGUAbgB0AGUAcgBwAHIAaQBzAGUALgBjAG8AbQA7AGwAZQBvAG4ALgBwAG8AcgB0AG0AYQBuAEAAbgBpAGMAZQAuAGMAbwBtADsAcwBpAHAAcgBlAGMAQABpAGUAdABmAC4AbwByAGcA;Sosha1_v1;7;{338393C4-862C-4610-9CBF-209A3E5B746B};ZQBjAGsAZQBsAGMAdQBAAGMAaQBzAGMAbwAuAGMAbwBtAA==;Mon, 14 Feb 2011 19:25:44 GMT;UgBFADoAIABbAHMAaQBwAHIAZQBjAF0AIABtAGUAdABhAGQAYQB0AGEAIABtAG8AZABlAGwAIABmAG8AcgAgAHAAYQByAHQAaQBjAGkAcABhAG4AdAAgAHQAaABhAHQAIABpAHMAIABuAG8AdAAgAHAAYQByAHQAIABvAGYAIABDAFMA x-cr-puzzleid: {338393C4-862C-4610-9CBF-209A3E5B746B} Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 I am ok with this best effort handling as in reality that is always the case anyway. If we show two use cases, one with highly functionality and cooperative participants and another with lower functioning participants, and illustrate the resulting meta data population, I think that will address my concerns. For example: 1) Participant A within a CS conferences in another party that is not a part of the CS via internal 3rd party conference feature. Participant A does not provide any SIP signaling regarding this toward the SRS. What is the resulting metadata? 2) MCU is used to host a multiparty conference that is part of a CS. What is the resulting metadata at the SRS if the MCU supports the conferencing package? How do things look if it does not. Perhaps (1) is just a special case of (2), but I think going through the metadata example will help determine that. Cheers, Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > Sent: Sunday, February 13, 2011 11:36 PM > To: Leon Portman; Paul Kyzivat (pkyzivat); siprec@ietf.org > Subject: Re: [siprec] metadata model for participant that is not part of CS > > Or we could have values "unknown" for certain things. > > John (as individual) > > > > -----Original Message----- > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > Sent: 13 February 2011 22:40 > > To: Elwell, John; Paul Kyzivat; siprec@ietf.org > > Subject: RE: [siprec] metadata model for participant that is > > not part of CS > > > > Hello, > > > > I agree with Paul statement that SRC should provide best > > effort to report complete metadata as possible. And we should > > model it as complete as possible as well. > > In cases where information is not complete or cannot be > > guaranteed to be correct, we should allow SRC to indicate it: > > maybe we should add a parameter called: "Metadata Certainty"? > > > > Leon > > > > > > -----Original Message----- > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > > Sent: Friday, February 11, 2011 4:29 PM > > To: Paul Kyzivat; siprec@ietf.org > > Subject: Re: [siprec] metadata model for participant that is > > not part of CS > > > > I realise I was directly addressed earlier in this thread and > > I didn't reply (it was left sitting in my inbox). > > > > I don't have anything further to add - I see both sides of > > the argument. Paul/Ram are looking for sufficient > > expressiveness to cover a wide range of situations, even > > though in many cases information available will be limited. > > Charles is concerned, I think, with it being misleading in > > some cases where limited information is available. So perhaps > > we need other opinions in order to close on this one. > > > > John > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > > > Sent: 27 January 2011 18:58 > > > To: siprec@ietf.org > > > Subject: Re: [siprec] metadata model for participant that > > is not part > > > of CS > > > > > > Charles, > > > > > > I don't think we will be able (or should try) to design > > this so that > > > everything the SRC specifies is guaranteed to be as complete as you > > > wish it to be. At the end of the day, the SRC will have to > > do what it > > > can, and some will be better at it than others. If the SRC you have > > > chosen isn't supplying the information it could have and > > wish it had, > > > then you can complain and request upgrades, or you can choose a > > > different product. > > > > > > As long as we have sufficient expressiveness to describe > > things as you > > > wish for any given case then I think we are good. Lets > > ensure we can > > > at least do that. > > > > > > BTW, this is exactly the sort of discussion I have been hoping we > > > would have over the model. I expected it would happen quite > > some time > > > ago. But better now than never. > > > > > > Thanks, > > > Paul > > > > > > On 1/27/2011 1:07 PM, Charles Eckel (eckelcu) wrote: > > > > Hi Ram, > > > > > > > > If all CS participants are required to support the > > conference event > > > > package and provide sufficient info about each non-CS > > participant in > > > > order to be allowed to bring them in, then I am ok with it. > > > My concern > > > > is that the SRS will not be able to get sufficient info > > about non-CS > > > > participant in all cases. In such cases, it seems to me the media > > > > streams should be associated with the CS participant > > > responsible for the > > > > non-CS participant, rather than allowing media from incompletely > > > > described non-CS participants to exist on its own. > > > > You mention the case of the conference focus, in which > > > everything may be > > > > fine, but there are other cases, as mentioned by Jon, for > > > which this may > > > > not be the case. > > > > > > > > Cheers, > > > > Charles > > > > > > > > > > > > > > > >> -----Original Message----- > > > >> From: Ram Mohan R (rmohanr) > > > >> Sent: Thursday, January 27, 2011 4:35 AM > > > >> To: Elwell, John; Charles Eckel (eckelcu); siprec@ietf.org > > > >> Subject: RE: [siprec] metadata model for participant that > > > is not part > > > > of CS > > > >> > > > >> Hi Charles/John, > > > >> > > > >> In the current model, a media stream is always associated with at > > > > least one participant. Here is the > > > >> snippet of the associations between CS and Participant and > > > Participant > > > > and Media Streams taken from > > > >> the draft > > > >> https://datatracker.ietf.org/doc/draft-ram-siprec-metadata > > > >> > > > >> Section 4.3.2 has the associations between CS and Participant > > > >> Section 4.4.2 has the associations between media stream and > > > > participant > > > >> > > > >> The current model allows participants who are not part > > of CS to be > > > > part of the model. > > > >> A example of such a case is: > > > >> - participants in a premixed media stream. The SRC may > > > have knowledge > > > > of such Participants, yet not > > > >> have any signaling relationship with them. This might > > arise if one > > > > participant in CS is a conf focus. > > > >> > > > >> In those case, if the metadata for non-CS participants is > > > incomplete, > > > > the SRC can use other mechanisms > > > >> like subscribing to conference event package to retrieve the > > > > information about non-CS participants. > > > >> > > > >> To summarize the model allows representing of non-CS > > > participants who > > > > contribute media to CS. > > > >> > > > >> Charles, > > > >> The use case section is at the end of this document > > > >> https://datatracker.ietf.org/doc/draft-ram-siprec-metadata > > > >> > > > >> Please note the case where Focus is acting as SRC is > > simpler as all > > > > participants of conference which > > > >> are connected to focus will in turn become participants > > of CS too. > > > >> > > > >> Thanks, > > > >> Ram > > > >> > > > >>> -----Original Message----- > > > >>> From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On > > > >>> Behalf Of Elwell, John > > > >>> Sent: Thursday, January 27, 2011 1:09 PM > > > >>> To: Charles Eckel (eckelcu); siprec@ietf.org > > > >>> Subject: Re: [siprec] metadata model for participant that is not > > > > part > > > >>> of CS > > > >>> > > > >>> I am starting to see Charles's point. For a participant > > behind a > > > >>> bridge, you don't really know what media he is > > > contributing or what > > > >>> media he is receiving. All you know for certain is that > > the bridge > > > > is a > > > >>> participant. Perhaps we could assign multiple user > > identities to a > > > >>> bridge participant, thereby reflecting users behind the > > > bridge that > > > > may > > > >>> or may not be contributing to the media the bridge sends > > > and may or > > > > may > > > >>> not be recipients of media the bridge receives. > > > >>> > > > >>> Note that the model when the SRC is at the bridge, rather than > > > > outside > > > >>> the bridge, is quite different. Also the model where > > the bridge is > > > >>> switching, rather than mixing, might be different. > > > >>> > > > >>> John (as individual) > > > >>> > > > >>>> -----Original Message----- > > > >>>> From: siprec-bounces@ietf.org > > > >>>> [mailto:siprec-bounces@ietf.org] On Behalf Of Charles Eckel > > > > (eckelcu) > > > >>>> Sent: 26 January 2011 18:56 > > > >>>> To: siprec@ietf.org > > > >>>> Subject: [siprec] metadata model for participant that > > is not part > > > >>>> of CS > > > >>>> > > > >>>> This is to follow up on some questions I raised regarding the > > > >>> metadata > > > >>>> model during the interim meeting Tuesday. > > > >>>> My initial concern was that I thought we were allowing media > > > >>>> streams to be defined without any participant. I now > > understand > > > >>>> that is not > > > > the > > > >>>> case; rather, a media stream is always associated with at least > > > > one > > > >>>> participant, but that participant need not necessary be > > > >>>> associated with the CS. > > > >>>> Now I have some concern about participants that are > > not part of > > > >>>> the CS. > > > >>>> My concern is that the level of metadata we have for such > > > >>> participants > > > >>>> will be inconsistent at best. If the metadata for a non-CS > > > >>> participant > > > >>>> is incomplete, what do we plan to do? > > > >>>> Also, I believe there was reference to a document that contains > > > > the > > > >>>> model and some use cases. Which document is that? > > > >>>> > > > >>>> Thanks, > > > >>>> Charles > > > >>>> _______________________________________________ > > > >>>> siprec mailing list > > > >>>> siprec@ietf.org > > > >>>> https://www.ietf.org/mailman/listinfo/siprec > > > >>>> > > > >>> _______________________________________________ > > > >>> siprec mailing list > > > >>> siprec@ietf.org > > > >>> https://www.ietf.org/mailman/listinfo/siprec > > > > _______________________________________________ > > > > siprec mailing 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 --_002_A444A0F8084434499206E78C106220CA0875E32DCCMCHP058Agloba_-- From john.elwell@siemens-enterprise.com Tue Apr 12 00:02:08 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A28B1E0752 for ; Tue, 12 Apr 2011 00:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.572 X-Spam-Level: X-Spam-Status: No, score=-104.572 tagged_above=-999 required=5 tests=[AWL=2.027, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id siLu7puEaRrm for ; Tue, 12 Apr 2011 00:02:07 -0700 (PDT) Received: from mail182.messagelabs.com (mail182.messagelabs.com [85.158.139.83]) by ietfc.amsl.com (Postfix) with SMTP id 8AF12E0750 for ; Tue, 12 Apr 2011 00:02:07 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-13.tower-182.messagelabs.com!1302591726!4716079!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 8019 invoked from network); 12 Apr 2011 07:02:06 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-13.tower-182.messagelabs.com with SMTP; 12 Apr 2011 07:02:06 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 60D2A1EB83DF; Tue, 12 Apr 2011 09:02:06 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 12 Apr 2011 09:02:06 +0200 From: "Elwell, John" To: "Charles Eckel (eckelcu)" , Leon Portman , "Paul Kyzivat (pkyzivat)" , "siprec@ietf.org" Date: Tue, 12 Apr 2011 09:02:05 +0200 Thread-Topic: [siprec] metadata model and persisent recording Thread-Index: Acv4XTAKi/ZJFIEdSLCuZF2ohpHgHAAAPlDgAAKLluAADOhI8AAQtoMw Message-ID: References: <07465C1D981ABC41A344374066AE1A2C38AB6E1DC4@TLVMBX01.nice.com><4DA31E2C.6080008@cisco.com><07465C1D981ABC41A344374066AE1A2C38AB6E1E75@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 Subject: Re: [siprec] metadata model and persisent recording X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 07:02:08 -0000 No, I don't think what you describe is the same as the persistent recording= session that Leon was talking about. I think a persistent recording sessio= n is where there is a permanent recording session between user X (e.g., a c= ontact centre agent) and the SRS, such that whenever user X is involved in = a CS, that CS gets recorded using that RS. At other times the RS is idle, b= ut still exists. Leon wanted to make sure that the identify of X is always = part of the metadata (i.e., it doesn't disappear during times when X is not= involved in a CS), and the way he wanted to achieve that was by considerin= g X as a Participant, even when there is no CS. My alternative proposal is = to make X an attribute of the RS object in the metadata. John > -----Original Message----- > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com]=20 > Sent: 12 April 2011 00:02 > To: Elwell, John; Leon Portman; Paul Kyzivat (pkyzivat);=20 > siprec@ietf.org > Subject: RE: [siprec] metadata model and persisent recording >=20 > If I understand correctly, this is the case in which the URL is: > 1) dialed to add a recorder to a conference > or > 2) a recorder dials into a conference using a given URL as=20 > its caller ID > In either case, I see the URL as being a property of the=20 > recorder, not a > participant. I support if the record injects media into the=20 > conference, > then it could be a participant as well. Is this the reason for having > URL presented both as a participant and as the "target" of the RS? >=20 > Thanks, > Charles >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Elwell, John > > Sent: Monday, April 11, 2011 9:52 AM > > To: Leon Portman; Paul Kyzivat (pkyzivat); siprec@ietf.org > > Subject: Re: [siprec] metadata model and persisent recording > >=20 > > Perhaps this is an attribute of the RS metadata object=20 > (let's call it > the "target" attribute, i.e., > > the target of recording) rather than a participant. When a=20 > CS starts, > one of the participant objects > > associated with the CS will happen to match the target. > >=20 > > John (as individual) > >=20 > >=20 > > > -----Original Message----- > > > From: siprec-bounces@ietf.org > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Leon Portman > > > Sent: 11 April 2011 16:37 > > > To: Paul Kyzivat; siprec@ietf.org > > > Subject: Re: [siprec] metadata model and persisent recording > > > > > > Actually yes, because it is common for persistent session > > > that SRS channel are predefined per DN (participant) > > > > > > Leon > > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > > > Sent: Monday, April 11, 2011 6:29 PM > > > To: siprec@ietf.org > > > Subject: Re: [siprec] metadata model and persisent recording > > > > > > Leon, > > > > > > Is it important that a persistent RS identify a participant > > > when there is no CS? Isn't it sufficient to identify the > > > participant at the time the CS is reported? > > > > > > Thanks, > > > Paul > > > > > > On 4/11/2011 9:24 AM, Leon Portman wrote: > > > > Partha Hi > > > > > > > > I think we are missing in the metadata model support for > persistent > > > > recording mode, where RS INVITE may be sent from SRC to SRC with > > > > participant info but without any communication session or > > > group. For > > > > example where RS will be established when somebody logins > > > to the phone. > > > > > > > > Regards > > > > > > > > Leon > > > > > > > > > > > > > > > > _______________________________________________ > > > > siprec mailing list > > > > siprec@ietf.org > > > > https://www.ietf.org/mailman/listinfo/siprec > > > _______________________________________________ > > > siprec mailing list > > > siprec@ietf.org > > > https://www.ietf.org/mailman/listinfo/siprec > > > _______________________________________________ > > > siprec mailing 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 Apr 12 00:14:30 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A89D0E076E for ; Tue, 12 Apr 2011 00:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.464 X-Spam-Level: X-Spam-Status: No, score=-103.464 tagged_above=-999 required=5 tests=[AWL=0.835, BAYES_00=-2.599, MANGLED_VIDEO=2.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T1fV8gT6ENtT for ; Tue, 12 Apr 2011 00:14:28 -0700 (PDT) Received: from mail182.messagelabs.com (mail182.messagelabs.com [85.158.139.83]) by ietfc.amsl.com (Postfix) with SMTP id 76003E0775 for ; Tue, 12 Apr 2011 00:14:28 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1302592467!4890452!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 27738 invoked from network); 12 Apr 2011 07:14:27 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-9.tower-182.messagelabs.com with SMTP; 12 Apr 2011 07:14:27 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 7C6971EB83E0; Tue, 12 Apr 2011 09:14:27 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 12 Apr 2011 09:14:27 +0200 From: "Elwell, John" To: Roy , "siprec@ietf.org" Date: Tue, 12 Apr 2011 09:14:26 +0200 Thread-Topic: [siprec] Question on the scope Thread-Index: Acv42ubXHfPE7b2ZSIutkk8YPChNPgABXVYQ Message-ID: References: <007b01cbf8da$e72ff570$b58fe050$@com> In-Reply-To: <007b01cbf8da$e72ff570$b58fe050$@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 the scope X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2011 07:14:30 -0000 Roy, I am not sure I understand your use case correctly, but it seems some conte= nt from inside a media server is being recorded, as opposed to recording co= ntent that is transported between two or more users as part of a communicat= ion session. I believe that is outside the scope of the working group. See = the charter and draft-ietf-siprec-req (requirements). Our work is concerned= with recording a session, so content that is held internally to a media se= rver, as opposed to being transported as part of a session is out of scope. John > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Roy > Sent: 12 April 2011 07:29 > To: siprec@ietf.org > Subject: [siprec] Question on the scope >=20 > Hello >=20 > =20 >=20 > I find this work group during Prague meeting. The work here=20 > is quite interesting although I have some questions as below: >=20 > =20 >=20 > All through the architecture and requirement document, we are=20 > talking about recording a media session between two UA.=20 >=20 > However, there is also use cases that a UA1 requests a=20 > recording server (SRS) to record a media content in media=20 > server (UA2) while there is not any direct media session=20 > between UA1 and media server. Following is a general architecture. >=20 > +-----------+ >=20 > (Recording Session) | | >=20 > ; +----- ding | >=20 > | | Server | >=20 > | +---MetaData---->| | >=20 > &n | +-----------+ >=20 > | | ^ >=20 > | | | >=20 > &n sp; | | RTP >=20 > V V unicast or multicast >=20 > +------------------+ | >=20 > nbsp; | B2BUA | | >=20 > +--------+ | Service Control | +---------+ >=20 > | |<- SIP ->| Function |<- SIP ->| | >=20 > | UA-A | +--------- -------- ; | Media | >=20 > | | | Server | >=20 > +--------+ +---------+ >=20 > =20 >=20 > This case is very common in IPTV industry, known as Network=20 > Personal Vide o Record ery similar with the work here. >=20 > Does current document cover this use case already or did you=20 > discussed similar case ever? >=20 > =20 >=20 > Many thanks and best regards, >=20 > Roy >=20 > = From mperumal@cisco.com Tue Apr 12 00:47:20 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8AF07E077E for ; Tue, 12 Apr 2011 00:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.182 X-Spam-Level: X-Spam-Status: No, score=-9.182 tagged_above=-999 required=5 tests=[AWL=1.417, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltfYSiptnIVp for ; Tue, 12 Apr 2011 00:47:18 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfc.amsl.com (Postfix) with ESMTP id 32F4DE077C for ; Tue, 12 Apr 2011 00:47:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=12954; q=dns/txt; s=iport; t=1302594438; x=1303804038; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=kuuQOceGchgIjVrhQk50FU3DMZLoa3ed5HOALceiP5M=; b=beXGOuEFz7LSwuFUPy5PqZbJwGBOVvxx3GWi+dzN/k475qA77OQ7c78l uTnor9awzbCIQ6NBE+OX4rzan5ykQJV2M/tbFdo4BS1sw9BOX7c2ksASF Ukcuj30oZdDbJOJ8a5NvKrFPLGikpMqL5KVi3gz5MMDayRzWBbhmflCsk 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4AAKACpE2Q/khLgWdsb2JhbACYQo1cFAEBFiYlpTOcbYVuBIVZi3s X-IronPort-AV: E=Sophos;i="4.64,194,1301875200"; d="scan'208";a="25352184" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 12 Apr 2011 07:47:04 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3C7kuDH028071; Tue, 12 Apr 2011 07:46:58 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Apr 2011 13:16:57 +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, 12 Apr 2011 13:16:53 +0530 Message-ID: <1D062974A4845E4D8A343C65380492020533B572@XMB-BGL-414.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] start/stop times & the metamodel Thread-Index: Acv4ar9mNRoQAPkwSImkiZlfghuuTgAIWrigAApMiDAABxSCkAAEak0w References: <4D9CDADD.1020403@cisco.com> <4DA2FC17.1060100@cisco.com><07465C1D981ABC41A344374066AE1A2C38AB6E1DE4@TLVMBX01.nice.com><4DA334F0.9050301@cisco.com><059AF07365DC474393A19A3AF187DF7406E67CB4@NAHALD.us.int.genesyslab.com> <1D062974A4845E4D8A343C65380492020533B45B@XMB-BGL-414.cisco.com> From: "Muthu ArulMozhi Perumal (mperumal)" To: "Parthasarathi R (partr)" , "Henry Lum" , "Paul Kyzivat (pkyzivat)" , "Leon Portman" X-OriginalArrivalTime: 12 Apr 2011 07:46:57.0028 (UTC) FILETIME=[CC60B440:01CBF8E5] Cc: siprec@ietf.org Subject: Re: [siprec] start/stop times & the metamodel X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2011 07:47:20 -0000 |In case AS & MS are two different physical devices, |it is highly tough to sync CS RTP timestamp with RS=20 |metadata timestamp because the delay between AS & |MS communication for RTP timestamp has to be considered. As Paul mentioned before, the delay/latency b/w call signaling and media is what it is -- I don't see it as a problem as well. The question is whether there is need to correlate the time of occurrence of events conveyed through call signaling with the transmission/reception time of media packets when those events occurred -- I don't see why the SRC/SRS would find that useful, yet. Muthu |-----Original Message----- |From: Parthasarathi R (partr) |Sent: Tuesday, April 12, 2011 12:11 PM |To: Muthu ArulMozhi Perumal (mperumal); Henry Lum; Paul Kyzivat (pkyzivat); Leon Portman |Cc: siprec@ietf.org |Subject: RE: [siprec] start/stop times & the metamodel | |This is one of the usecase wherein I'm interested in SRC architecture with Application server (AS) & |Media server (MS) as a different logical entity. In case AS & MS are two different physical devices, |it is highly tough to sync CS RTP timestamp with RS metadata timestamp because the delay between AS & |MS communication for RTP timestamp has to be considered. IMO, AS has to aware of the change in the |signaling plane and inform in RS metadata with timestamp rather than depend upon media (RTP). | |Thanks |Partha | |-----Original Message----- |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Muthu ArulMozhi Perumal |(mperumal) |Sent: Tuesday, April 12, 2011 8:15 AM |To: Henry Lum; Paul Kyzivat (pkyzivat); Leon Portman |Cc: siprec@ietf.org |Subject: Re: [siprec] start/stop times & the metamodel | |While I see it may be useful for the SRS to know when certain things happened in CS signaling |(participant joining, leaving, going mute etc) I don't see how useful it would be for it know how |those things are related to when the participant actually sent/received (or stopped |sending/receiving) RTP. | |If we see any use, one way to do it is using the NTP timestamp carried in RTCP SR reports, provided |the SRC, SRS and the participants have access to the same reference wallclock. | |Muthu | ||-----Original Message----- ||From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On |Behalf Of Henry Lum ||Sent: Tuesday, April 12, 2011 2:56 AM ||To: Paul Kyzivat (pkyzivat); Leon Portman ||Cc: siprec@ietf.org ||Subject: Re: [siprec] start/stop times & the metamodel || ||A related question on the RTP model is that if the SRC as an RTP ||translator chooses to relay the RTP timestamps, then how would the SRC ||synchronize the timestamps between the SIP messages the multiple RTP ||streams? || ||Henry || ||> -----Original Message----- ||> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On ||> Behalf Of Paul Kyzivat ||> Sent: Monday, April 11, 2011 1:06 PM ||> To: Leon Portman ||> Cc: siprec@ietf.org ||> Subject: Re: [siprec] start/stop times & the metamodel ||> ||> ||> ||> On 4/11/2011 9:36 AM, Leon Portman wrote: ||> > Paul Hi ||> > ||> > I agree with proposed method of time stamping metadata elements |with ||> SRC clock (it is like a wall clock from the requirement document). ||> > About RTP time synchronization to metadata events, we either should ||> have some low latency event from SRC to SRS with SRC time that will ||> allow SRS to maintain time difference between its clock and SRC clock ||> and then apply it also to receive time of RTP packet (assuming no ||> buffering) ||> ||> ISTM the issue isn't the latency of the event - it is what it is - |but ||> rather how to correlate a sip message containing metadata with a ||> particular RTP packet. I suspect that needs to be tied into the ||> discussion of the various models for how the SRC might handle RDP. ||> ||> Thanks, ||> Paul ||> ||> > Leon ||> > ||> > -----Original Message----- ||> > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On ||> Behalf Of Paul Kyzivat ||> > Sent: Monday, April 11, 2011 4:03 PM ||> > To: Elwell, John ||> > Cc: siprec@ietf.org ||> > Subject: Re: [siprec] start/stop times& the metamodel ||> > ||> > ||> > ||> > On 4/8/2011 11:53 AM, Elwell, John wrote: ||> >> Paul, ||> >> ||> >> I think much of what you say makes sense. I was concerned that we ||> probably need to record when a participant stops or starts sending or ||> receiving a stream, which seems to be covered by your statement: ||> "Changes to media streams should similarly be tagged with the time ||they ||> occurred in the CS signaling. Each participant relationship change ||> (send, receive, inactive,) will be there." That doesn't seem to be in ||> the model at present. ||> > ||> > John, ||> > ||> > I agree the current model doesn't reflect this - it was a private ||> thought by me, provoked by the work and discussion to date. It is a ||bit ||> of a change of direction, so I'm interested in what others think |about ||> it. ||> > ||> > Thanks, ||> > Paul ||> > ||> >> John (as individual) ||> >> ||> >> ||> >>> -----Original Message----- ||> >>> From: siprec-bounces@ietf.org ||> >>> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat ||> >>> Sent: 06 April 2011 22:28 ||> >>> To: siprec@ietf.org ||> >>> Subject: [siprec] start/stop times& the metamodel ||> >>> ||> >>> In Prague, one of the open issues was around start/stop times. |The ||> >>> format draft floated the possibility of having explicit |start/stop ||> >>> times signaled for each of the metatdata elements. But then we ||> asked ||> >>> for feedback on which make sense. ||> >>> ||> >>> IMO explicit start/stop times make more sense for some things |than ||> >>> others. ||> >>> ||> >>> One place where we potentially have explicit times to report with ||> the ||> >>> dialogs that constitute a CS. Each such dialog presumably has a ||> start ||> >>> and stop time observable by the SRC, which might differ, at least ||a ||> >>> bit, from the corresponding signaling on the RS. ||> >>> ||> >>> We might want to report those times. Or, since we abstract the CS ||> >>> away from the dialog, we might want to report the start time of ||the ||> >>> first dialog in the CS as the CS start time, and the stop time of ||> the ||> >>> last dialog in the CS as the CS stop time. ||> >>> ||> >>> Similarly, we have abstracted media streams away from the media ||> >>> streams in the sip dialogs that make up the CS. We might want to ||> >>> report the start time of a media stream as the time (according to ||> the ||> >>> CS) of the first participant to a new media stream, and the stop ||> time ||> >>> as the time that the last participant leaves the media stream. ||> >>> ||> >>> There are several things that complicate this: ||> >>> ||> >>> - Do we consider the case of a stream that starts with recvonly ||> >>> or inactive participants, and only later gets a sender? If ||so, ||> >>> is the start time of the stream when the first participant ||> arrived, ||> >>> or when the first sender arrived? ||> >>> ||> >>> - How do we get the clock times for the media streams? ||> >>> IIUC the correct ones are in the RTP/RTCP, but the reporting ||> of ||> >>> these events is driven by the signaling, and we don't have ||> good ||> >>> sync between those. (E.g. media could start flowing before ||the ||> >>> corresponding signaling, and we would like to include that |if ||> we ||> >>> can figure it out.) So, even if the clocks used for media |and ||> >>> signaling are in sync, we might see media packets arrive |with ||> >>> a timestamp prior to the timestamp for the signaling that ||> >>> indicates the send state of the participant. This could |cause ||> >>> trouble in playback. ||> >>> ||> >>> - There isn't any guarantee that the clock used for signaling ||> >>> messages is synchronized with the clock used in RTP/RTCP. ||> >>> ||> >>> - There isn't any guarantee that there will be any RTCP at all, ||> >>> to provide correlation of the RTP to clocktime. ||> >>> ||> >>> The best I can see to deal with all of this is: ||> >>> ||> >>> - All the metadata messages should be timestamped by the SRC ||> >>> using its local clock. This is easily achieved by the Date ||> >>> header in the sip message. ||> >>> ||> >>> - Changes to a CS, including changes of participants, should ||> >>> be explicitly tagged with the time they occurred in the ||> >>> CS signaling, according to the SRC's clock. (If that is ||> >>> unavailable for some reason, then use the time the SRC ||> >>> became aware of it.) ||> >>> ||> >>> - We could provide a metadata update element to indicate end ||> >>> of a CS, but I suggest this just be shorthand for indicating ||> >>> removal of all participants from it. (While its possible to ||> >>> mark that the CS is truly ended, that simply introduces an ||> >>> error case if added metadata about it is subsequently sent.) ||> >>> The actual start/stop time would be determined by the SRS ||> >>> based on the timestamps of first and last data about it. ||> >>> ||> >>> - Changes to media streams should similarly be tagged with ||> >>> the time they occurred in the CS signaling. Each participant ||> >>> relationship change (send, receive, inactive,) will be |there. ||> >>> The actual start/stop time of the media stream again would |be ||> >>> derived by the SRS. ||> >>> ||> >>> - CS-Groups can simply be tagged by the timestamps of the ||> >>> updates that put CSs into them. Explicit start/stop times ||> don't ||> >>> seem useful. If desired, the SRS can derive start/stop times ||> >>> from the start/stop times of the contained stuff. ||> >>> ||> >>> - I now think that CS-Groups should not be "contained" within ||> >>> a recording. This just seems to introduce unnecessary error ||> >>> conditions, and limitations on future enhancements. The ||> >>> lifetime of CS-Groups will probably be naturally limited by ||> >>> the ability of the SRC to remember the IDs of old ones. ||> >>> For instance, if a CS-G is created during one Recording, ||> >>> and then another CS is added to it from a different |recording ||> >>> session, would we prefer to fail that, or just allow it? ||> >>> (I think allow.) ||> >>> ||> >>> - Rather, I think every update transmitted during a recording ||> >>> session can be tagged with a link to the metadata of the ||> >>> recording session it came from. This need not be explicit - ||> the ||> >>> SRS can do it automatically. The recording session entity ||> >>> itself will also have a start/stop time which is the start/ ||> >>> stop of the RS dialog as observed by the SRS. ||> >>> ||> >>> (Note the above doesn't solve the problem of getting correct |clock ||> >>> times for RTP media. If anyone has a suggestion for this I'm all ||> >>> ears.) ||> >>> ||> >>> Thanks, ||> >>> Paul ||> >>> _______________________________________________ ||> >>> siprec mailing 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 || || ||---------------------------------------------------------------------- - |------------------------------- ||------------- ||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. || ||_______________________________________________ ||siprec mailing list ||siprec@ietf.org ||https://www.ietf.org/mailman/listinfo/siprec |_______________________________________________ |siprec mailing list |siprec@ietf.org |https://www.ietf.org/mailman/listinfo/siprec From rmohanr@cisco.com Tue Apr 12 00:47:21 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2D775E077C for ; Tue, 12 Apr 2011 00:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tweDzRZ0dVI4 for ; Tue, 12 Apr 2011 00:47:19 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfc.amsl.com (Postfix) with ESMTP id 549C8E076E for ; Tue, 12 Apr 2011 00:47:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=7490; q=dns/txt; s=iport; t=1302594439; x=1303804039; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=sMu2lXPsWlb2J3IrHhpYh8+RUpqKrBUnG1czJGcv56w=; b=l1wtjg2wEr5eEgfJuVY1gLxpVQUvQB9jv5PptqWIRuC8OZ3ncK5iv5lD G3ajwCBjFzojmNaeZiE1z0C3OaVwn5NmlY71msjv/YHrFPr0UCqtUu9s/ bKCwJbZsOoJ20rWHrNzhqjocZ1ntQFbgTKkyYc2hnNNCpGhFcvc4dm3oz o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjkBAKACpE2Q/khR/2dsb2JhbACYQo1cd4h6nDmcbYVuBIVZi3s X-IronPort-AV: E=Sophos;i="4.64,194,1301875200"; d="scan'208";a="25352203" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 12 Apr 2011 07:47:06 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3C7l5uU024602; Tue, 12 Apr 2011 07:47:05 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, 12 Apr 2011 13:17:04 +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, 12 Apr 2011 13:17:02 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD06009405@XMB-BGL-417.cisco.com> In-Reply-To: <4DA2FC17.1060100@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] start/stop times & the metamodel Thread-Index: Acv4SNxgbqUl8VtvRLKQD5NvHQX6rQAlVKGA References: <4D9CDADD.1020403@cisco.com> <4DA2FC17.1060100@cisco.com> From: "Ram Mohan R (rmohanr)" To: "Paul Kyzivat (pkyzivat)" , "Elwell, John" X-OriginalArrivalTime: 12 Apr 2011 07:47:04.0850 (UTC) FILETIME=[D10A3F20:01CBF8E5] Cc: siprec@ietf.org Subject: Re: [siprec] start/stop times & the metamodel X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2011 07:47:21 -0000 Inline=20 A comment on this mail > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Paul Kyzivat (pkyzivat) > Sent: Monday, April 11, 2011 6:33 PM > To: Elwell, John > Cc: siprec@ietf.org > Subject: Re: [siprec] start/stop times & the metamodel >=20 >=20 >=20 > On 4/8/2011 11:53 AM, Elwell, John wrote: > > Paul, > > > > I think much of what you say makes sense. I was concerned that we > probably need to record when a participant stops or starts sending or > receiving a stream, which seems to be covered by your statement: > "Changes to media streams should similarly be tagged with the time they > occurred in the CS signaling. Each participant relationship change > (send, receive, inactive,) will be there." That doesn't seem to be in > the model at present. I agree on sending information of when a participant start/stop sending media [ from SRC perspective - what SRC sees] in the metadata. Do we really need reporting Changes to the media streams of CS like send, receive, inactive ? This would again go back to sending portions of CS SDP [ in this case direction attribute] in metadata. Ram >=20 > John, >=20 > I agree the current model doesn't reflect this - it was a private > thought by me, provoked by the work and discussion to date. It is a bit > of a change of direction, so I'm interested in what others think about > it. >=20 > Thanks, > Paul >=20 > > John (as individual) > > > > > >> -----Original Message----- > >> From: siprec-bounces@ietf.org > >> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > >> Sent: 06 April 2011 22:28 > >> To: siprec@ietf.org > >> Subject: [siprec] start/stop times& the metamodel > >> > >> In Prague, one of the open issues was around start/stop times. The > >> format draft floated the possibility of having explicit > >> start/stop times > >> signaled for each of the metatdata elements. But then we asked for > >> feedback on which make sense. > >> > >> IMO explicit start/stop times make more sense for some things > >> than others. > >> > >> One place where we potentially have explicit times to report with > the > >> dialogs that constitute a CS. Each such dialog presumably has a > start > >> and stop time observable by the SRC, which might differ, at > >> least a bit, > >> from the corresponding signaling on the RS. > >> > >> We might want to report those times. Or, since we abstract > >> the CS away > >> from the dialog, we might want to report the start time of the first > >> dialog in the CS as the CS start time, and the stop time of the last > >> dialog in the CS as the CS stop time. > >> > >> Similarly, we have abstracted media streams away from the > >> media streams > >> in the sip dialogs that make up the CS. We might want to report the > >> start time of a media stream as the time (according to the CS) of > the > >> first participant to a new media stream, and the stop time as > >> the time > >> that the last participant leaves the media stream. > >> > >> There are several things that complicate this: > >> > >> - Do we consider the case of a stream that starts with recvonly > >> or inactive participants, and only later gets a sender? If so, > >> is the start time of the stream when the first participant > arrived, > >> or when the first sender arrived? > >> > >> - How do we get the clock times for the media streams? > >> IIUC the correct ones are in the RTP/RTCP, but the reporting of > >> these events is driven by the signaling, and we don't have good > >> sync between those. (E.g. media could start flowing before the > >> corresponding signaling, and we would like to include that if we > >> can figure it out.) So, even if the clocks used for media and > >> signaling are in sync, we might see media packets arrive with > >> a timestamp prior to the timestamp for the signaling that > >> indicates the send state of the participant. This could cause > >> trouble in playback. > >> > >> - There isn't any guarantee that the clock used for signaling > >> messages is synchronized with the clock used in RTP/RTCP. > >> > >> - There isn't any guarantee that there will be any RTCP at all, > >> to provide correlation of the RTP to clocktime. > >> > >> The best I can see to deal with all of this is: > >> > >> - All the metadata messages should be timestamped by the SRC > >> using its local clock. This is easily achieved by the Date > >> header in the sip message. > >> > >> - Changes to a CS, including changes of participants, should > >> be explicitly tagged with the time they occurred in the > >> CS signaling, according to the SRC's clock. (If that is > >> unavailable for some reason, then use the time the SRC > >> became aware of it.) > >> > >> - We could provide a metadata update element to indicate end > >> of a CS, but I suggest this just be shorthand for indicating > >> removal of all participants from it. (While its possible to > >> mark that the CS is truly ended, that simply introduces an > >> error case if added metadata about it is subsequently sent.) > >> The actual start/stop time would be determined by the SRS > >> based on the timestamps of first and last data about it. > >> > >> - Changes to media streams should similarly be tagged with > >> the time they occurred in the CS signaling. Each participant > >> relationship change (send, receive, inactive,) will be there. > >> The actual start/stop time of the media stream again would be > >> derived by the SRS. > >> > >> - CS-Groups can simply be tagged by the timestamps of the > >> updates that put CSs into them. Explicit start/stop times don't > >> seem useful. If desired, the SRS can derive start/stop times > >> from the start/stop times of the contained stuff. > >> > >> - I now think that CS-Groups should not be "contained" within > >> a recording. This just seems to introduce unnecessary error > >> conditions, and limitations on future enhancements. The > >> lifetime of CS-Groups will probably be naturally limited by > >> the ability of the SRC to remember the IDs of old ones. > >> For instance, if a CS-G is created during one Recording, > >> and then another CS is added to it from a different recording > >> session, would we prefer to fail that, or just allow it? > >> (I think allow.) > >> > >> - Rather, I think every update transmitted during a recording > >> session can be tagged with a link to the metadata of the > >> recording session it came from. This need not be explicit - the > >> SRS can do it automatically. The recording session entity > >> itself will also have a start/stop time which is the start/ > >> stop of the RS dialog as observed by the SRS. > >> > >> (Note the above doesn't solve the problem of getting correct > >> clock times > >> for RTP media. If anyone has a suggestion for this I'm all ears.) > >> > >> Thanks, > >> Paul > >> _______________________________________________ > >> siprec mailing 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 mperumal@cisco.com Tue Apr 12 01:21:34 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E6340E068A for ; Tue, 12 Apr 2011 01:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.384 X-Spam-Level: X-Spam-Status: No, score=-9.384 tagged_above=-999 required=5 tests=[AWL=1.215, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZxc-hCNceA2 for ; Tue, 12 Apr 2011 01:21:33 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfc.amsl.com (Postfix) with ESMTP id 34E98E0613 for ; Tue, 12 Apr 2011 01:21:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=8905; q=dns/txt; s=iport; t=1302596493; x=1303806093; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=I3tcVGUKBFeIIMk685V1NlkfywhP4j+69/ejIqtTAzI=; b=Ewj9tSE7mG76c6slyCLMCMKhnWHkW4i5u/EulqfYsfMmcRf2oKDEqdv3 85gfcX+0xDMDoR9rsdey63g+sUVnVkT/bbpSf6wa/58C95ozzP9d1dJTT jwuo3DqAR+4IXaGKOxATEQMWhbBKIXmEV3mIT2X11rzACnR4WJGnlQDxG 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4AAFILpE2Q/khLgWdsb2JhbACYQ41cFAEBFiYlpTucb4MAgm4EhVmLew X-IronPort-AV: E=Sophos;i="4.64,194,1301875200"; d="scan'208";a="83194317" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 12 Apr 2011 08:21:32 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3C8KsJJ003771; Tue, 12 Apr 2011 08:21:32 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Apr 2011 13:51: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: Tue, 12 Apr 2011 13:51:29 +0530 Message-ID: <1D062974A4845E4D8A343C65380492020533B590@XMB-BGL-414.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD06009405@XMB-BGL-417.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] start/stop times & the metamodel Thread-Index: Acv4SNxgbqUl8VtvRLKQD5NvHQX6rQAlVKGAAAKS0cA= References: <4D9CDADD.1020403@cisco.com><4DA2FC17.1060100@cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD06009405@XMB-BGL-417.cisco.com> From: "Muthu ArulMozhi Perumal (mperumal)" To: "Ram Mohan R (rmohanr)" , "Paul Kyzivat (pkyzivat)" , "Elwell, John" X-OriginalArrivalTime: 12 Apr 2011 08:21:31.0042 (UTC) FILETIME=[A0962020:01CBF8EA] Cc: siprec@ietf.org Subject: Re: [siprec] start/stop times & the metamodel X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2011 08:21:35 -0000 |I agree on sending information of when a participant start/stop=20 |sending media [ from SRC perspective - what SRC sees] in the=20 |metadata. Do we really need reporting Changes to the media=20 |streams of CS like send, receive, inactive ? Aren't they related? If a participant goes recvonly or inactive it is an indication that he isn't going to send anything, so SRS might want to know this in order to pause recording the media stream coming from that participant and save some disk space -- might be useful in environment where occasional small clips in the recorded stream isn't a problem. An alternative is for the SRC to run media activity/inactivity detection and report it to the SRS (which can also suffer from media clipping). However, not every SRC might be capable of doing this. Muthu |-----Original Message----- |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Ram Mohan R (rmohanr) |Sent: Tuesday, April 12, 2011 1:17 PM |To: Paul Kyzivat (pkyzivat); Elwell, John |Cc: siprec@ietf.org |Subject: Re: [siprec] start/stop times & the metamodel | |Inline |A comment on this mail | | |> -----Original Message----- |> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On |> Behalf Of Paul Kyzivat (pkyzivat) |> Sent: Monday, April 11, 2011 6:33 PM |> To: Elwell, John |> Cc: siprec@ietf.org |> Subject: Re: [siprec] start/stop times & the metamodel |> |> |> |> On 4/8/2011 11:53 AM, Elwell, John wrote: |> > Paul, |> > |> > I think much of what you say makes sense. I was concerned that we |> probably need to record when a participant stops or starts sending or |> receiving a stream, which seems to be covered by your statement: |> "Changes to media streams should similarly be tagged with the time |they |> occurred in the CS signaling. Each participant relationship change |> (send, receive, inactive,) will be there." That doesn't seem to be in |> the model at present. | |I agree on sending information of when a participant start/stop sending |media [ from SRC perspective - what SRC sees] in the metadata. Do we |really need reporting Changes to the media streams of CS like send, |receive, inactive ? This would again go back to sending portions of CS |SDP [ in this case direction attribute] in metadata. | |Ram | |> |> John, |> |> I agree the current model doesn't reflect this - it was a private |> thought by me, provoked by the work and discussion to date. It is a |bit |> of a change of direction, so I'm interested in what others think about |> it. |> |> Thanks, |> Paul |> |> > John (as individual) |> > |> > |> >> -----Original Message----- |> >> From: siprec-bounces@ietf.org |> >> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat |> >> Sent: 06 April 2011 22:28 |> >> To: siprec@ietf.org |> >> Subject: [siprec] start/stop times& the metamodel |> >> |> >> In Prague, one of the open issues was around start/stop times. The |> >> format draft floated the possibility of having explicit |> >> start/stop times |> >> signaled for each of the metatdata elements. But then we asked for |> >> feedback on which make sense. |> >> |> >> IMO explicit start/stop times make more sense for some things |> >> than others. |> >> |> >> One place where we potentially have explicit times to report with |> the |> >> dialogs that constitute a CS. Each such dialog presumably has a |> start |> >> and stop time observable by the SRC, which might differ, at |> >> least a bit, |> >> from the corresponding signaling on the RS. |> >> |> >> We might want to report those times. Or, since we abstract |> >> the CS away |> >> from the dialog, we might want to report the start time of the |first |> >> dialog in the CS as the CS start time, and the stop time of the |last |> >> dialog in the CS as the CS stop time. |> >> |> >> Similarly, we have abstracted media streams away from the |> >> media streams |> >> in the sip dialogs that make up the CS. We might want to report the |> >> start time of a media stream as the time (according to the CS) of |> the |> >> first participant to a new media stream, and the stop time as |> >> the time |> >> that the last participant leaves the media stream. |> >> |> >> There are several things that complicate this: |> >> |> >> - Do we consider the case of a stream that starts with recvonly |> >> or inactive participants, and only later gets a sender? If so, |> >> is the start time of the stream when the first participant |> arrived, |> >> or when the first sender arrived? |> >> |> >> - How do we get the clock times for the media streams? |> >> IIUC the correct ones are in the RTP/RTCP, but the reporting of |> >> these events is driven by the signaling, and we don't have good |> >> sync between those. (E.g. media could start flowing before the |> >> corresponding signaling, and we would like to include that if |we |> >> can figure it out.) So, even if the clocks used for media and |> >> signaling are in sync, we might see media packets arrive with |> >> a timestamp prior to the timestamp for the signaling that |> >> indicates the send state of the participant. This could cause |> >> trouble in playback. |> >> |> >> - There isn't any guarantee that the clock used for signaling |> >> messages is synchronized with the clock used in RTP/RTCP. |> >> |> >> - There isn't any guarantee that there will be any RTCP at all, |> >> to provide correlation of the RTP to clocktime. |> >> |> >> The best I can see to deal with all of this is: |> >> |> >> - All the metadata messages should be timestamped by the SRC |> >> using its local clock. This is easily achieved by the Date |> >> header in the sip message. |> >> |> >> - Changes to a CS, including changes of participants, should |> >> be explicitly tagged with the time they occurred in the |> >> CS signaling, according to the SRC's clock. (If that is |> >> unavailable for some reason, then use the time the SRC |> >> became aware of it.) |> >> |> >> - We could provide a metadata update element to indicate end |> >> of a CS, but I suggest this just be shorthand for indicating |> >> removal of all participants from it. (While its possible to |> >> mark that the CS is truly ended, that simply introduces an |> >> error case if added metadata about it is subsequently sent.) |> >> The actual start/stop time would be determined by the SRS |> >> based on the timestamps of first and last data about it. |> >> |> >> - Changes to media streams should similarly be tagged with |> >> the time they occurred in the CS signaling. Each participant |> >> relationship change (send, receive, inactive,) will be there. |> >> The actual start/stop time of the media stream again would be |> >> derived by the SRS. |> >> |> >> - CS-Groups can simply be tagged by the timestamps of the |> >> updates that put CSs into them. Explicit start/stop times don't |> >> seem useful. If desired, the SRS can derive start/stop times |> >> from the start/stop times of the contained stuff. |> >> |> >> - I now think that CS-Groups should not be "contained" within |> >> a recording. This just seems to introduce unnecessary error |> >> conditions, and limitations on future enhancements. The |> >> lifetime of CS-Groups will probably be naturally limited by |> >> the ability of the SRC to remember the IDs of old ones. |> >> For instance, if a CS-G is created during one Recording, |> >> and then another CS is added to it from a different recording |> >> session, would we prefer to fail that, or just allow it? |> >> (I think allow.) |> >> |> >> - Rather, I think every update transmitted during a recording |> >> session can be tagged with a link to the metadata of the |> >> recording session it came from. This need not be explicit - the |> >> SRS can do it automatically. The recording session entity |> >> itself will also have a start/stop time which is the start/ |> >> stop of the RS dialog as observed by the SRS. |> >> |> >> (Note the above doesn't solve the problem of getting correct |> >> clock times |> >> for RTP media. If anyone has a suggestion for this I'm all ears.) |> >> |> >> Thanks, |> >> Paul |> >> _______________________________________________ |> >> siprec mailing list |> >> siprec@ietf.org |> >> https://www.ietf.org/mailman/listinfo/siprec |> >> |> _______________________________________________ |> siprec mailing list |> siprec@ietf.org |> https://www.ietf.org/mailman/listinfo/siprec |_______________________________________________ |siprec mailing list |siprec@ietf.org |https://www.ietf.org/mailman/listinfo/siprec From rmohanr@cisco.com Tue Apr 12 01:47:11 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5E2CEE06AC for ; Tue, 12 Apr 2011 01:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AyY5jFlLaesW for ; Tue, 12 Apr 2011 01:47:10 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfc.amsl.com (Postfix) with ESMTP id 9887BE06B6 for ; Tue, 12 Apr 2011 01:47:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=9898; q=dns/txt; s=iport; t=1302598029; x=1303807629; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=lW6ZzD016MExhdABp/gGHBl3bhGTUnHwmfNNjRIMsYg=; b=Dt/L0j5gds3c+hkyJT9z4wxH2ew+zYEV9HcT/V0TPZxyRP+sdn9e1SDI U9FPobz/pbUvzbCDygm3xyql+7ndOTixUd35VZ3akNTlm9lxHq146d0WC Ls9HT6UVfnlrvTFXuEUREy5sRrxhCs1ZgpDW1SMMOri7AVid+H5Tr4yon s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjkBAKoQpE2Q/khR/2dsb2JhbACYQ41cd4h6nDuccYMAgm4EhVmLew X-IronPort-AV: E=Sophos;i="4.64,194,1301875200"; d="scan'208";a="25362126" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 12 Apr 2011 08:47:08 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3C8l71F010287; Tue, 12 Apr 2011 08:47:08 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, 12 Apr 2011 14:17:07 +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, 12 Apr 2011 14:17:05 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD06009443@XMB-BGL-417.cisco.com> In-Reply-To: <1D062974A4845E4D8A343C65380492020533B590@XMB-BGL-414.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] start/stop times & the metamodel Thread-Index: Acv4SNxgbqUl8VtvRLKQD5NvHQX6rQAlVKGAAAKS0cAAAV1ToA== References: <4D9CDADD.1020403@cisco.com><4DA2FC17.1060100@cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD06009405@XMB-BGL-417.cisco.com> <1D062974A4845E4D8A343C65380492020533B590@XMB-BGL-414.cisco.com> From: "Ram Mohan R (rmohanr)" To: "Muthu ArulMozhi Perumal (mperumal)" , "Paul Kyzivat (pkyzivat)" , "Elwell, John" X-OriginalArrivalTime: 12 Apr 2011 08:47:07.0161 (UTC) FILETIME=[342F4890:01CBF8EE] Cc: siprec@ietf.org Subject: Re: [siprec] start/stop times & the metamodel X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2011 08:47:11 -0000 Inline > -----Original Message----- > From: Muthu ArulMozhi Perumal (mperumal) > Sent: Tuesday, April 12, 2011 1:51 PM > To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat); Elwell, John > Cc: siprec@ietf.org > Subject: RE: [siprec] start/stop times & the metamodel >=20 > |I agree on sending information of when a participant start/stop > |sending media [ from SRC perspective - what SRC sees] in the > |metadata. Do we really need reporting Changes to the media > |streams of CS like send, receive, inactive ? >=20 > Aren't they related? If a participant goes recvonly or inactive it is > an indication that he isn't going to send anything, so SRS might want > to know this in order to pause recording the media stream coming from > that participant and save some disk space -- might be useful in > environment where occasional small clips in the recorded stream isn't a > problem. An alternative is for the SRC to run media activity/inactivity > detection and report it to the SRS (which can also suffer from media > clipping). However, not every SRC might be capable of doing this. SRC to SRS indication of participant hold/resume can happen through updates in RS SIP dialog. What I am asking here is if there is a need to report the original CS SDP media params (say direction attribute) explicitly in the metadata to RS. Ram >=20 > Muthu >=20 > |-----Original Message----- > |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Ram Mohan R (rmohanr) > |Sent: Tuesday, April 12, 2011 1:17 PM > |To: Paul Kyzivat (pkyzivat); Elwell, John > |Cc: siprec@ietf.org > |Subject: Re: [siprec] start/stop times & the metamodel > | > |Inline > |A comment on this mail > | > | > |> -----Original Message----- > |> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > |> Behalf Of Paul Kyzivat (pkyzivat) > |> Sent: Monday, April 11, 2011 6:33 PM > |> To: Elwell, John > |> Cc: siprec@ietf.org > |> Subject: Re: [siprec] start/stop times & the metamodel > |> > |> > |> > |> On 4/8/2011 11:53 AM, Elwell, John wrote: > |> > Paul, > |> > > |> > I think much of what you say makes sense. I was concerned that we > |> probably need to record when a participant stops or starts sending > or > |> receiving a stream, which seems to be covered by your statement: > |> "Changes to media streams should similarly be tagged with the time > |they > |> occurred in the CS signaling. Each participant relationship change > |> (send, receive, inactive,) will be there." That doesn't seem to be > in > |> the model at present. > | > |I agree on sending information of when a participant start/stop > sending > |media [ from SRC perspective - what SRC sees] in the metadata. Do we > |really need reporting Changes to the media streams of CS like send, > |receive, inactive ? This would again go back to sending portions of CS > |SDP [ in this case direction attribute] in metadata. > | > |Ram > | > |> > |> John, > |> > |> I agree the current model doesn't reflect this - it was a private > |> thought by me, provoked by the work and discussion to date. It is a > |bit > |> of a change of direction, so I'm interested in what others think > about > |> it. > |> > |> Thanks, > |> Paul > |> > |> > John (as individual) > |> > > |> > > |> >> -----Original Message----- > |> >> From: siprec-bounces@ietf.org > |> >> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > |> >> Sent: 06 April 2011 22:28 > |> >> To: siprec@ietf.org > |> >> Subject: [siprec] start/stop times& the metamodel > |> >> > |> >> In Prague, one of the open issues was around start/stop times. > The > |> >> format draft floated the possibility of having explicit > |> >> start/stop times > |> >> signaled for each of the metatdata elements. But then we asked > for > |> >> feedback on which make sense. > |> >> > |> >> IMO explicit start/stop times make more sense for some things > |> >> than others. > |> >> > |> >> One place where we potentially have explicit times to report with > |> the > |> >> dialogs that constitute a CS. Each such dialog presumably has a > |> start > |> >> and stop time observable by the SRC, which might differ, at > |> >> least a bit, > |> >> from the corresponding signaling on the RS. > |> >> > |> >> We might want to report those times. Or, since we abstract > |> >> the CS away > |> >> from the dialog, we might want to report the start time of the > |first > |> >> dialog in the CS as the CS start time, and the stop time of the > |last > |> >> dialog in the CS as the CS stop time. > |> >> > |> >> Similarly, we have abstracted media streams away from the > |> >> media streams > |> >> in the sip dialogs that make up the CS. We might want to report > the > |> >> start time of a media stream as the time (according to the CS) of > |> the > |> >> first participant to a new media stream, and the stop time as > |> >> the time > |> >> that the last participant leaves the media stream. > |> >> > |> >> There are several things that complicate this: > |> >> > |> >> - Do we consider the case of a stream that starts with recvonly > |> >> or inactive participants, and only later gets a sender? If > so, > |> >> is the start time of the stream when the first participant > |> arrived, > |> >> or when the first sender arrived? > |> >> > |> >> - How do we get the clock times for the media streams? > |> >> IIUC the correct ones are in the RTP/RTCP, but the reporting > of > |> >> these events is driven by the signaling, and we don't have > good > |> >> sync between those. (E.g. media could start flowing before > the > |> >> corresponding signaling, and we would like to include that if > |we > |> >> can figure it out.) So, even if the clocks used for media and > |> >> signaling are in sync, we might see media packets arrive with > |> >> a timestamp prior to the timestamp for the signaling that > |> >> indicates the send state of the participant. This could cause > |> >> trouble in playback. > |> >> > |> >> - There isn't any guarantee that the clock used for signaling > |> >> messages is synchronized with the clock used in RTP/RTCP. > |> >> > |> >> - There isn't any guarantee that there will be any RTCP at all, > |> >> to provide correlation of the RTP to clocktime. > |> >> > |> >> The best I can see to deal with all of this is: > |> >> > |> >> - All the metadata messages should be timestamped by the SRC > |> >> using its local clock. This is easily achieved by the Date > |> >> header in the sip message. > |> >> > |> >> - Changes to a CS, including changes of participants, should > |> >> be explicitly tagged with the time they occurred in the > |> >> CS signaling, according to the SRC's clock. (If that is > |> >> unavailable for some reason, then use the time the SRC > |> >> became aware of it.) > |> >> > |> >> - We could provide a metadata update element to indicate end > |> >> of a CS, but I suggest this just be shorthand for indicating > |> >> removal of all participants from it. (While its possible to > |> >> mark that the CS is truly ended, that simply introduces an > |> >> error case if added metadata about it is subsequently sent.) > |> >> The actual start/stop time would be determined by the SRS > |> >> based on the timestamps of first and last data about it. > |> >> > |> >> - Changes to media streams should similarly be tagged with > |> >> the time they occurred in the CS signaling. Each participant > |> >> relationship change (send, receive, inactive,) will be there. > |> >> The actual start/stop time of the media stream again would be > |> >> derived by the SRS. > |> >> > |> >> - CS-Groups can simply be tagged by the timestamps of the > |> >> updates that put CSs into them. Explicit start/stop times > don't > |> >> seem useful. If desired, the SRS can derive start/stop times > |> >> from the start/stop times of the contained stuff. > |> >> > |> >> - I now think that CS-Groups should not be "contained" within > |> >> a recording. This just seems to introduce unnecessary error > |> >> conditions, and limitations on future enhancements. The > |> >> lifetime of CS-Groups will probably be naturally limited by > |> >> the ability of the SRC to remember the IDs of old ones. > |> >> For instance, if a CS-G is created during one Recording, > |> >> and then another CS is added to it from a different recording > |> >> session, would we prefer to fail that, or just allow it? > |> >> (I think allow.) > |> >> > |> >> - Rather, I think every update transmitted during a recording > |> >> session can be tagged with a link to the metadata of the > |> >> recording session it came from. This need not be explicit - > the > |> >> SRS can do it automatically. The recording session entity > |> >> itself will also have a start/stop time which is the start/ > |> >> stop of the RS dialog as observed by the SRS. > |> >> > |> >> (Note the above doesn't solve the problem of getting correct > |> >> clock times > |> >> for RTP media. If anyone has a suggestion for this I'm all ears.) > |> >> > |> >> Thanks, > |> >> Paul > |> >> _______________________________________________ > |> >> siprec mailing 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 mperumal@cisco.com Tue Apr 12 02:20:23 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DC044E06B6 for ; Tue, 12 Apr 2011 02:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.536 X-Spam-Level: X-Spam-Status: No, score=-9.536 tagged_above=-999 required=5 tests=[AWL=1.063, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id byshWpb4foxk for ; Tue, 12 Apr 2011 02:20:21 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfc.amsl.com (Postfix) with ESMTP id D2A57E0613 for ; Tue, 12 Apr 2011 02:20:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=11183; q=dns/txt; s=iport; t=1302600021; x=1303809621; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=7Nx97AavBDCrplH+EtuWDHYbS/06A7MixH8a9TiUQfg=; b=e9kW7ECK3MdKVm+rvrrU7HdCujwXXLip+ZirQRzNqz7xSYn3R3Qm+Pph QkCDx+9hXCN0g5iOwdB8TW4GBBzdlVwyO/VbzbbmYELYSIWZJGqZOAwRG 8HWcfzzJ0pKHntEuuU/iSQWqsmXzwNtJ9vWhvGth+EvTzX2bYkIo0aXqo k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4AAOcYpE2Q/khLgWdsb2JhbACYQ41cFAEBFiYlpQeccIMAgm4EhVmLew X-IronPort-AV: E=Sophos;i="4.64,194,1301875200"; d="scan'208";a="25368479" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 12 Apr 2011 09:20:18 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3C9Jt2Y019450; Tue, 12 Apr 2011 09:20:18 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Apr 2011 14:50:17 +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, 12 Apr 2011 14:50:16 +0530 Message-ID: <1D062974A4845E4D8A343C65380492020533B5BE@XMB-BGL-414.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD06009443@XMB-BGL-417.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] start/stop times & the metamodel Thread-Index: Acv4SNxgbqUl8VtvRLKQD5NvHQX6rQAlVKGAAAKS0cAAAV1ToAAAMo/Q References: <4D9CDADD.1020403@cisco.com><4DA2FC17.1060100@cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD06009405@XMB-BGL-417.cisco.com> <1D062974A4845E4D8A343C65380492020533B590@XMB-BGL-414.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD06009443@XMB-BGL-417.cisco.com> From: "Muthu ArulMozhi Perumal (mperumal)" To: "Ram Mohan R (rmohanr)" , "Paul Kyzivat (pkyzivat)" , "Elwell, John" X-OriginalArrivalTime: 12 Apr 2011 09:20:17.0121 (UTC) FILETIME=[D64B1510:01CBF8F2] Cc: siprec@ietf.org Subject: Re: [siprec] start/stop times & the metamodel X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2011 09:20:24 -0000 |SRC to SRS indication of participant hold/resume can=20 |happen through updates in RS SIP dialog. What I am=20 |asking here is if there is a need to report the original=20 |CS SDP media params (say direction attribute) explicitly=20 |in the metadata to RS. The SRC might have its own policy of when (and when not) to pause the recording, which it can achieve through the RS dialog. The SRS on the other hand might also have policies on when (and when not) to record based on the participants media state. So, I see it might be useful to convey this information in metadata if the SRS wants to take decisions independent of the SRC. Also, since only metadata is persistent, making it available in metadata might be handy for the SRS, for future interpretation. Muthu |-----Original Message----- |From: Ram Mohan R (rmohanr) |Sent: Tuesday, April 12, 2011 2:17 PM |To: Muthu ArulMozhi Perumal (mperumal); Paul Kyzivat (pkyzivat); 'Elwell, John' |Cc: 'siprec@ietf.org' |Subject: RE: [siprec] start/stop times & the metamodel | |Inline | |> -----Original Message----- |> From: Muthu ArulMozhi Perumal (mperumal) |> Sent: Tuesday, April 12, 2011 1:51 PM |> To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat); Elwell, John |> Cc: siprec@ietf.org |> Subject: RE: [siprec] start/stop times & the metamodel |> |> |I agree on sending information of when a participant start/stop |> |sending media [ from SRC perspective - what SRC sees] in the |> |metadata. Do we really need reporting Changes to the media |> |streams of CS like send, receive, inactive ? |> |> Aren't they related? If a participant goes recvonly or inactive it is |> an indication that he isn't going to send anything, so SRS might want |> to know this in order to pause recording the media stream coming from |> that participant and save some disk space -- might be useful in |> environment where occasional small clips in the recorded stream isn't a |> problem. An alternative is for the SRC to run media activity/inactivity |> detection and report it to the SRS (which can also suffer from media |> clipping). However, not every SRC might be capable of doing this. | |SRC to SRS indication of participant hold/resume can happen through updates in RS SIP dialog. What I |am asking here is if there is a need to report the original CS SDP media params (say direction |attribute) explicitly in the metadata to RS. | |Ram | |> |> Muthu |> |> |-----Original Message----- |> |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On |> Behalf Of Ram Mohan R (rmohanr) |> |Sent: Tuesday, April 12, 2011 1:17 PM |> |To: Paul Kyzivat (pkyzivat); Elwell, John |> |Cc: siprec@ietf.org |> |Subject: Re: [siprec] start/stop times & the metamodel |> | |> |Inline |> |A comment on this mail |> | |> | |> |> -----Original Message----- |> |> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On |> |> Behalf Of Paul Kyzivat (pkyzivat) |> |> Sent: Monday, April 11, 2011 6:33 PM |> |> To: Elwell, John |> |> Cc: siprec@ietf.org |> |> Subject: Re: [siprec] start/stop times & the metamodel |> |> |> |> |> |> |> |> On 4/8/2011 11:53 AM, Elwell, John wrote: |> |> > Paul, |> |> > |> |> > I think much of what you say makes sense. I was concerned that we |> |> probably need to record when a participant stops or starts sending |> or |> |> receiving a stream, which seems to be covered by your statement: |> |> "Changes to media streams should similarly be tagged with the time |> |they |> |> occurred in the CS signaling. Each participant relationship change |> |> (send, receive, inactive,) will be there." That doesn't seem to be |> in |> |> the model at present. |> | |> |I agree on sending information of when a participant start/stop |> sending |> |media [ from SRC perspective - what SRC sees] in the metadata. Do we |> |really need reporting Changes to the media streams of CS like send, |> |receive, inactive ? This would again go back to sending portions of CS |> |SDP [ in this case direction attribute] in metadata. |> | |> |Ram |> | |> |> |> |> John, |> |> |> |> I agree the current model doesn't reflect this - it was a private |> |> thought by me, provoked by the work and discussion to date. It is a |> |bit |> |> of a change of direction, so I'm interested in what others think |> about |> |> it. |> |> |> |> Thanks, |> |> Paul |> |> |> |> > John (as individual) |> |> > |> |> > |> |> >> -----Original Message----- |> |> >> From: siprec-bounces@ietf.org |> |> >> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat |> |> >> Sent: 06 April 2011 22:28 |> |> >> To: siprec@ietf.org |> |> >> Subject: [siprec] start/stop times& the metamodel |> |> >> |> |> >> In Prague, one of the open issues was around start/stop times. |> The |> |> >> format draft floated the possibility of having explicit |> |> >> start/stop times |> |> >> signaled for each of the metatdata elements. But then we asked |> for |> |> >> feedback on which make sense. |> |> >> |> |> >> IMO explicit start/stop times make more sense for some things |> |> >> than others. |> |> >> |> |> >> One place where we potentially have explicit times to report with |> |> the |> |> >> dialogs that constitute a CS. Each such dialog presumably has a |> |> start |> |> >> and stop time observable by the SRC, which might differ, at |> |> >> least a bit, |> |> >> from the corresponding signaling on the RS. |> |> >> |> |> >> We might want to report those times. Or, since we abstract |> |> >> the CS away |> |> >> from the dialog, we might want to report the start time of the |> |first |> |> >> dialog in the CS as the CS start time, and the stop time of the |> |last |> |> >> dialog in the CS as the CS stop time. |> |> >> |> |> >> Similarly, we have abstracted media streams away from the |> |> >> media streams |> |> >> in the sip dialogs that make up the CS. We might want to report |> the |> |> >> start time of a media stream as the time (according to the CS) of |> |> the |> |> >> first participant to a new media stream, and the stop time as |> |> >> the time |> |> >> that the last participant leaves the media stream. |> |> >> |> |> >> There are several things that complicate this: |> |> >> |> |> >> - Do we consider the case of a stream that starts with recvonly |> |> >> or inactive participants, and only later gets a sender? If |> so, |> |> >> is the start time of the stream when the first participant |> |> arrived, |> |> >> or when the first sender arrived? |> |> >> |> |> >> - How do we get the clock times for the media streams? |> |> >> IIUC the correct ones are in the RTP/RTCP, but the reporting |> of |> |> >> these events is driven by the signaling, and we don't have |> good |> |> >> sync between those. (E.g. media could start flowing before |> the |> |> >> corresponding signaling, and we would like to include that if |> |we |> |> >> can figure it out.) So, even if the clocks used for media and |> |> >> signaling are in sync, we might see media packets arrive with |> |> >> a timestamp prior to the timestamp for the signaling that |> |> >> indicates the send state of the participant. This could cause |> |> >> trouble in playback. |> |> >> |> |> >> - There isn't any guarantee that the clock used for signaling |> |> >> messages is synchronized with the clock used in RTP/RTCP. |> |> >> |> |> >> - There isn't any guarantee that there will be any RTCP at all, |> |> >> to provide correlation of the RTP to clocktime. |> |> >> |> |> >> The best I can see to deal with all of this is: |> |> >> |> |> >> - All the metadata messages should be timestamped by the SRC |> |> >> using its local clock. This is easily achieved by the Date |> |> >> header in the sip message. |> |> >> |> |> >> - Changes to a CS, including changes of participants, should |> |> >> be explicitly tagged with the time they occurred in the |> |> >> CS signaling, according to the SRC's clock. (If that is |> |> >> unavailable for some reason, then use the time the SRC |> |> >> became aware of it.) |> |> >> |> |> >> - We could provide a metadata update element to indicate end |> |> >> of a CS, but I suggest this just be shorthand for indicating |> |> >> removal of all participants from it. (While its possible to |> |> >> mark that the CS is truly ended, that simply introduces an |> |> >> error case if added metadata about it is subsequently sent.) |> |> >> The actual start/stop time would be determined by the SRS |> |> >> based on the timestamps of first and last data about it. |> |> >> |> |> >> - Changes to media streams should similarly be tagged with |> |> >> the time they occurred in the CS signaling. Each participant |> |> >> relationship change (send, receive, inactive,) will be there. |> |> >> The actual start/stop time of the media stream again would be |> |> >> derived by the SRS. |> |> >> |> |> >> - CS-Groups can simply be tagged by the timestamps of the |> |> >> updates that put CSs into them. Explicit start/stop times |> don't |> |> >> seem useful. If desired, the SRS can derive start/stop times |> |> >> from the start/stop times of the contained stuff. |> |> >> |> |> >> - I now think that CS-Groups should not be "contained" within |> |> >> a recording. This just seems to introduce unnecessary error |> |> >> conditions, and limitations on future enhancements. The |> |> >> lifetime of CS-Groups will probably be naturally limited by |> |> >> the ability of the SRC to remember the IDs of old ones. |> |> >> For instance, if a CS-G is created during one Recording, |> |> >> and then another CS is added to it from a different recording |> |> >> session, would we prefer to fail that, or just allow it? |> |> >> (I think allow.) |> |> >> |> |> >> - Rather, I think every update transmitted during a recording |> |> >> session can be tagged with a link to the metadata of the |> |> >> recording session it came from. This need not be explicit - |> the |> |> >> SRS can do it automatically. The recording session entity |> |> >> itself will also have a start/stop time which is the start/ |> |> >> stop of the RS dialog as observed by the SRS. |> |> >> |> |> >> (Note the above doesn't solve the problem of getting correct |> |> >> clock times |> |> >> for RTP media. If anyone has a suggestion for this I'm all ears.) |> |> >> |> |> >> Thanks, |> |> >> Paul |> |> >> _______________________________________________ |> |> >> siprec mailing list |> |> >> siprec@ietf.org |> |> >> https://www.ietf.org/mailman/listinfo/siprec |> |> >> |> |> _______________________________________________ |> |> siprec mailing list |> |> siprec@ietf.org |> |> https://www.ietf.org/mailman/listinfo/siprec |> |_______________________________________________ |> |siprec mailing list |> |siprec@ietf.org |> |https://www.ietf.org/mailman/listinfo/siprec From rmohanr@cisco.com Tue Apr 12 02:34:48 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 568BFE06A2 for ; Tue, 12 Apr 2011 02:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.699 X-Spam-Level: X-Spam-Status: No, score=-9.699 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWmcSvTR2BOk for ; Tue, 12 Apr 2011 02:34:45 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfc.amsl.com (Postfix) with ESMTP id D538CE0692 for ; Tue, 12 Apr 2011 02:34:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=22521; q=dns/txt; s=iport; t=1302600884; x=1303810484; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=ZxvRCTrA4oKsK4BR4M6JpQXMjyL6uXLn7zV4+9gxBI4=; b=DwzLFdKzMGOtLGO1ukTuhCYVW4tITPP6ZKUB3tBgHdbttZdli8Psf85t h72b49aQrkFLbKI8CzqqC6BdxKiTcI75xWpkV77U+pM0l1VKTjTQOG7Hr pXIrtAcMar9ASR6tOuyyDVoEG7IhfkWww9J9BunrB+6ANbmgmgrt/cN2J w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4AALQbpE2Q/khLgWdsb2JhbACYQ41cFAEBFiYliHqcB5xwgn+CbwSFWYt7 X-IronPort-AV: E=Sophos;i="4.64,194,1301875200"; d="scan'208";a="83208219" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 12 Apr 2011 09:34:43 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3C9YgJP025248; Tue, 12 Apr 2011 09:34:43 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, 12 Apr 2011 15:04:41 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-hashedpuzzle: A2h+ CYdG C9/W Di/d EEyP EKaD EtdF FwxM GAVV KhmG My87 N0Ce OOqR PHoP RDD1 Wlp5; 2; agBvAGgAbgAuAGUAbAB3AGUAbABsAEAAcwBpAGUAbQBlAG4AcwAtAGUAbgB0AGUAcgBwAHIAaQBzAGUALgBjAG8AbQA7AHMAaQBwAHIAZQBjAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {6D79B7F3-CED0-43F9-8FB1-25C905157DE6}; cgBtAG8AaABhAG4AcgBAAGMAaQBzAGMAbwAuAGMAbwBtAA==; Tue, 12 Apr 2011 09:34:24 GMT; RABvACAAdwBlACAAbgBlAGUAZAAgAHQAbwAgAG0AbwBkAGUAbAAgAHAAYQByAHQAaQBjAGkAcABhAG4AdABzACAAbgBvAHQAIABwAGEAcgB0ACAAbwBmACAAQwBTACAAYgB1AHQAIABhAHMAcwBvAGMAaQBhAHQAZQBkACAAdwBpAHQAaAAgAE0AZQBkAGkAYQAgAFMAdAByAGUAYQBtACAAYgBsAG8AYwBrACAAaQBuACAAdABoAGUAIABtAGUAdABhAGQAYQB0AGEAIABtAG8AZABlAGwAIAA/ACAAKAAgAHcAYQBzACAAUgBFADoAIABbAHMAaQBwAHIAZQBjAF0AIABQAGEAcgB0AGkAYQBsACAAdQBwAGQAYQB0AGUAcwAgAGEAbgBkACAAaQBkAGUAbgB0AGkAZgBpAGUAcgBzACkA x-cr-puzzleid: {6D79B7F3-CED0-43F9-8FB1-25C905157DE6} Content-class: urn:content-classes:message Date: Tue, 12 Apr 2011 15:04:24 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD06009482@XMB-BGL-417.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Do we need to model participants not part of CS but associated with Media Stream block in the metadata model ? ( was RE: [siprec] Partial updates and identifiers) Thread-Index: Acv0jVXI4ji2YTo+SquJ6T6YR3i+lQAdOkDgAEETmvAAg54qsAADKDEgAADSn+AAEAO1UAANZylQABBzW2AABHtBwA== References: <4D9CB8E1.7030402@cisco.com> From: "Ram Mohan R (rmohanr)" To: "Elwell, John" , "Charles Eckel (eckelcu)" , "Parthasarathi R (partr)" , "Paul Kyzivat (pkyzivat)" , X-OriginalArrivalTime: 12 Apr 2011 09:34:41.0882 (UTC) FILETIME=[D9BB23A0:01CBF8F4] Cc: "Peter Saint-Andre \(psaintan\)" , "Joe Hildebrand \(jhildebr\)" Subject: [siprec] Do we need to model participants not part of CS but associated with Media Stream block in the metadata model ? ( was RE: Partial updates and identifiers) X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2011 09:34:48 -0000 Renaming the mail thread to discussion to this specific issue - "Metadata for participants not part of CS" which we have been discussing from several weeks. Please continue the other issues in original thread and lets use this thread to close this issue. I would request people to give inputs for this issue on this thread and take it to a conclusion. We(Authors of Metadata model) included participants that are not part of CS to imply: - Participants that does NOT contribute to signaling in CS but contributes to media=20 The intent is to give more flexibility in the metamodel to represent these types of participants. Following are some of use case where this can happen- Use-Case 1: A conference where one of the participants is a SRC. In these case the Focus which talks to this SRC becomes part of CS contributing signaling as well as media. However the media includes media from other participants that are not part of CS. Please note SRC has to subscribe to conf event packet to get this information (which may not be always feasible). Use-Case 2: one UA in CS works in 3pcc mode to acquire an MoH media stream, this might be reflected as unique source for media stream without having a reported signaling relationship to it. E.g is given here by Henry Lum http://www.ietf.org/mail-archive/web/siprec/current/msg01372.html In some sense these participants are *still* part of CS as they contribute to CS media. There are three approaches I can see- Don't model the participants that does not contribute signaling in CS and only contribute Media Model these participants as not part of CS in the model but associated with Media Stream block ( current approach) Model these participants to be associated with CS but have the association labeled as "indirect participant"=20 Let me know your thoughts. Thanks, Ram > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Elwell, John > Sent: Tuesday, April 12, 2011 12:13 PM > To: Charles Eckel (eckelcu); Parthasarathi R (partr); Paul Kyzivat > (pkyzivat); siprec@ietf.org > Cc: Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr) > Subject: Re: [siprec] Partial updates and identifiers >=20 > I think the attached message was the last in that thread. So I don't > really think we had closure. >=20 > John >=20 > > -----Original Message----- > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > Sent: 11 April 2011 23:53 > > To: Elwell, John; Parthasarathi R (partr); Paul Kyzivat (pkyzivat); > > siprec@ietf.org > > Cc: Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr); Hadriel > > Kaplan > > Subject: RE: [siprec] Partial updates and identifiers > > > > Hi John, > > > > I have attached the last e-mail I have from the thread in which I > > first raised this issue. Unfortunately, I do not have the e-mail with > > the ultimate agreement, but maybe someone else does or this will help > > prompt some memories. > > > > Cheers, > > Charles > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Elwell, John > > > Sent: Monday, April 11, 2011 9:46 AM > > > To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); > > siprec@ietf.org > > > Cc: Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr); > Hadriel > > Kaplan > > > Subject: Re: [siprec] Partial updates and identifiers > > > > > > Partha, > > > > > > Thanks for reminding me - I now recall the discussion some > > weeks/months ago about the participants > > > obtained from the conference event package. I was never > particularly > > comfortable with the fact these > > > were not considered part of the CS. While that might be > > correct if we > > consider the CS to be the SIP > > > dialog between the SRC and the conference focus, taking a > > broader view > > of CS those participants behind > > > the focus could be considered part of the CS. I don't particularly > > want to open up the old discussion > > > if people are happy with what we have, but something doesn't seem > > quite right to me. > > > > > > For example, if these "participants" are not considered part of the > > CS, and if we don't have specific > > > information about their involvement in media streams, do they > really > > merit being considered > > > Participant objects? > > > > > > In other words, two possible approaches are: > > > > > > 1) The CS extends only as far as the focus / mixer. The > > focus/mixer is > > a "Participant" and the users > > > behind the focus are not separate Participants but are just > > additional > > data associated with the > > > focus/mixer Participant. The only Media Streams we are > > concerned with > > are between the mixer and the > > > SRC. > > > > > > 2) The CS extends beyond the focus/mixer to users learned via the > > conference event package, each of > > > those users is a separate Participant object, and we are concerned > > with Media Stream objects that > > > those participants send and receive. I am not sure how feasible > this > > approach is, because I am not > > > sure that the SRC can obtain enough information about media > > streams at > > users behind the focus/mixer. > > > > > > It seems the present solution is somewhere between the two, which > is > > why I am uncomfortable. > > > > > > Regards, > > > > > > John (as individual) > > > > > > > > > > -----Original Message----- > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > Sent: 11 April 2011 10:29 > > > > To: Elwell, John; Paul Kyzivat (pkyzivat); siprec@ietf.org > > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe Hildebrand > > > > (jhildebr) > > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > > > John, > > > > > > > > Please read inline. > > > > > > > > Thanks > > > > Partha > > > > > > > > -----Original Message----- > > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > Sent: Monday, April 11, 2011 2:11 PM > > > > To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); > > siprec@ietf.org > > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe Hildebrand > > > > (jhildebr) > > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > > Sent: 11 April 2011 08:35 > > > > > To: Elwell, John; Paul Kyzivat (pkyzivat); siprec@ietf.org > > > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe > Hildebrand > > > > > (jhildebr) > > > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > > > > > John, > > > > > > > > > > As I mentioned below, stream block will be unique > > within CS, (not > > > > > required to be unique across multiple CS) and so, xml:id or > > > > enhancing > > > > > the normative statement of RFC 4574 label attribute to be > unique > > > > > within CS will serve the purpose. I'm fine with any of the > above > > > > > mentioned id. > > > > > Please note that RFC 4574 "label" attribute is the nature > > > > data for RS > > > > > dialog. > > > > > > > > > > In case participant within CS, xml:id will serve the purpose > but > > we > > > > > need to get more clarity about participants who are not > > > > part of CS but > > > > > > > > > within RS. > > > > [JRE] If I understand the figure in section 3 of metadata-04 > > > > correctly, a Participant can have a relationship with a CS, but > no > > > > direct relationship with an RS. > > > > > > > > Sorry, I mixed up my statement with the latest update of > > > > making CSG optional. As per Sec 3 of metadata-04, participant has > > > > direct relationship with CSG in case CS is left completely > > > > unattached. In case CSG is optional, then participant will have > > > > direct relationship with RS in case there is no relationship > > > > between CS and participant. > > > > > > > > > > > > So a participant that does not have a relationship with a CS is > > left > > > > completely unattached, unless it has a relationship with a Media > > > > Stream (which always has a relationship with a CS). So to > > > > summarize: > > > > - a Participant can have a direct relationship with a CS; or > > > > - a Participant can have an indirect relationship with a CS (via > a > > > > Media Stream); agreed > > > > - a Participant can have no relationship with a CS, and > > therefore no > > > > relationship with an RS. > > > > Do we really need this last case? > > > > > > > > I'm happy if the last case is not required because it > > > > simplify the solution and there is no need of unique id for > > > > participant. But SRS implementers may prefer to have relationship > > > > with participant and RS. I wish more opinion before taking > > > > decision whether to remove the last case > > > > > > > > > Because CS may span across different RS how about the > > > > participant who > > > > > are not part of CS? > > > > [JRE] I don't understand the words "Because CS may span across > > > > different RS", because in the rest of the sentence you are > talking > > > > about a Participant that is not part of a CS. > > > > > > > > > Ex: One of the user in the conference acts as SRC, fetch > > > > participant > > > > > info using conferene package and new RS is created > > during initial > > > > > conference creation and hold&resume of a user within CS. > > > > [JRE] I am not sure what you are trying to say here. I would > > > > consider a user whose identity is obtained via a conference event > > > > package as being part of the CS. > > > > > > > > I'm trying to give the example where participant is not > > > > associated with CS directly but related to CSG (/RS). This > > > > scenario was considered as a blocking in -03 version of metadata. > > > > I'm not arguing to have this scenario but it is major concern for > > > > few folks. > > > > > > > > CS is between focus and UA, UA acts as SRC, UA receives the > > > > participant info via conference event package but those > > > > participants are not related in CS directly (and only focus is > > > > related) but they contributed for the mixed stream. > > > > > > > > That user is sending/receiving Media Streams that are part of a > > > > CS, or if it isn't sending/receiving Media Streams, what is the > > > > relevance > > of > > > > that Participant? > > > > > > > > Mixed media stream from focus to UA belongs to the > > Conference > > > > event package participants. There participant are not directly > > > > involved as part of CS. Why would we create a new RS > > > > for such a participant? > > > > RS is not created for participant. Multiple RS shall be > > > > created the same CS during the different time frame as shown > below > > > > > > > > <-------------------CS1-------------> > > > > <---RS1--> <---RS2------> > > > > > > > > CS1 is between UA (SRC) and focus whereas RS1, RS2 is between UA > > (SRC) > > > > and SRS. Here tangling (conference event package) participant has > > > > to be grouped together in RS1, RS2 by some means through given > > > > metadata. > > The > > > > question whether this corner has to be solved ? > > > > > > > > John (as individual) > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > Partha > > > > > > > > > > -----Original Message----- > > > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > > Sent: Friday, April 08, 2011 9:36 PM > > > > > To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); > > > > siprec@ietf.org > > > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe > Hildebrand > > > > > (jhildebr) > > > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > > > > > Focusing just on participant and stream for the time being, > > > > do these > > > > > need to be unique across multiple CSs or not? > > > > > > > > > > John > > > > > > > > > > > -----Original Message----- > > > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > > > Sent: 07 April 2011 10:51 > > > > > > To: Paul Kyzivat (pkyzivat); siprec@ietf.org; Elwell, John > > > > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe > > Hildebrand > > > > > > (jhildebr) > > > > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > > > > > > > John, > > > > > > > > > > > > Sorry for the lengthy mail but it contains lot of analysis > and > > > > > > reasoning for this id approach. > > > > > > > > > > > > Adding to Paul's point, I wish to give more background and > > > > > reason for > > > > > > these globally unique id. Initially I had the impression that > > the > > > > > > single unique id (RS dialog-id) in the recording (session > > > > > level) and > > > > > > some relevant natural id for the rest of the element will > > > > serve the > > > > > > purpose. > > > > > > There are usecases where this assumption fails. Even I have > > > > > thought of > > > > > > > > > > > using "xml:id" instead of URN UUID to avoid long string but > > > > > xml:id may > > > > > > > > > > > not end up with unique value always. Our analysis for URN > > > > UUID for > > > > > > each level is as follows and please provide your input in > case > > id > > > > > > shall be > > > > > > tweaked: > > > > > > > > > > > > 1) Recording block: The reason for globally unique id is > > > > > that multiple > > > > > > > > > > > SRC with same id to single SRS. > > > > > > > > > > > > Topology: > > > > > > > > > > > > SRC1 SRC2 > > > > > > | | > > > > > > | ----(RS1-ID1)-----SRS1 > > > > > > | > > > > > > ---(RS2-ID1)------------------SRS1 > > > > > > > > > > > > In the above topology, it is possible for ID1 is generated by > > both > > > > > > SRC1 and SRC2 at the same time. > > > > > > > > > > > > 2) group (CSG) block: Grouping mechanism (Hadriel > > > > session-id, Paul > > > > > > Jones > > > > > > Session-UUID) is outside the scope of SIPREC. URN UUID > > > > > abstracts the > > > > > > exact mechanism to SRS and provides the information only > > > > about the > > > > > > group of CS from SRC perspective. It possible that group may > > span > > > > > > across multiple RS and It is up to SRS to group and view > > > > as single > > > > > > recording. > > > > > > Here, the single level id in the top will fail. The counter > > > > > argument > > > > > > is to force the single RS having complete CSG but > > it*may not* be > > > > > > possible in SRC implementation. Here, xml:id will not > > serve the > > > > > > purpose > > > > > > > > > > > > 3) session (CS) block: At the immediate look, session > > > > falls exactly > > > > > > under recording block. Use case 3 of draft-ietf-siprec-req-09 > > > > > > illustrates where CS span across multiple RS. This > > > > > requirement calls > > > > > > for unique id in session by which these session shall be > > > > viewed as > > > > > > single CS even though there is no group exists among > > > > them. IMO, in > > > > > > case session should not have globally unique id, then it is > > > > > preferred > > > > > > to remove usecase 3 in the requirement. > > > > > > > > > > > > 4) participant block: It needs some id which may be AOR but > > > > > AOR is not > > > > > > > > > > > unique. IMO, xml:id may serve the purpose with session > > > > > unique id. The > > > > > > trick exists for participant who are not associated with > > > > > CS. We shall > > > > > > discuss and fine tune if required. > > > > > > > > > > > > 5) stream block: Label attribute shall be used as unique > > > > > value but RFC > > > > > > 4574 does not mandate label attribute has to be unique across > > the > > > > > > dialog or CS and so, it may possible to change within > > RS and no > > > > > > normative statement to stop this implementation. IMO, > > > > > xml:id may serve > > > > > > > > > > > the purpose with session unique id. Here as well, We shall > > > > > discuss and > > > > > > > > > > > fine tune if required. > > > > > > > > > > > > 6) extensiondata block: This is tracked in the separate > > > > mail thread > > > > > > whether unique id is required or not. Let us close this > > > > as part of > > > > > > that mail thread. > > > > > > > > > > > > Including explicitly Hadriel, Peter, Joe in this mail > > > > > thread as they > > > > > > have different view on this ID mechanism. > > > > > > > > > > > > I had offline discussion with Hadriel in Prague after > > > > > SIPREC meeting > > > > > > and my understanding of his major concern is that how SRS > > > > > will be able > > > > > > > > > > > to design the database in case partial update does not have > > > > > recording > > > > > > (top) id information. I'll put more thought > > processing to close > > > > > > Hadriel concern of how top id has to be tracked in case > > > > > partial update > > > > > > > > > > > by which SRS implementation will be simplified in terms of > > > > > aggregation > > > > > > > > > > > maintenance. > > > > > > > > > > > > Thanks > > > > > > Partha > > > > > > > > > > > > -----Original Message----- > > > > > > From: siprec-bounces@ietf.org > > > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > > > > > (pkyzivat) > > > > > > Sent: Thursday, April 07, 2011 12:33 AM > > > > > > To: siprec@ietf.org > > > > > > Subject: Re: [siprec] Partial updates and identifiers > > > > > > > > > > > > John, > > > > > > > > > > > > For the moment we have proposed that the ids be conveyed in > > > > > the form > > > > > > of URIs that are globally unique, and specifically that > > > > > they be UUID > > > > > > URNs. > > > > > > There is no dependency on the particular form of the URI, but > > > > > > specifying they must be UUID URNs makes it possible to > > > > perform some > > > > > > internal optimizations for storage. > > > > > > > > > > > > The UUID URN is a pretty inefficient encoding. A UUID can > > > > > be expressed > > > > > > > > > > > in 32 bits, so we could consider retaining UUIDs but alter > the > > > > > > encoding if its really an issue. However I am far from > > > > > convinced that > > > > > > the size of the IDs is going to be a major issue in the > > > > > overall size > > > > > > of messages, so I think its probably premature to worry about > > it. > > > > > > > > > > > > Because the ids can be expressed in 32 bits, the SRC and > > > > > SRS can store > > > > > > > > > > > them internally that way, thus reducing the runtime cost of > > > > > > maintaining the data. > > > > > > > > > > > > The use of unique ids is a significant part of the overall > > > > > approach to > > > > > > > > > > > formatting updates. If somebody has a different concept > > > > in mind it > > > > > > could be useful to have an alternative proposal for the > > > > > format. If we > > > > > > had two worked out approaches we could compare the > > > > > tradeoffs in each. > > > > > > > > > > > > Thanks, > > > > > > Paul > > > > > > > > > > > > On 4/6/2011 10:24 AM, Elwell, John wrote: > > > > > > > Much of the discussion on draft-ram-metadata-format > > in Prague > > > > > > concerned the mechanism for performing partial updates and > > > > > the use of > > > > > > identifiers. The draft permits partial updates by allowing > > > > > individual > > > > > > objects (e.g., CS, participant, media stream) to be sent > > > > > with updated > > > > > > content, without having to send again other objects that have > > not > > > > > > changed. So, for example, in a large conference, it would > > > > > be possible > > > > > > to add or modify an individual participant object without > > > > having to > > > > > > send all the other participant objects again. I do not recall > > any > > > > > > opposition to this basic principle. > > > > > > > > > > > > > > However, to achieve this, every object requires an > > > > > > identifier, and it > > > > > > was asserted that these identifiers need to be globally > > > > > unique for all > > > > > > > > > > > time. Although this might be efficient for updating an > > individual > > > > > > object, when sending many objects (e.g., at the start of a > > > > > CS or when > > > > > > refreshing the entire metadata), this can make the > > metadata very > > > > > > bulky. > > > > > > It depends, of course, on the format of the identifiers, > > > > and it was > > > > > > stated that there could be alternatives to UUID. > > > > Nevertheless, some > > > > > > people had concerns. These concerns also extended to the > > > > > impact on the > > > > > > > > > > > database where metadata is stored, since it might not be > > > > > feasible to > > > > > > convert to a database-friendly mechanism for linking > > > > > objects together. > > > > > > > > > > > > > > One alternative proposal during the meeting was to have a > > single > > > > > > unique identifier at the top level (for the RS) and use local > > > > > > identifiers for other objects. Thus when updating a single > > > > > object, it > > > > > > would be necessary to include the top level identifier as > > > > > well as one > > > > > > or more local identifiers. However, there were also concerns > > this > > > > > > might not fulfil actual or perceived future requirements. > > > > > > > > > > > > > > Please continue discussion on this. > > > > > > > > > > > > > > John (as chair) > > > > > > > _______________________________________________ > > > > > > > siprec mailing list > > > > > > > siprec@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > > > > > > _______________________________________________ > > > > > > siprec mailing list > > > > > > siprec@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > > > > > > > > > > > _______________________________________________ > > > siprec mailing list > > > siprec@ietf.org > > > https://www.ietf.org/mailman/listinfo/siprec > > From andrew.hutton@siemens-enterprise.com Tue Apr 12 02:37:03 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 11C49E06E4 for ; Tue, 12 Apr 2011 02:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.850, BAYES_00=-2.599, MANGLED_VIDEO=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gs7cPVTqcQdY for ; Tue, 12 Apr 2011 02:37:02 -0700 (PDT) Received: from mail174.messagelabs.com (mail174.messagelabs.com [85.158.138.51]) by ietfc.amsl.com (Postfix) with SMTP id C4148E0692 for ; Tue, 12 Apr 2011 02:37:01 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: andrew.hutton@siemens-enterprise.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1302601020!10434185!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 14531 invoked from network); 12 Apr 2011 09:37:00 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-15.tower-174.messagelabs.com with SMTP; 12 Apr 2011 09:37:00 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id CCB0723F03DB; Tue, 12 Apr 2011 11:37:00 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 12 Apr 2011 11:37:00 +0200 From: "Hutton, Andrew" To: "Elwell, John" , Roy , "siprec@ietf.org" Date: Tue, 12 Apr 2011 11:36:59 +0200 Thread-Topic: [siprec] Question on the scope Thread-Index: Acv42ubXHfPE7b2ZSIutkk8YPChNPgABXVYQAAUKXIA= Message-ID: <101C6067BEC68246B0C3F6843BCCC1E30B6D5C888D@MCHP058A.global-ad.net> References: <007b01cbf8da$e72ff570$b58fe050$@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 Subject: Re: [siprec] Question on the scope X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2011 09:37:03 -0000 Hi Roy, Your diagram shows a SIP session from UA-A to the B2BUA and between the B2B= UA and the Media Server. I assume this is logically a session between the U= A-A and the Media Server with the B2BUA in the middle.=20 Does this session convey any media between UA-A and the Media Server and if= so what is the relationship between this and the media sent to the recordi= ng server? What is the SIP Session used for at UA-A? Regards Andy > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > Sent: 12 April 2011 08:14 > To: Roy; siprec@ietf.org > Subject: Re: [siprec] Question on the scope >=20 > Roy, >=20 > I am not sure I understand your use case correctly, but it=20 > seems some content from inside a media server is being=20 > recorded, as opposed to recording content that is transported=20 > between two or more users as part of a communication session.=20 > I believe that is outside the scope of the working group. See=20 > the charter and draft-ietf-siprec-req (requirements). Our=20 > work is concerned with recording a session, so content that=20 > is held internally to a media server, as opposed to being=20 > transported as part of a session is out of scope. >=20 > John >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org=20 > > [mailto:siprec-bounces@ietf.org] On Behalf Of Roy > > Sent: 12 April 2011 07:29 > > To: siprec@ietf.org > > Subject: [siprec] Question on the scope > >=20 > > Hello > >=20 > > =20 > >=20 > > I find this work group during Prague meeting. The work here=20 > > is quite interesting although I have some questions as below: > >=20 > > =20 > >=20 > > All through the architecture and requirement document, we are=20 > > talking about recording a media session between two UA.=20 > >=20 > > However, there is also use cases that a UA1 requests a=20 > > recording server (SRS) to record a media content in media=20 > > server (UA2) while there is not any direct media session=20 > > between UA1 and media server. Following is a general architecture. > >=20 > > +-----------+ > >=20 > > (Recording Session) | | > >=20 > > ; +----- ding | > >=20 > > | | Server | > >=20 > > | +---MetaData---->| | > >=20 > > &n | +-----------+ > >=20 > > | | ^ > >=20 > > | | | > >=20 > > &n sp; | | RTP > >=20 > > V V unicast or multicast > >=20 > > +------------------+ | > >=20 > > nbsp; | B2BUA | | > >=20 > > +--------+ | Service Control | +---------+ > >=20 > > | |<- SIP ->| Function |<- SIP ->| | > >=20 > > | UA-A | +--------- -------- ; | Media | > >=20 > > | | | Server | > >=20 > > +--------+ +---------+ > >=20 > > =20 > >=20 > > This case is very common in IPTV industry, known as Network=20 > > Personal Vide o Record ery similar with the work here. > >=20 > > Does current document cover this use case already or did you=20 > > discussed similar case ever? > >=20 > > =20 > >=20 > > Many thanks and best regards, > >=20 > > Roy > >=20 > >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > = From partr@cisco.com Tue Apr 12 02:38:13 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 47E89E06D4 for ; Tue, 12 Apr 2011 02:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.874 X-Spam-Level: X-Spam-Status: No, score=-9.874 tagged_above=-999 required=5 tests=[AWL=0.725, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X0YNxW2pPtnb for ; Tue, 12 Apr 2011 02:38:11 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfc.amsl.com (Postfix) with ESMTP id E87B3E06BE for ; Tue, 12 Apr 2011 02:38:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=13739; q=dns/txt; s=iport; t=1302601091; x=1303810691; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=ukc6J9Wd+kLKNDqgr9cQTJkaeeyT9pSlW5kue7UUW+Q=; b=KoUb2ggQEVWhMFVC81My9evsOTpIpl62iXClnvUs4vgmayNKooUcLVRs pXOhCaN0JePRdl7fNX73DYtAYPknsyEmPYJclabuN5hf8dRfFK7hmhAqo 0N8y08bk5AdMOuHjlAviSzb9m5lmWTVLTC/PpE59go1GdxeGBGi68Xt7k M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4AAOccpE2Q/khLgWdsb2JhbACYQ41cFAEBFiYlpQiccIVuBIVZi3s X-IronPort-AV: E=Sophos;i="4.64,194,1301875200"; d="scan'208";a="83208843" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 12 Apr 2011 09:38:10 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3C9bnMX026072; Tue, 12 Apr 2011 09:38:09 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Apr 2011 15:08:00 +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, 12 Apr 2011 15:08:00 +0530 Message-ID: In-Reply-To: <1D062974A4845E4D8A343C65380492020533B572@XMB-BGL-414.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] start/stop times & the metamodel Thread-Index: Acv4ar9mNRoQAPkwSImkiZlfghuuTgAIWrigAApMiDAABxSCkAAEak0wAANKJPA= References: <4D9CDADD.1020403@cisco.com> <4DA2FC17.1060100@cisco.com><07465C1D981ABC41A344374066AE1A2C38AB6E1DE4@TLVMBX01.nice.com><4DA334F0.9050301@cisco.com><059AF07365DC474393A19A3AF187DF7406E67CB4@NAHALD.us.int.genesyslab.com> <1D062974A4845E4D8A343C65380492020533B45B@XMB-BGL-414.cisco.com> <1D062974A4845E4D8A343C65380492020533B572@XMB-BGL-414.cisco.com> From: "Parthasarathi R (partr)" To: "Muthu ArulMozhi Perumal (mperumal)" , "Henry Lum" , "Paul Kyzivat (pkyzivat)" , "Leon Portman" X-OriginalArrivalTime: 12 Apr 2011 09:38:00.0602 (UTC) FILETIME=[502D67A0:01CBF8F5] Cc: siprec@ietf.org Subject: Re: [siprec] start/stop times & the metamodel X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2011 09:38:13 -0000 Muthu, I agree with you that till now there is no strong usecase for SRS to have the timestamp information about media (RTP/RTCP) packets.=20 I added further and mentioned even if somebody looks for it, the timestamp information about media packet is not possible to be achieved in all architecture without delay/latency. Thanks Partha=20 -----Original Message----- From: Muthu ArulMozhi Perumal (mperumal)=20 Sent: Tuesday, April 12, 2011 1:17 PM To: Parthasarathi R (partr); 'Henry Lum'; Paul Kyzivat (pkyzivat); 'Leon Portman' Cc: 'siprec@ietf.org' Subject: RE: [siprec] start/stop times & the metamodel |In case AS & MS are two different physical devices, it is highly tough=20 |to sync CS RTP timestamp with RS metadata timestamp because the delay=20 |between AS & MS communication for RTP timestamp has to be considered. As Paul mentioned before, the delay/latency b/w call signaling and media is what it is -- I don't see it as a problem as well. The question is whether there is need to correlate the time of occurrence of events conveyed through call signaling with the transmission/reception time of media packets when those events occurred -- I don't see why the SRC/SRS would find that useful, yet. Muthu |-----Original Message----- |From: Parthasarathi R (partr) |Sent: Tuesday, April 12, 2011 12:11 PM |To: Muthu ArulMozhi Perumal (mperumal); Henry Lum; Paul Kyzivat=20 |(pkyzivat); Leon Portman |Cc: siprec@ietf.org |Subject: RE: [siprec] start/stop times & the metamodel | |This is one of the usecase wherein I'm interested in SRC architecture=20 |with Application server (AS) & Media server (MS) as a different logical |entity. In case AS & MS are two different physical devices, it is=20 |highly tough to sync CS RTP timestamp with RS metadata timestamp=20 |because the delay between AS & MS communication for RTP timestamp has to be considered. IMO, AS has to aware of the change in the signaling plane and inform in RS metadata with timestamp rather than depend upon media (RTP). | |Thanks |Partha | |-----Original Message----- |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 |Behalf Of Muthu ArulMozhi Perumal |(mperumal) |Sent: Tuesday, April 12, 2011 8:15 AM |To: Henry Lum; Paul Kyzivat (pkyzivat); Leon Portman |Cc: siprec@ietf.org |Subject: Re: [siprec] start/stop times & the metamodel | |While I see it may be useful for the SRS to know when certain things=20 |happened in CS signaling (participant joining, leaving, going mute etc) |I don't see how useful it would be for it know how those things are=20 |related to when the participant actually sent/received (or stopped |sending/receiving) RTP. | |If we see any use, one way to do it is using the NTP timestamp carried=20 |in RTCP SR reports, provided the SRC, SRS and the participants have access to the same reference wallclock. | |Muthu | ||-----Original Message----- ||From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On |Behalf Of Henry Lum ||Sent: Tuesday, April 12, 2011 2:56 AM ||To: Paul Kyzivat (pkyzivat); Leon Portman ||Cc: siprec@ietf.org ||Subject: Re: [siprec] start/stop times & the metamodel || ||A related question on the RTP model is that if the SRC as an RTP=20 ||translator chooses to relay the RTP timestamps, then how would the SRC ||synchronize the timestamps between the SIP messages the multiple RTP=20 ||streams? || ||Henry || ||> -----Original Message----- ||> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 ||> Behalf Of Paul Kyzivat ||> Sent: Monday, April 11, 2011 1:06 PM ||> To: Leon Portman ||> Cc: siprec@ietf.org ||> Subject: Re: [siprec] start/stop times & the metamodel ||> ||> ||> ||> On 4/11/2011 9:36 AM, Leon Portman wrote: ||> > Paul Hi ||> > ||> > I agree with proposed method of time stamping metadata elements |with ||> SRC clock (it is like a wall clock from the requirement document). ||> > About RTP time synchronization to metadata events, we either=20 ||> > should ||> have some low latency event from SRC to SRS with SRC time that will=20 ||> allow SRS to maintain time difference between its clock and SRC=20 ||> clock and then apply it also to receive time of RTP packet (assuming ||> no ||> buffering) ||> ||> ISTM the issue isn't the latency of the event - it is what it is - |but ||> rather how to correlate a sip message containing metadata with a=20 ||> particular RTP packet. I suspect that needs to be tied into the=20 ||> discussion of the various models for how the SRC might handle RDP. ||> ||> Thanks, ||> Paul ||> ||> > Leon ||> > ||> > -----Original Message----- ||> > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On ||> Behalf Of Paul Kyzivat ||> > Sent: Monday, April 11, 2011 4:03 PM ||> > To: Elwell, John ||> > Cc: siprec@ietf.org ||> > Subject: Re: [siprec] start/stop times& the metamodel ||> > ||> > ||> > ||> > On 4/8/2011 11:53 AM, Elwell, John wrote: ||> >> Paul, ||> >> ||> >> I think much of what you say makes sense. I was concerned that we ||> probably need to record when a participant stops or starts sending=20 ||> or receiving a stream, which seems to be covered by your statement: ||> "Changes to media streams should similarly be tagged with the time ||they ||> occurred in the CS signaling. Each participant relationship change=20 ||> (send, receive, inactive,) will be there." That doesn't seem to be=20 ||> in the model at present. ||> > ||> > John, ||> > ||> > I agree the current model doesn't reflect this - it was a private ||> thought by me, provoked by the work and discussion to date. It is a ||bit ||> of a change of direction, so I'm interested in what others think |about ||> it. ||> > ||> > Thanks, ||> > Paul ||> > ||> >> John (as individual) ||> >> ||> >> ||> >>> -----Original Message----- ||> >>> From: siprec-bounces@ietf.org ||> >>> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat ||> >>> Sent: 06 April 2011 22:28 ||> >>> To: siprec@ietf.org ||> >>> Subject: [siprec] start/stop times& the metamodel ||> >>> ||> >>> In Prague, one of the open issues was around start/stop times. |The ||> >>> format draft floated the possibility of having explicit |start/stop ||> >>> times signaled for each of the metatdata elements. But then we ||> asked ||> >>> for feedback on which make sense. ||> >>> ||> >>> IMO explicit start/stop times make more sense for some things |than ||> >>> others. ||> >>> ||> >>> One place where we potentially have explicit times to report=20 ||> >>> with ||> the ||> >>> dialogs that constitute a CS. Each such dialog presumably has a ||> start ||> >>> and stop time observable by the SRC, which might differ, at=20 ||> >>> least ||a ||> >>> bit, from the corresponding signaling on the RS. ||> >>> ||> >>> We might want to report those times. Or, since we abstract the=20 ||> >>> CS away from the dialog, we might want to report the start time=20 ||> >>> of ||the ||> >>> first dialog in the CS as the CS start time, and the stop time=20 ||> >>> of ||> the ||> >>> last dialog in the CS as the CS stop time. ||> >>> ||> >>> Similarly, we have abstracted media streams away from the media=20 ||> >>> streams in the sip dialogs that make up the CS. We might want to ||> >>> report the start time of a media stream as the time (according=20 ||> >>> to ||> the ||> >>> CS) of the first participant to a new media stream, and the stop ||> time ||> >>> as the time that the last participant leaves the media stream. ||> >>> ||> >>> There are several things that complicate this: ||> >>> ||> >>> - Do we consider the case of a stream that starts with recvonly ||> >>> or inactive participants, and only later gets a sender? If ||so, ||> >>> is the start time of the stream when the first participant ||> arrived, ||> >>> or when the first sender arrived? ||> >>> ||> >>> - How do we get the clock times for the media streams? ||> >>> IIUC the correct ones are in the RTP/RTCP, but the=20 ||> >>> reporting ||> of ||> >>> these events is driven by the signaling, and we don't have ||> good ||> >>> sync between those. (E.g. media could start flowing before ||the ||> >>> corresponding signaling, and we would like to include that |if ||> we ||> >>> can figure it out.) So, even if the clocks used for media |and ||> >>> signaling are in sync, we might see media packets arrive |with ||> >>> a timestamp prior to the timestamp for the signaling that ||> >>> indicates the send state of the participant. This could |cause ||> >>> trouble in playback. ||> >>> ||> >>> - There isn't any guarantee that the clock used for signaling ||> >>> messages is synchronized with the clock used in RTP/RTCP. ||> >>> ||> >>> - There isn't any guarantee that there will be any RTCP at all, ||> >>> to provide correlation of the RTP to clocktime. ||> >>> ||> >>> The best I can see to deal with all of this is: ||> >>> ||> >>> - All the metadata messages should be timestamped by the SRC ||> >>> using its local clock. This is easily achieved by the Date ||> >>> header in the sip message. ||> >>> ||> >>> - Changes to a CS, including changes of participants, should ||> >>> be explicitly tagged with the time they occurred in the ||> >>> CS signaling, according to the SRC's clock. (If that is ||> >>> unavailable for some reason, then use the time the SRC ||> >>> became aware of it.) ||> >>> ||> >>> - We could provide a metadata update element to indicate end ||> >>> of a CS, but I suggest this just be shorthand for indicating ||> >>> removal of all participants from it. (While its possible to ||> >>> mark that the CS is truly ended, that simply introduces an ||> >>> error case if added metadata about it is subsequently sent.) ||> >>> The actual start/stop time would be determined by the SRS ||> >>> based on the timestamps of first and last data about it. ||> >>> ||> >>> - Changes to media streams should similarly be tagged with ||> >>> the time they occurred in the CS signaling. Each participant ||> >>> relationship change (send, receive, inactive,) will be |there. ||> >>> The actual start/stop time of the media stream again would |be ||> >>> derived by the SRS. ||> >>> ||> >>> - CS-Groups can simply be tagged by the timestamps of the ||> >>> updates that put CSs into them. Explicit start/stop times ||> don't ||> >>> seem useful. If desired, the SRS can derive start/stop times ||> >>> from the start/stop times of the contained stuff. ||> >>> ||> >>> - I now think that CS-Groups should not be "contained" within ||> >>> a recording. This just seems to introduce unnecessary error ||> >>> conditions, and limitations on future enhancements. The ||> >>> lifetime of CS-Groups will probably be naturally limited by ||> >>> the ability of the SRC to remember the IDs of old ones. ||> >>> For instance, if a CS-G is created during one Recording, ||> >>> and then another CS is added to it from a different |recording ||> >>> session, would we prefer to fail that, or just allow it? ||> >>> (I think allow.) ||> >>> ||> >>> - Rather, I think every update transmitted during a recording ||> >>> session can be tagged with a link to the metadata of the ||> >>> recording session it came from. This need not be explicit - ||> the ||> >>> SRS can do it automatically. The recording session entity ||> >>> itself will also have a start/stop time which is the start/ ||> >>> stop of the RS dialog as observed by the SRS. ||> >>> ||> >>> (Note the above doesn't solve the problem of getting correct |clock ||> >>> times for RTP media. If anyone has a suggestion for this I'm all ||> >>> ears.) ||> >>> ||> >>> Thanks, ||> >>> Paul ||> >>> _______________________________________________ ||> >>> siprec mailing 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 || || ||---------------------------------------------------------------------- ||- |------------------------------- ||------------- ||CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain |confidential and proprietary ||information of Alcatel-Lucent and/or its affiliated entities. Access=20 ||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. || ||_______________________________________________ ||siprec mailing 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 Apr 12 02:42:34 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E4486E06EF for ; Tue, 12 Apr 2011 02:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.701 X-Spam-Level: X-Spam-Status: No, score=-104.701 tagged_above=-999 required=5 tests=[AWL=1.898, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A+e1JiwvcOWm for ; Tue, 12 Apr 2011 02:42:33 -0700 (PDT) Received: from mail21.messagelabs.com (mail21.messagelabs.com [85.158.143.35]) by ietfc.amsl.com (Postfix) with SMTP id E24B9E06BD for ; Tue, 12 Apr 2011 02:42:32 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1302601346!37008075!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 20564 invoked from network); 12 Apr 2011 09:42:26 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-12.tower-21.messagelabs.com with SMTP; 12 Apr 2011 09:42:26 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id CE35823F03DB; Tue, 12 Apr 2011 11:42:31 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 12 Apr 2011 11:42:31 +0200 From: "Elwell, John" To: "Muthu ArulMozhi Perumal (mperumal)" , "Ram Mohan R (rmohanr)" , "Paul Kyzivat (pkyzivat)" Date: Tue, 12 Apr 2011 11:42:29 +0200 Thread-Topic: [siprec] start/stop times & the metamodel Thread-Index: Acv4SNxgbqUl8VtvRLKQD5NvHQX6rQAlVKGAAAKS0cAAAV1ToAAAMo/QAAGAW9A= Message-ID: References: <4D9CDADD.1020403@cisco.com><4DA2FC17.1060100@cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD06009405@XMB-BGL-417.cisco.com> <1D062974A4845E4D8A343C65380492020533B590@XMB-BGL-414.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD06009443@XMB-BGL-417.cisco.com> <1D062974A4845E4D8A343C65380492020533B5BE@XMB-BGL-414.cisco.com> In-Reply-To: <1D062974A4845E4D8A343C65380492020533B5BE@XMB-BGL-414.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 Cc: "siprec@ietf.org" Subject: Re: [siprec] start/stop times & the metamodel X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2011 09:42:35 -0000 I think the indication in the metadata can be constructed by the SRC based = on information it sends or receives in CS SDP, but this does not necessaril= y mean that it should be conveyed in RS SDP - it should be conveyed in XML.= So I agree with Muthu. Note that starting to send a particular Media Stream can be a result of var= ious changes in CS SDP, e.g: - addition of an m-line; - changing m-line port from zero to non-zero; - changing from inactive to sendrecv; - changing from recvonly to sendrecv; - changing from inactive to sendonly. Similarly starting to receive, ceasing to send and ceasing to receive can a= ll arise from a number of different changes to CS SDP. The SRS should not need to understand all the details of CS SDP changes, bu= t should just be given an abstraction, i.e., it should be told that a given= participant is starting/stopping sending/receiving a media stream, in line= with the metadata model. John (as individual) > -----Original Message----- > From: Muthu ArulMozhi Perumal (mperumal) [mailto:mperumal@cisco.com]=20 > Sent: 12 April 2011 10:20 > To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat); Elwell, John > Cc: siprec@ietf.org > Subject: RE: [siprec] start/stop times & the metamodel >=20 > |SRC to SRS indication of participant hold/resume can=20 > |happen through updates in RS SIP dialog. What I am=20 > |asking here is if there is a need to report the original=20 > |CS SDP media params (say direction attribute) explicitly=20 > |in the metadata to RS. >=20 > The SRC might have its own policy of when (and when not) to pause the > recording, which it can achieve through the RS dialog. The SRS on the > other hand might also have policies on when (and when not) to record > based on the participants media state. So, I see it might be useful to > convey this information in metadata if the SRS wants to take decisions > independent of the SRC. Also, since only metadata is=20 > persistent, making > it available in metadata might be handy for the SRS, for future > interpretation. >=20 > Muthu >=20 > |-----Original Message----- > |From: Ram Mohan R (rmohanr) > |Sent: Tuesday, April 12, 2011 2:17 PM > |To: Muthu ArulMozhi Perumal (mperumal); Paul Kyzivat (pkyzivat); > 'Elwell, John' > |Cc: 'siprec@ietf.org' > |Subject: RE: [siprec] start/stop times & the metamodel > | > |Inline > | > |> -----Original Message----- > |> From: Muthu ArulMozhi Perumal (mperumal) > |> Sent: Tuesday, April 12, 2011 1:51 PM > |> To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat); Elwell, John > |> Cc: siprec@ietf.org > |> Subject: RE: [siprec] start/stop times & the metamodel > |> > |> |I agree on sending information of when a participant start/stop > |> |sending media [ from SRC perspective - what SRC sees] in the > |> |metadata. Do we really need reporting Changes to the media > |> |streams of CS like send, receive, inactive ? > |> > |> Aren't they related? If a participant goes recvonly or=20 > inactive it is > |> an indication that he isn't going to send anything, so SRS=20 > might want > |> to know this in order to pause recording the media stream=20 > coming from > |> that participant and save some disk space -- might be useful in > |> environment where occasional small clips in the recorded=20 > stream isn't > a > |> problem. An alternative is for the SRC to run media > activity/inactivity > |> detection and report it to the SRS (which can also suffer=20 > from media > |> clipping). However, not every SRC might be capable of doing this. > | > |SRC to SRS indication of participant hold/resume can happen through > updates in RS SIP dialog. What I > |am asking here is if there is a need to report the original CS SDP > media params (say direction > |attribute) explicitly in the metadata to RS. > | > |Ram > | > |> > |> Muthu > |> > |> |-----Original Message----- > |> |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > |> Behalf Of Ram Mohan R (rmohanr) > |> |Sent: Tuesday, April 12, 2011 1:17 PM > |> |To: Paul Kyzivat (pkyzivat); Elwell, John > |> |Cc: siprec@ietf.org > |> |Subject: Re: [siprec] start/stop times & the metamodel > |> | > |> |Inline > |> |A comment on this mail > |> | > |> | > |> |> -----Original Message----- > |> |> From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On > |> |> Behalf Of Paul Kyzivat (pkyzivat) > |> |> Sent: Monday, April 11, 2011 6:33 PM > |> |> To: Elwell, John > |> |> Cc: siprec@ietf.org > |> |> Subject: Re: [siprec] start/stop times & the metamodel > |> |> > |> |> > |> |> > |> |> On 4/8/2011 11:53 AM, Elwell, John wrote: > |> |> > Paul, > |> |> > > |> |> > I think much of what you say makes sense. I was concerned that > we > |> |> probably need to record when a participant stops or=20 > starts sending > |> or > |> |> receiving a stream, which seems to be covered by your statement: > |> |> "Changes to media streams should similarly be tagged=20 > with the time > |> |they > |> |> occurred in the CS signaling. Each participant=20 > relationship change > |> |> (send, receive, inactive,) will be there." That doesn't=20 > seem to be > |> in > |> |> the model at present. > |> | > |> |I agree on sending information of when a participant start/stop > |> sending > |> |media [ from SRC perspective - what SRC sees] in the=20 > metadata. Do we > |> |really need reporting Changes to the media streams of CS=20 > like send, > |> |receive, inactive ? This would again go back to sending=20 > portions of > CS > |> |SDP [ in this case direction attribute] in metadata. > |> | > |> |Ram > |> | > |> |> > |> |> John, > |> |> > |> |> I agree the current model doesn't reflect this - it was=20 > a private > |> |> thought by me, provoked by the work and discussion to=20 > date. It is > a > |> |bit > |> |> of a change of direction, so I'm interested in what others think > |> about > |> |> it. > |> |> > |> |> Thanks, > |> |> Paul > |> |> > |> |> > John (as individual) > |> |> > > |> |> > > |> |> >> -----Original Message----- > |> |> >> From: siprec-bounces@ietf.org > |> |> >> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > |> |> >> Sent: 06 April 2011 22:28 > |> |> >> To: siprec@ietf.org > |> |> >> Subject: [siprec] start/stop times& the metamodel > |> |> >> > |> |> >> In Prague, one of the open issues was around=20 > start/stop times. > |> The > |> |> >> format draft floated the possibility of having explicit > |> |> >> start/stop times > |> |> >> signaled for each of the metatdata elements. But=20 > then we asked > |> for > |> |> >> feedback on which make sense. > |> |> >> > |> |> >> IMO explicit start/stop times make more sense for some things > |> |> >> than others. > |> |> >> > |> |> >> One place where we potentially have explicit times to report > with > |> |> the > |> |> >> dialogs that constitute a CS. Each such dialog=20 > presumably has a > |> |> start > |> |> >> and stop time observable by the SRC, which might differ, at > |> |> >> least a bit, > |> |> >> from the corresponding signaling on the RS. > |> |> >> > |> |> >> We might want to report those times. Or, since we abstract > |> |> >> the CS away > |> |> >> from the dialog, we might want to report the start=20 > time of the > |> |first > |> |> >> dialog in the CS as the CS start time, and the stop=20 > time of the > |> |last > |> |> >> dialog in the CS as the CS stop time. > |> |> >> > |> |> >> Similarly, we have abstracted media streams away from the > |> |> >> media streams > |> |> >> in the sip dialogs that make up the CS. We might=20 > want to report > |> the > |> |> >> start time of a media stream as the time (according=20 > to the CS) > of > |> |> the > |> |> >> first participant to a new media stream, and the stop time as > |> |> >> the time > |> |> >> that the last participant leaves the media stream. > |> |> >> > |> |> >> There are several things that complicate this: > |> |> >> > |> |> >> - Do we consider the case of a stream that starts=20 > with recvonly > |> |> >> or inactive participants, and only later gets a=20 > sender? If > |> so, > |> |> >> is the start time of the stream when the first=20 > participant > |> |> arrived, > |> |> >> or when the first sender arrived? > |> |> >> > |> |> >> - How do we get the clock times for the media streams? > |> |> >> IIUC the correct ones are in the RTP/RTCP, but the > reporting > |> of > |> |> >> these events is driven by the signaling, and we=20 > don't have > |> good > |> |> >> sync between those. (E.g. media could start=20 > flowing before > |> the > |> |> >> corresponding signaling, and we would like to=20 > include that > if > |> |we > |> |> >> can figure it out.) So, even if the clocks used for media > and > |> |> >> signaling are in sync, we might see media packets arrive > with > |> |> >> a timestamp prior to the timestamp for the signaling that > |> |> >> indicates the send state of the participant. This could > cause > |> |> >> trouble in playback. > |> |> >> > |> |> >> - There isn't any guarantee that the clock used for signaling > |> |> >> messages is synchronized with the clock used in RTP/RTCP. > |> |> >> > |> |> >> - There isn't any guarantee that there will be any=20 > RTCP at all, > |> |> >> to provide correlation of the RTP to clocktime. > |> |> >> > |> |> >> The best I can see to deal with all of this is: > |> |> >> > |> |> >> - All the metadata messages should be timestamped by the SRC > |> |> >> using its local clock. This is easily achieved=20 > by the Date > |> |> >> header in the sip message. > |> |> >> > |> |> >> - Changes to a CS, including changes of participants, should > |> |> >> be explicitly tagged with the time they occurred in the > |> |> >> CS signaling, according to the SRC's clock. (If that is > |> |> >> unavailable for some reason, then use the time the SRC > |> |> >> became aware of it.) > |> |> >> > |> |> >> - We could provide a metadata update element to indicate end > |> |> >> of a CS, but I suggest this just be shorthand for > indicating > |> |> >> removal of all participants from it. (While its=20 > possible to > |> |> >> mark that the CS is truly ended, that simply=20 > introduces an > |> |> >> error case if added metadata about it is subsequently > sent.) > |> |> >> The actual start/stop time would be determined by the SRS > |> |> >> based on the timestamps of first and last data about it. > |> |> >> > |> |> >> - Changes to media streams should similarly be tagged with > |> |> >> the time they occurred in the CS signaling. Each > participant > |> |> >> relationship change (send, receive, inactive,) will be > there. > |> |> >> The actual start/stop time of the media stream=20 > again would > be > |> |> >> derived by the SRS. > |> |> >> > |> |> >> - CS-Groups can simply be tagged by the timestamps of the > |> |> >> updates that put CSs into them. Explicit start/stop times > |> don't > |> |> >> seem useful. If desired, the SRS can derive start/stop > times > |> |> >> from the start/stop times of the contained stuff. > |> |> >> > |> |> >> - I now think that CS-Groups should not be "contained" within > |> |> >> a recording. This just seems to introduce=20 > unnecessary error > |> |> >> conditions, and limitations on future enhancements. The > |> |> >> lifetime of CS-Groups will probably be naturally=20 > limited by > |> |> >> the ability of the SRC to remember the IDs of old ones. > |> |> >> For instance, if a CS-G is created during one Recording, > |> |> >> and then another CS is added to it from a different > recording > |> |> >> session, would we prefer to fail that, or just allow it? > |> |> >> (I think allow.) > |> |> >> > |> |> >> - Rather, I think every update transmitted during a recording > |> |> >> session can be tagged with a link to the metadata of the > |> |> >> recording session it came from. This need not be=20 > explicit - > |> the > |> |> >> SRS can do it automatically. The recording session entity > |> |> >> itself will also have a start/stop time which is=20 > the start/ > |> |> >> stop of the RS dialog as observed by the SRS. > |> |> >> > |> |> >> (Note the above doesn't solve the problem of getting correct > |> |> >> clock times > |> |> >> for RTP media. If anyone has a suggestion for this I'm all > ears.) > |> |> >> > |> |> >> Thanks, > |> |> >> Paul > |> |> >> _______________________________________________ > |> |> >> siprec mailing list > |> |> >> siprec@ietf.org > |> |> >> https://www.ietf.org/mailman/listinfo/siprec > |> |> >> > |> |> _______________________________________________ > |> |> siprec mailing list > |> |> siprec@ietf.org > |> |> https://www.ietf.org/mailman/listinfo/siprec > |> |_______________________________________________ > |> |siprec mailing list > |> |siprec@ietf.org > |> |https://www.ietf.org/mailman/listinfo/siprec > = From rmohanr@cisco.com Tue Apr 12 02:52:49 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 565DEE06BD for ; Tue, 12 Apr 2011 02:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.486 X-Spam-Level: X-Spam-Status: No, score=-10.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sCggOXVjzRdj for ; Tue, 12 Apr 2011 02:52:47 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfc.amsl.com (Postfix) with ESMTP id 1CBA2E0682 for ; Tue, 12 Apr 2011 02:52:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=13904; q=dns/txt; s=iport; t=1302601967; x=1303811567; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=w1ju26S41TUJ4b93ZSXsK2sPlAoQIp/NQELObKYLo7s=; b=VRazW5cwK8U551vzDnSicYczEEx0trMrO92XwJkUiALR+g8N/UOr7Xs8 /38gT7sMrkYZGl3lHgFFuoSAd7HEuMHtbjV9e34A7Pu57nA1A+6uV9YLd olZMrWDjY/cxhFP3E+uwCaqv5XlXokhpW/KJfyom/wApQsXEQpAK83mWy c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4AAOQfpE2Q/khNgWdsb2JhbACYQ41cFAEBFiYliHqcApxwgwCCbgSFWYt7 X-IronPort-AV: E=Sophos;i="4.64,194,1301875200"; d="scan'208";a="25374076" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 12 Apr 2011 09:52:45 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3C9qivr011588; Tue, 12 Apr 2011 09:52:45 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, 12 Apr 2011 15:22:44 +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, 12 Apr 2011 15:22:43 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD060094A3@XMB-BGL-417.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] start/stop times & the metamodel Thread-Index: Acv4SNxgbqUl8VtvRLKQD5NvHQX6rQAlVKGAAAKS0cAAAV1ToAAAMo/QAAGAW9AAAJR2kA== References: <4D9CDADD.1020403@cisco.com><4DA2FC17.1060100@cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD06009405@XMB-BGL-417.cisco.com> <1D062974A4845E4D8A343C65380492020533B590@XMB-BGL-414.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD06009443@XMB-BGL-417.cisco.com> <1D062974A4845E4D8A343C65380492020533B5BE@XMB-BGL-414.cisco.com> From: "Ram Mohan R (rmohanr)" To: "Elwell, John" , "Muthu ArulMozhi Perumal (mperumal)" , "Paul Kyzivat (pkyzivat)" X-OriginalArrivalTime: 12 Apr 2011 09:52:44.0336 (UTC) FILETIME=[5EEC8300:01CBF8F7] Cc: siprec@ietf.org Subject: Re: [siprec] start/stop times & the metamodel X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2011 09:52:49 -0000 Hi John, Inline=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Tuesday, April 12, 2011 3:12 PM > To: Muthu ArulMozhi Perumal (mperumal); Ram Mohan R (rmohanr); Paul > Kyzivat (pkyzivat) > Cc: siprec@ietf.org > Subject: RE: [siprec] start/stop times & the metamodel >=20 > I think the indication in the metadata can be constructed by the SRC > based on information it sends or receives in CS SDP, but this does not > necessarily mean that it should be conveyed in RS SDP - it should be > conveyed in XML. So I agree with Muthu. >=20 > Note that starting to send a particular Media Stream can be a result of > various changes in CS SDP, e.g: > - addition of an m-line; > - changing m-line port from zero to non-zero; > - changing from inactive to sendrecv; > - changing from recvonly to sendrecv; > - changing from inactive to sendonly. >=20 > Similarly starting to receive, ceasing to send and ceasing to receive > can all arise from a number of different changes to CS SDP. >=20 > The SRS should not need to understand all the details of CS SDP > changes, but should just be given an abstraction, i.e., it should be > told that a given participant is starting/stopping sending/receiving a > media stream, in line with the metadata model. If we are ok to abstract the details and indicate starting/stopping sending/receiving a media stream, the current model already does it. Do you see a need to have anything else in the model to accommodate this ? Ram >=20 > John (as individual) >=20 > > -----Original Message----- > > From: Muthu ArulMozhi Perumal (mperumal) [mailto:mperumal@cisco.com] > > Sent: 12 April 2011 10:20 > > To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat); Elwell, John > > Cc: siprec@ietf.org > > Subject: RE: [siprec] start/stop times & the metamodel > > > > |SRC to SRS indication of participant hold/resume can > > |happen through updates in RS SIP dialog. What I am > > |asking here is if there is a need to report the original > > |CS SDP media params (say direction attribute) explicitly > > |in the metadata to RS. > > > > The SRC might have its own policy of when (and when not) to pause the > > recording, which it can achieve through the RS dialog. The SRS on the > > other hand might also have policies on when (and when not) to record > > based on the participants media state. So, I see it might be useful > to > > convey this information in metadata if the SRS wants to take > decisions > > independent of the SRC. Also, since only metadata is > > persistent, making > > it available in metadata might be handy for the SRS, for future > > interpretation. > > > > Muthu > > > > |-----Original Message----- > > |From: Ram Mohan R (rmohanr) > > |Sent: Tuesday, April 12, 2011 2:17 PM > > |To: Muthu ArulMozhi Perumal (mperumal); Paul Kyzivat (pkyzivat); > > 'Elwell, John' > > |Cc: 'siprec@ietf.org' > > |Subject: RE: [siprec] start/stop times & the metamodel > > | > > |Inline > > | > > |> -----Original Message----- > > |> From: Muthu ArulMozhi Perumal (mperumal) > > |> Sent: Tuesday, April 12, 2011 1:51 PM > > |> To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat); Elwell, John > > |> Cc: siprec@ietf.org > > |> Subject: RE: [siprec] start/stop times & the metamodel > > |> > > |> |I agree on sending information of when a participant start/stop > > |> |sending media [ from SRC perspective - what SRC sees] in the > > |> |metadata. Do we really need reporting Changes to the media > > |> |streams of CS like send, receive, inactive ? > > |> > > |> Aren't they related? If a participant goes recvonly or > > inactive it is > > |> an indication that he isn't going to send anything, so SRS > > might want > > |> to know this in order to pause recording the media stream > > coming from > > |> that participant and save some disk space -- might be useful in > > |> environment where occasional small clips in the recorded > > stream isn't > > a > > |> problem. An alternative is for the SRC to run media > > activity/inactivity > > |> detection and report it to the SRS (which can also suffer > > from media > > |> clipping). However, not every SRC might be capable of doing this. > > | > > |SRC to SRS indication of participant hold/resume can happen through > > updates in RS SIP dialog. What I > > |am asking here is if there is a need to report the original CS SDP > > media params (say direction > > |attribute) explicitly in the metadata to RS. > > | > > |Ram > > | > > |> > > |> Muthu > > |> > > |> |-----Original Message----- > > |> |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > |> Behalf Of Ram Mohan R (rmohanr) > > |> |Sent: Tuesday, April 12, 2011 1:17 PM > > |> |To: Paul Kyzivat (pkyzivat); Elwell, John > > |> |Cc: siprec@ietf.org > > |> |Subject: Re: [siprec] start/stop times & the metamodel > > |> | > > |> |Inline > > |> |A comment on this mail > > |> | > > |> | > > |> |> -----Original Message----- > > |> |> From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On > > |> |> Behalf Of Paul Kyzivat (pkyzivat) > > |> |> Sent: Monday, April 11, 2011 6:33 PM > > |> |> To: Elwell, John > > |> |> Cc: siprec@ietf.org > > |> |> Subject: Re: [siprec] start/stop times & the metamodel > > |> |> > > |> |> > > |> |> > > |> |> On 4/8/2011 11:53 AM, Elwell, John wrote: > > |> |> > Paul, > > |> |> > > > |> |> > I think much of what you say makes sense. I was concerned > that > > we > > |> |> probably need to record when a participant stops or > > starts sending > > |> or > > |> |> receiving a stream, which seems to be covered by your > statement: > > |> |> "Changes to media streams should similarly be tagged > > with the time > > |> |they > > |> |> occurred in the CS signaling. Each participant > > relationship change > > |> |> (send, receive, inactive,) will be there." That doesn't > > seem to be > > |> in > > |> |> the model at present. > > |> | > > |> |I agree on sending information of when a participant start/stop > > |> sending > > |> |media [ from SRC perspective - what SRC sees] in the > > metadata. Do we > > |> |really need reporting Changes to the media streams of CS > > like send, > > |> |receive, inactive ? This would again go back to sending > > portions of > > CS > > |> |SDP [ in this case direction attribute] in metadata. > > |> | > > |> |Ram > > |> | > > |> |> > > |> |> John, > > |> |> > > |> |> I agree the current model doesn't reflect this - it was > > a private > > |> |> thought by me, provoked by the work and discussion to > > date. It is > > a > > |> |bit > > |> |> of a change of direction, so I'm interested in what others > think > > |> about > > |> |> it. > > |> |> > > |> |> Thanks, > > |> |> Paul > > |> |> > > |> |> > John (as individual) > > |> |> > > > |> |> > > > |> |> >> -----Original Message----- > > |> |> >> From: siprec-bounces@ietf.org > > |> |> >> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > > |> |> >> Sent: 06 April 2011 22:28 > > |> |> >> To: siprec@ietf.org > > |> |> >> Subject: [siprec] start/stop times& the metamodel > > |> |> >> > > |> |> >> In Prague, one of the open issues was around > > start/stop times. > > |> The > > |> |> >> format draft floated the possibility of having explicit > > |> |> >> start/stop times > > |> |> >> signaled for each of the metatdata elements. But > > then we asked > > |> for > > |> |> >> feedback on which make sense. > > |> |> >> > > |> |> >> IMO explicit start/stop times make more sense for some > things > > |> |> >> than others. > > |> |> >> > > |> |> >> One place where we potentially have explicit times to report > > with > > |> |> the > > |> |> >> dialogs that constitute a CS. Each such dialog > > presumably has a > > |> |> start > > |> |> >> and stop time observable by the SRC, which might differ, at > > |> |> >> least a bit, > > |> |> >> from the corresponding signaling on the RS. > > |> |> >> > > |> |> >> We might want to report those times. Or, since we abstract > > |> |> >> the CS away > > |> |> >> from the dialog, we might want to report the start > > time of the > > |> |first > > |> |> >> dialog in the CS as the CS start time, and the stop > > time of the > > |> |last > > |> |> >> dialog in the CS as the CS stop time. > > |> |> >> > > |> |> >> Similarly, we have abstracted media streams away from the > > |> |> >> media streams > > |> |> >> in the sip dialogs that make up the CS. We might > > want to report > > |> the > > |> |> >> start time of a media stream as the time (according > > to the CS) > > of > > |> |> the > > |> |> >> first participant to a new media stream, and the stop time > as > > |> |> >> the time > > |> |> >> that the last participant leaves the media stream. > > |> |> >> > > |> |> >> There are several things that complicate this: > > |> |> >> > > |> |> >> - Do we consider the case of a stream that starts > > with recvonly > > |> |> >> or inactive participants, and only later gets a > > sender? If > > |> so, > > |> |> >> is the start time of the stream when the first > > participant > > |> |> arrived, > > |> |> >> or when the first sender arrived? > > |> |> >> > > |> |> >> - How do we get the clock times for the media streams? > > |> |> >> IIUC the correct ones are in the RTP/RTCP, but the > > reporting > > |> of > > |> |> >> these events is driven by the signaling, and we > > don't have > > |> good > > |> |> >> sync between those. (E.g. media could start > > flowing before > > |> the > > |> |> >> corresponding signaling, and we would like to > > include that > > if > > |> |we > > |> |> >> can figure it out.) So, even if the clocks used for > media > > and > > |> |> >> signaling are in sync, we might see media packets arrive > > with > > |> |> >> a timestamp prior to the timestamp for the signaling > that > > |> |> >> indicates the send state of the participant. This could > > cause > > |> |> >> trouble in playback. > > |> |> >> > > |> |> >> - There isn't any guarantee that the clock used for > signaling > > |> |> >> messages is synchronized with the clock used in > RTP/RTCP. > > |> |> >> > > |> |> >> - There isn't any guarantee that there will be any > > RTCP at all, > > |> |> >> to provide correlation of the RTP to clocktime. > > |> |> >> > > |> |> >> The best I can see to deal with all of this is: > > |> |> >> > > |> |> >> - All the metadata messages should be timestamped by the SRC > > |> |> >> using its local clock. This is easily achieved > > by the Date > > |> |> >> header in the sip message. > > |> |> >> > > |> |> >> - Changes to a CS, including changes of participants, should > > |> |> >> be explicitly tagged with the time they occurred in the > > |> |> >> CS signaling, according to the SRC's clock. (If that is > > |> |> >> unavailable for some reason, then use the time the SRC > > |> |> >> became aware of it.) > > |> |> >> > > |> |> >> - We could provide a metadata update element to indicate end > > |> |> >> of a CS, but I suggest this just be shorthand for > > indicating > > |> |> >> removal of all participants from it. (While its > > possible to > > |> |> >> mark that the CS is truly ended, that simply > > introduces an > > |> |> >> error case if added metadata about it is subsequently > > sent.) > > |> |> >> The actual start/stop time would be determined by the > SRS > > |> |> >> based on the timestamps of first and last data about it. > > |> |> >> > > |> |> >> - Changes to media streams should similarly be tagged with > > |> |> >> the time they occurred in the CS signaling. Each > > participant > > |> |> >> relationship change (send, receive, inactive,) will be > > there. > > |> |> >> The actual start/stop time of the media stream > > again would > > be > > |> |> >> derived by the SRS. > > |> |> >> > > |> |> >> - CS-Groups can simply be tagged by the timestamps of the > > |> |> >> updates that put CSs into them. Explicit start/stop > times > > |> don't > > |> |> >> seem useful. If desired, the SRS can derive start/stop > > times > > |> |> >> from the start/stop times of the contained stuff. > > |> |> >> > > |> |> >> - I now think that CS-Groups should not be "contained" > within > > |> |> >> a recording. This just seems to introduce > > unnecessary error > > |> |> >> conditions, and limitations on future enhancements. The > > |> |> >> lifetime of CS-Groups will probably be naturally > > limited by > > |> |> >> the ability of the SRC to remember the IDs of old ones. > > |> |> >> For instance, if a CS-G is created during one Recording, > > |> |> >> and then another CS is added to it from a different > > recording > > |> |> >> session, would we prefer to fail that, or just allow it? > > |> |> >> (I think allow.) > > |> |> >> > > |> |> >> - Rather, I think every update transmitted during a > recording > > |> |> >> session can be tagged with a link to the metadata of the > > |> |> >> recording session it came from. This need not be > > explicit - > > |> the > > |> |> >> SRS can do it automatically. The recording session > entity > > |> |> >> itself will also have a start/stop time which is > > the start/ > > |> |> >> stop of the RS dialog as observed by the SRS. > > |> |> >> > > |> |> >> (Note the above doesn't solve the problem of getting correct > > |> |> >> clock times > > |> |> >> for RTP media. If anyone has a suggestion for this I'm all > > ears.) > > |> |> >> > > |> |> >> Thanks, > > |> |> >> Paul From pkyzivat@cisco.com Tue Apr 12 05:40:39 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 98A25E0782 for ; Tue, 12 Apr 2011 05:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.455 X-Spam-Level: X-Spam-Status: No, score=-110.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3iUNWoQD3lO0 for ; Tue, 12 Apr 2011 05:40:37 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfc.amsl.com (Postfix) with ESMTP id 683C8E066B for ; Tue, 12 Apr 2011 05:40:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=16051; q=dns/txt; s=iport; t=1302612037; x=1303821637; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=ibY361R5ZNV5dMAwlftPItHDWSTViBQVyscvdS8NMHw=; b=A2RqTqQHjjsKnjbI5YCB2BsClVwCQlnMMapN4vdCCQIh0SIUsmzP8auE VG/JH+YuyWO2EkkKD9LauueelMGY696pNxUzy6UsVhyDM6btY/78RLdYa V8dQ7cNH8mI7PeMXhO8irvAtqRrooPkbz0Za+zK2WBbwrPoROgcTeh1ZD s=; X-IronPort-AV: E=Sophos;i="4.64,195,1301875200"; d="scan'208";a="294468769" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 12 Apr 2011 12:40:36 +0000 Received: from [161.44.174.125] (dhcp-161-44-174-125.cisco.com [161.44.174.125]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3CCeZCe000582; Tue, 12 Apr 2011 12:40:36 GMT Message-ID: <4DA44843.9090507@cisco.com> Date: Tue, 12 Apr 2011 08:40:35 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Parthasarathi R (partr)" References: <4D9CDADD.1020403@cisco.com> <4DA2FC17.1060100@cisco.com><07465C1D981ABC41A344374066AE1A2C38AB6E1DE4@TLVMBX01.nice.com><4DA334F0.9050301@cisco.com><059AF07365DC474393A19A3AF187DF7406E67CB4@NAHALD.us.int.genesyslab.com> <1D062974A4845E4D8A343C65380492020533B45B@XMB-BGL-414.cisco.com> <1D062974A4845E4D8A343C65380492020533B572@XMB-BGL-414.cisco.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] start/stop times & the metamodel X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2011 12:40:39 -0000 The problem I see (which is out of scope for now of our work) is how one queries/plays back the data and metadata captured by the SRS. Presumably one wants to look for a particular CS and then play it back, and have the events unfold in the same sequence they did in realtime. That means correlating events in the metadata with recorded media. And its not just clocks for the signaling vs media. Its also synchronizing the different media streams. If you have one media stream from A to B, and another from B to A, then it can be very important to synchronize those for playback. But they may have been generated with very different clocks. And there is also the possibility that they didn't have RTCP at all, and so have no mapping to clock time. In some cases there will be insufficient data to precisely synchronize the clocks, but even an imprecise sync done "at the time" is likely to be better than trying to figure it out after the fact with insufficient data. The alternative seems to be to partition the recorded media independent of its clocking, and then associate the start time of the partition with some metadata that is assumed to have happened at about the same time. But that doesn't necessarily work very well, especially for persistent recording. Thanks, Paul On 4/12/2011 5:38 AM, Parthasarathi R (partr) wrote: > Muthu, > > I agree with you that till now there is no strong usecase for SRS to > have the timestamp information about media (RTP/RTCP) packets. > > I added further and mentioned even if somebody looks for it, the > timestamp information about media packet is not possible to be achieved > in all architecture without delay/latency. > > Thanks > Partha > > -----Original Message----- > From: Muthu ArulMozhi Perumal (mperumal) > Sent: Tuesday, April 12, 2011 1:17 PM > To: Parthasarathi R (partr); 'Henry Lum'; Paul Kyzivat (pkyzivat); 'Leon > Portman' > Cc: 'siprec@ietf.org' > Subject: RE: [siprec] start/stop times& the metamodel > > |In case AS& MS are two different physical devices, it is highly tough > |to sync CS RTP timestamp with RS metadata timestamp because the delay > |between AS& MS communication for RTP timestamp has to be considered. > > As Paul mentioned before, the delay/latency b/w call signaling and media > is what it is -- I don't see it as a problem as well. The question is > whether there is need to correlate the time of occurrence of events > conveyed through call signaling with the transmission/reception time of > media packets when those events occurred -- I don't see why the SRC/SRS > would find that useful, yet. > > Muthu > > |-----Original Message----- > |From: Parthasarathi R (partr) > |Sent: Tuesday, April 12, 2011 12:11 PM > |To: Muthu ArulMozhi Perumal (mperumal); Henry Lum; Paul Kyzivat > |(pkyzivat); Leon Portman > |Cc: siprec@ietf.org > |Subject: RE: [siprec] start/stop times& the metamodel > | > |This is one of the usecase wherein I'm interested in SRC architecture > |with Application server (AS)& Media server (MS) as a different logical > > |entity. In case AS& MS are two different physical devices, it is > |highly tough to sync CS RTP timestamp with RS metadata timestamp > |because the delay between AS& MS communication for RTP timestamp has > to be considered. IMO, AS has to aware of the change in the signaling > plane and inform in RS metadata with timestamp rather than depend upon > media (RTP). > | > |Thanks > |Partha > | > |-----Original Message----- > |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > |Behalf Of Muthu ArulMozhi Perumal > |(mperumal) > |Sent: Tuesday, April 12, 2011 8:15 AM > |To: Henry Lum; Paul Kyzivat (pkyzivat); Leon Portman > |Cc: siprec@ietf.org > |Subject: Re: [siprec] start/stop times& the metamodel > | > |While I see it may be useful for the SRS to know when certain things > |happened in CS signaling (participant joining, leaving, going mute etc) > > |I don't see how useful it would be for it know how those things are > |related to when the participant actually sent/received (or stopped > |sending/receiving) RTP. > | > |If we see any use, one way to do it is using the NTP timestamp carried > |in RTCP SR reports, provided the SRC, SRS and the participants have > access to the same reference wallclock. > | > |Muthu > | > ||-----Original Message----- > ||From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > |Behalf Of Henry Lum > ||Sent: Tuesday, April 12, 2011 2:56 AM > ||To: Paul Kyzivat (pkyzivat); Leon Portman > ||Cc: siprec@ietf.org > ||Subject: Re: [siprec] start/stop times& the metamodel > || > ||A related question on the RTP model is that if the SRC as an RTP > ||translator chooses to relay the RTP timestamps, then how would the SRC > > ||synchronize the timestamps between the SIP messages the multiple RTP > ||streams? > || > ||Henry > || > ||> -----Original Message----- > ||> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > ||> Behalf Of Paul Kyzivat > ||> Sent: Monday, April 11, 2011 1:06 PM > ||> To: Leon Portman > ||> Cc: siprec@ietf.org > ||> Subject: Re: [siprec] start/stop times& the metamodel > ||> > ||> > ||> > ||> On 4/11/2011 9:36 AM, Leon Portman wrote: > ||> > Paul Hi > ||> > > ||> > I agree with proposed method of time stamping metadata elements > |with > ||> SRC clock (it is like a wall clock from the requirement document). > ||> > About RTP time synchronization to metadata events, we either > ||> > should > ||> have some low latency event from SRC to SRS with SRC time that will > ||> allow SRS to maintain time difference between its clock and SRC > ||> clock and then apply it also to receive time of RTP packet (assuming > > ||> no > ||> buffering) > ||> > ||> ISTM the issue isn't the latency of the event - it is what it is - > |but > ||> rather how to correlate a sip message containing metadata with a > ||> particular RTP packet. I suspect that needs to be tied into the > ||> discussion of the various models for how the SRC might handle RDP. > ||> > ||> Thanks, > ||> Paul > ||> > ||> > Leon > ||> > > ||> > -----Original Message----- > ||> > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > ||> Behalf Of Paul Kyzivat > ||> > Sent: Monday, April 11, 2011 4:03 PM > ||> > To: Elwell, John > ||> > Cc: siprec@ietf.org > ||> > Subject: Re: [siprec] start/stop times& the metamodel > ||> > > ||> > > ||> > > ||> > On 4/8/2011 11:53 AM, Elwell, John wrote: > ||> >> Paul, > ||> >> > ||> >> I think much of what you say makes sense. I was concerned that we > ||> probably need to record when a participant stops or starts sending > ||> or receiving a stream, which seems to be covered by your statement: > ||> "Changes to media streams should similarly be tagged with the time > ||they > ||> occurred in the CS signaling. Each participant relationship change > ||> (send, receive, inactive,) will be there." That doesn't seem to be > ||> in the model at present. > ||> > > ||> > John, > ||> > > ||> > I agree the current model doesn't reflect this - it was a private > ||> thought by me, provoked by the work and discussion to date. It is a > ||bit > ||> of a change of direction, so I'm interested in what others think > |about > ||> it. > ||> > > ||> > Thanks, > ||> > Paul > ||> > > ||> >> John (as individual) > ||> >> > ||> >> > ||> >>> -----Original Message----- > ||> >>> From: siprec-bounces@ietf.org > ||> >>> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > ||> >>> Sent: 06 April 2011 22:28 > ||> >>> To: siprec@ietf.org > ||> >>> Subject: [siprec] start/stop times& the metamodel > ||> >>> > ||> >>> In Prague, one of the open issues was around start/stop times. > |The > ||> >>> format draft floated the possibility of having explicit > |start/stop > ||> >>> times signaled for each of the metatdata elements. But then we > ||> asked > ||> >>> for feedback on which make sense. > ||> >>> > ||> >>> IMO explicit start/stop times make more sense for some things > |than > ||> >>> others. > ||> >>> > ||> >>> One place where we potentially have explicit times to report > ||> >>> with > ||> the > ||> >>> dialogs that constitute a CS. Each such dialog presumably has a > ||> start > ||> >>> and stop time observable by the SRC, which might differ, at > ||> >>> least > ||a > ||> >>> bit, from the corresponding signaling on the RS. > ||> >>> > ||> >>> We might want to report those times. Or, since we abstract the > ||> >>> CS away from the dialog, we might want to report the start time > ||> >>> of > ||the > ||> >>> first dialog in the CS as the CS start time, and the stop time > ||> >>> of > ||> the > ||> >>> last dialog in the CS as the CS stop time. > ||> >>> > ||> >>> Similarly, we have abstracted media streams away from the media > ||> >>> streams in the sip dialogs that make up the CS. We might want to > > ||> >>> report the start time of a media stream as the time (according > ||> >>> to > ||> the > ||> >>> CS) of the first participant to a new media stream, and the stop > ||> time > ||> >>> as the time that the last participant leaves the media stream. > ||> >>> > ||> >>> There are several things that complicate this: > ||> >>> > ||> >>> - Do we consider the case of a stream that starts with recvonly > ||> >>> or inactive participants, and only later gets a sender? If > ||so, > ||> >>> is the start time of the stream when the first participant > ||> arrived, > ||> >>> or when the first sender arrived? > ||> >>> > ||> >>> - How do we get the clock times for the media streams? > ||> >>> IIUC the correct ones are in the RTP/RTCP, but the > ||> >>> reporting > ||> of > ||> >>> these events is driven by the signaling, and we don't have > ||> good > ||> >>> sync between those. (E.g. media could start flowing before > ||the > ||> >>> corresponding signaling, and we would like to include that > |if > ||> we > ||> >>> can figure it out.) So, even if the clocks used for media > |and > ||> >>> signaling are in sync, we might see media packets arrive > |with > ||> >>> a timestamp prior to the timestamp for the signaling that > ||> >>> indicates the send state of the participant. This could > |cause > ||> >>> trouble in playback. > ||> >>> > ||> >>> - There isn't any guarantee that the clock used for signaling > ||> >>> messages is synchronized with the clock used in RTP/RTCP. > ||> >>> > ||> >>> - There isn't any guarantee that there will be any RTCP at all, > ||> >>> to provide correlation of the RTP to clocktime. > ||> >>> > ||> >>> The best I can see to deal with all of this is: > ||> >>> > ||> >>> - All the metadata messages should be timestamped by the SRC > ||> >>> using its local clock. This is easily achieved by the Date > ||> >>> header in the sip message. > ||> >>> > ||> >>> - Changes to a CS, including changes of participants, should > ||> >>> be explicitly tagged with the time they occurred in the > ||> >>> CS signaling, according to the SRC's clock. (If that is > ||> >>> unavailable for some reason, then use the time the SRC > ||> >>> became aware of it.) > ||> >>> > ||> >>> - We could provide a metadata update element to indicate end > ||> >>> of a CS, but I suggest this just be shorthand for > indicating > ||> >>> removal of all participants from it. (While its possible to > ||> >>> mark that the CS is truly ended, that simply introduces an > ||> >>> error case if added metadata about it is subsequently > sent.) > ||> >>> The actual start/stop time would be determined by the SRS > ||> >>> based on the timestamps of first and last data about it. > ||> >>> > ||> >>> - Changes to media streams should similarly be tagged with > ||> >>> the time they occurred in the CS signaling. Each > participant > ||> >>> relationship change (send, receive, inactive,) will be > |there. > ||> >>> The actual start/stop time of the media stream again would > |be > ||> >>> derived by the SRS. > ||> >>> > ||> >>> - CS-Groups can simply be tagged by the timestamps of the > ||> >>> updates that put CSs into them. Explicit start/stop times > ||> don't > ||> >>> seem useful. If desired, the SRS can derive start/stop > times > ||> >>> from the start/stop times of the contained stuff. > ||> >>> > ||> >>> - I now think that CS-Groups should not be "contained" within > ||> >>> a recording. This just seems to introduce unnecessary error > ||> >>> conditions, and limitations on future enhancements. The > ||> >>> lifetime of CS-Groups will probably be naturally limited by > ||> >>> the ability of the SRC to remember the IDs of old ones. > ||> >>> For instance, if a CS-G is created during one Recording, > ||> >>> and then another CS is added to it from a different > |recording > ||> >>> session, would we prefer to fail that, or just allow it? > ||> >>> (I think allow.) > ||> >>> > ||> >>> - Rather, I think every update transmitted during a recording > ||> >>> session can be tagged with a link to the metadata of the > ||> >>> recording session it came from. This need not be explicit - > ||> the > ||> >>> SRS can do it automatically. The recording session entity > ||> >>> itself will also have a start/stop time which is the start/ > ||> >>> stop of the RS dialog as observed by the SRS. > ||> >>> > ||> >>> (Note the above doesn't solve the problem of getting correct > |clock > ||> >>> times for RTP media. If anyone has a suggestion for this I'm all > ||> >>> ears.) > ||> >>> > ||> >>> Thanks, > ||> >>> Paul > ||> >>> _______________________________________________ > ||> >>> siprec mailing 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 > || > || > ||---------------------------------------------------------------------- > ||- > |------------------------------- > ||------------- > ||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. > || > ||_______________________________________________ > ||siprec mailing 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@cisco.com Tue Apr 12 05:50:09 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BC375E06F5 for ; Tue, 12 Apr 2011 05:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.469 X-Spam-Level: X-Spam-Status: No, score=-110.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zgYccQ6BElkP for ; Tue, 12 Apr 2011 05:50:09 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfc.amsl.com (Postfix) with ESMTP id BFA97E06BD for ; Tue, 12 Apr 2011 05:50:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=4486; q=dns/txt; s=iport; t=1302612608; x=1303822208; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=KI09LVlAhErQAbja1F0KZ8ghLQBURF3KL7pJA3PCro8=; b=XVd5dLcUMc/mYNGXS3MH0kbmTVCRf7lEMyqvZIZRSi1eEGEsZccIOK30 dvqr6Y2cgaDnKsfDR+dNdrX1QF7eu1KtKJ4PkzSCipEL68Q6+eO+6+afY xConl6Ls629xuJ+/g2xBORnh3Y0vnYuAIMVDMSKFzYZuKdSvn+pw55Wgf Q=; X-IronPort-AV: E=Sophos;i="4.64,195,1301875200"; d="scan'208";a="428167845" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by sj-iport-1.cisco.com with ESMTP; 12 Apr 2011 12:50:07 +0000 Received: from [161.44.174.125] (dhcp-161-44-174-125.cisco.com [161.44.174.125]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3CCo7Nf001284; Tue, 12 Apr 2011 12:50:07 GMT Message-ID: <4DA44A7F.2000406@cisco.com> Date: Tue, 12 Apr 2011 08:50:07 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Elwell, John" References: <07465C1D981ABC41A344374066AE1A2C38AB6E1DC4@TLVMBX01.nice.com><4DA31E2C.6080008@cisco.com><07465C1D981ABC41A344374066AE1A2C38AB6E1E75@TLVMBX01.nice.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] metadata model and persisent recording X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 12:50:09 -0000 On 4/12/2011 3:02 AM, Elwell, John wrote: > No, I don't think what you describe is the same as the persistent recording session that Leon was talking about. I think a persistent recording session is where there is a permanent recording session between user X (e.g., a contact centre agent) and the SRS, such that whenever user X is involved in a CS, that CS gets recorded using that RS. At other times the RS is idle, but still exists. Leon wanted to make sure that the identify of X is always part of the metadata (i.e., it doesn't disappear during times when X is not involved in a CS), and the way he wanted to achieve that was by considering X as a Participant, even when there is no CS. My alternative proposal is to make X an attribute of the RS object in the metadata. ISTM this is a distinction without a difference, *unless* the RS may actually be receiving/recording media from the one UA even when there is no CS. (IOW, it is a tap on the agent's phone all the time.) Thanks, Paul > John > >> -----Original Message----- >> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] >> Sent: 12 April 2011 00:02 >> To: Elwell, John; Leon Portman; Paul Kyzivat (pkyzivat); >> siprec@ietf.org >> Subject: RE: [siprec] metadata model and persisent recording >> >> If I understand correctly, this is the case in which the URL is: >> 1) dialed to add a recorder to a conference >> or >> 2) a recorder dials into a conference using a given URL as >> its caller ID >> In either case, I see the URL as being a property of the >> recorder, not a >> participant. I support if the record injects media into the >> conference, >> then it could be a participant as well. Is this the reason for having >> URL presented both as a participant and as the "target" of the RS? >> >> Thanks, >> Charles >> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Elwell, John >>> Sent: Monday, April 11, 2011 9:52 AM >>> To: Leon Portman; Paul Kyzivat (pkyzivat); siprec@ietf.org >>> Subject: Re: [siprec] metadata model and persisent recording >>> >>> Perhaps this is an attribute of the RS metadata object >> (let's call it >> the "target" attribute, i.e., >>> the target of recording) rather than a participant. When a >> CS starts, >> one of the participant objects >>> associated with the CS will happen to match the target. >>> >>> John (as individual) >>> >>> >>>> -----Original Message----- >>>> From: siprec-bounces@ietf.org >>>> [mailto:siprec-bounces@ietf.org] On Behalf Of Leon Portman >>>> Sent: 11 April 2011 16:37 >>>> To: Paul Kyzivat; siprec@ietf.org >>>> Subject: Re: [siprec] metadata model and persisent recording >>>> >>>> Actually yes, because it is common for persistent session >>>> that SRS channel are predefined per DN (participant) >>>> >>>> Leon >>>> >>>> -----Original Message----- >>>> From: siprec-bounces@ietf.org >>>> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat >>>> Sent: Monday, April 11, 2011 6:29 PM >>>> To: siprec@ietf.org >>>> Subject: Re: [siprec] metadata model and persisent recording >>>> >>>> Leon, >>>> >>>> Is it important that a persistent RS identify a participant >>>> when there is no CS? Isn't it sufficient to identify the >>>> participant at the time the CS is reported? >>>> >>>> Thanks, >>>> Paul >>>> >>>> On 4/11/2011 9:24 AM, Leon Portman wrote: >>>>> Partha Hi >>>>> >>>>> I think we are missing in the metadata model support for >> persistent >>>>> recording mode, where RS INVITE may be sent from SRC to SRC with >>>>> participant info but without any communication session or >>>> group. For >>>>> example where RS will be established when somebody logins >>>> to the phone. >>>>> >>>>> Regards >>>>> >>>>> Leon >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> siprec mailing list >>>>> siprec@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/siprec >>>> _______________________________________________ >>>> siprec mailing list >>>> siprec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/siprec >>>> _______________________________________________ >>>> siprec mailing 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 Apr 12 07:47:05 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 3D58DE07E4 for ; Tue, 12 Apr 2011 07:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.379 X-Spam-Level: X-Spam-Status: No, score=-10.379 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iLe4cVIk1hkI for ; Tue, 12 Apr 2011 07:47:03 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfc.amsl.com (Postfix) with ESMTP id 7BC6AE07E1 for ; Tue, 12 Apr 2011 07:47:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=9587; q=dns/txt; s=iport; t=1302619623; x=1303829223; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=CdbgP+KfaF8ZKUJgt4uktHRI8AQPb6c2qmqNhilgWxw=; b=MaxwSDJmHt+Xi+RFHQ0AmtGN0U1oki7PjgUHQzFAjEVQ2mNnu+lUID2w MI52FKlFTZYYD014p1ZESwMRRf6mQruTL/j5czAX51DFtC26dLJltorEC uyl7XXid3zm7JGaIuOO7hEEN4Sph2N13I/be6hEGdvbGQ8dy98J5IUSNq s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIBAAdlpE2rRDoI/2dsb2JhbACYQ41od6U7nH2FbgSFW4t8 X-IronPort-AV: E=Sophos;i="4.64,195,1301875200"; d="scan'208";a="335470604" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 12 Apr 2011 14:47:02 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3CEl2vK006471; Tue, 12 Apr 2011 14:47:02 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Apr 2011 07:47:02 -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, 12 Apr 2011 07:47:00 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Recording awareness indication Thread-Index: Acv4TeQi+KylUoLKQ8aqVd4Ks0+vxQADzIHAAB9a6OAAEQj0UA== References: <4D9CBB90.4080804@cisco.com><059AF07365DC474393A19A3AF187DF7406E677EF@NAHALD.us.int.genesyslab.com><4DA3048E.5000103@cisco.com> From: "Charles Eckel (eckelcu)" To: "Elwell, John" , "Paul Kyzivat (pkyzivat)" , "Henry Lum" X-OriginalArrivalTime: 12 Apr 2011 14:47:02.0558 (UTC) FILETIME=[7C0B5BE0:01CBF920] Cc: siprec@ietf.org Subject: Re: [siprec] Recording awareness indication X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2011 14:47:05 -0000 I was actually thinking of an options tag in a supported header field as well, though I now realize the term feature tag means something else. I am not all that familiar with media feature tags, so I possibly could be convinced to go either way. Cheers, Charles=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Monday, April 11, 2011 11:29 PM > To: Charles Eckel (eckelcu); Paul Kyzivat (pkyzivat); Henry Lum > Cc: siprec@ietf.org > Subject: RE: [siprec] Recording awareness indication >=20 > I am curious why a media feature tag is being considered, rather than an option tag (in the Supported > header field). >=20 > John >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf Of Charles Eckel (eckelcu) > > Sent: 11 April 2011 16:33 > > To: Paul Kyzivat (pkyzivat); Henry Lum > > Cc: siprec@ietf.org > > Subject: Re: [siprec] Recording awareness indication > > > > My thinking on this is that recording awareness indication > > may be useful > > to indicate an ability to request and/or provide recording. As such, I > > may place a call and see in the response that I have the ability to > > request this call, or not. I also thought this indication may > > be useful > > to help a SRC determine how best to indicate to a UA that its media is > > being recorded. In both case, but especially in the former, the > > indication is not tied to the media, so I think it makes more sense to > > signal it as a feature tag than as an SDP attribute. > > > > Cheers, > > Charles > > > > > -----Original Message----- > > > From: Paul Kyzivat (pkyzivat) > > > Sent: Monday, April 11, 2011 6:39 AM > > > To: Henry Lum > > > Cc: Charles Eckel (eckelcu); siprec@ietf.org > > > Subject: Re: [siprec] Recording awareness indication > > > > > > > > > > > > On 4/8/2011 10:46 AM, Henry Lum wrote: > > > > Currently in the draft we propose to use an SDP attribute > > to declare > > the > > > > awareness. I saw comments that this should be changed to a feature > > tag > > > > instead. I am okay either way; are there arguments against using a > > > > feature tag? > > > > > > IIUC the main argument has been to use SDP attributes to > > indicate that > > > recording is being done. And there it *is* important for it to be in > > SDP > > > so it can be indicated on a per-media basis. > > > > > > For the awareness indicator its not so clear cut. Certainly we could > > > define awareness so that it applies to all media, and then > > it *could* > > be > > > in the SIP rather than the SDP. It then comes down to taste - for > > > consistency it might be preferable to indicate it in SDP. I > > don't have > > a > > > strong preference one way or the other. > > > > > > Thanks, > > > Paul > > > > > > > Regards, > > > > Henry > > > > > > > >> -----Original Message----- > > > >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > > >> Behalf Of Charles Eckel (eckelcu) > > > >> Sent: Thursday, April 07, 2011 3:45 PM > > > >> To: Paul Kyzivat (pkyzivat); siprec@ietf.org > > > >> Subject: Re: [siprec] Recording awareness indication > > > >> > > > >> I agree with Paul. I would hate to force the addition of > > an audible > > > >> beep > > > >> or a red dot to all participants when a less intrusive > > mechanism is > > > >> supported. > > > >> > > > >> Cheers, > > > >> Charles > > > >> > > > >>> -----Original Message----- > > > >>> From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On > > > >> Behalf Of Paul Kyzivat (pkyzivat) > > > >>> Sent: Wednesday, April 06, 2011 12:14 PM > > > >>> To: siprec@ietf.org > > > >>> Subject: Re: [siprec] Recording awareness indication > > > >>> > > > >>> I liked this concept of an overt "opt-out" of the in-band > > > > indication. > > > >>> ISTM that if the UA has a "better" way of doing the > > indication it > > > > may > > > >>> not want the default mechanism. (E.g. The UA may want > > to apply its > > > >> own > > > >>> in-band indication. But that won't work well if a different one > > has > > > >>> already been applied.) > > > >>> > > > >>> If we can agree on the *concept* of opt-out, then we > > can determine > > > >> the > > > >>> exact form as a subsequent step. > > > >>> > > > >>> I suppose some SRCs may feel they are obliged to do their own > > > >> indication > > > >>> even if a participant desires to opt-out, and we ought to allow > > that > > > >>> too. In that case there should probably be some indication that > > the > > > >>> opt-out has been ignored, so that the UA can behave accordingly. > > > >>> > > > >>> Thanks, > > > >>> Paul > > > >>> > > > >>> On 4/6/2011 11:08 AM, Elwell, John wrote: > > > >>>> My own thoughts on this are that the SIP/SDP indication that > > > >> recording is in progress, even if sent > > > >>> to a UA known to be recording-aware, should not be used as a > > > >> substitute for other non-SIP/SDP means of > > > >>> notification that might otherwise be needed (e.g., an in-band > > audio > > > >> announcement). I think recording > > > >>> indicators should be used to complement other means. > > For example, > > an > > > >> in-band audio announcement would > > > >>> be able to reach all users (although might be problematic for > > > >> hearing-impaired users or for users > > > >>> speaking a different language). Despite such limitations, an > > in-band > > > >> announcement is often sufficient > > > >>> to satisfy legal requirements. On the other hand, a SIP/SDP > > > >> indication > > > >> that recording is in progress > > > >>> could be rendered in different ways and in different > > languages at > > > > the > > > >> user interface of a recording- > > > >>> aware UA. > > > >>>> > > > >>>> For this reason, I don't see a need for the recording-aware > > > >> indication in SIP/SDP. Recording > > > >>> indications can be sent without knowing whether they will be > > > >> understood by the receiving UA - if they > > > >>> are understood the user might get an enhanced > > indication - if not > > > >> they > > > >> will be discarded and the user > > > >>> will get only the basic (non-SIP/SDP) indication. > > > >>>> > > > >>>> John (as individual) > > > >>>> > > > >>>> > > > >>>>> -----Original Message----- > > > >>>>> From: siprec-bounces@ietf.org > > > >>>>> [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > > > >>>>> Sent: 06 April 2011 15:55 > > > >>>>> To: siprec@ietf.org > > > >>>>> Subject: [siprec] Recording awareness indication > > > >>>>> > > > >>>>> There was an inconclusive discussion in Prague on the > > > >>>>> recording awareness signalling indication in > > > >>>>> draft-portman-siprec-protocol (slide 6 / section 6.1 of > > > >>>>> draft). If I understand correctly, it indicates that a UA > > > >>>>> involved in the CS supports the SIPREC extensions relevant to > > > >>>>> the CS. In particular, it indicates that the UA would be able > > > >>>>> to understand SIP/SDP recording indications (slide 7 / > > > >>>>> section 6.2 of draft). It seems the recording awareness > > > >>>>> indication means that the SRC can rely on the recording > > > >>>>> indications in SIP/SDP to advise the user that recording is > > > >>>>> in progress, thereby avoiding the need for the SRC to provide > > > >>>>> suitable indications through non-SIP means (e.g., in-band > > > >>>>> audio announcements). > > > >>>>> > > > >>>>> Please continue this discussion. > > > >>>>> > > > >>>>> John (as chair) > > > >>>>> _______________________________________________ > > > >>>>> siprec mailing list > > > >>>>> siprec@ietf.org > > > >>>>> https://www.ietf.org/mailman/listinfo/siprec > > > >>>>> > > > >>>> _______________________________________________ > > > >>>> siprec mailing list > > > >>>> siprec@ietf.org > > > >>>> https://www.ietf.org/mailman/listinfo/siprec > > > >>>> > > > >>> _______________________________________________ > > > >>> siprec mailing list > > > >>> siprec@ietf.org > > > >>> https://www.ietf.org/mailman/listinfo/siprec > > > >> _______________________________________________ > > > >> 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. > > > > > > > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > > From Henry.Lum@alcatel-lucent.com Tue Apr 12 14:13:04 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0DD33E0961 for ; Tue, 12 Apr 2011 14:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kp28k6OVDax4 for ; Tue, 12 Apr 2011 14:13:02 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfc.amsl.com (Postfix) with ESMTP id D644AE0960 for ; Tue, 12 Apr 2011 14:13:01 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p3CLCjiH022528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 12 Apr 2011 16:12:50 -0500 (CDT) Received: from relay-out1.wc.genesyslab.com (relay-out1.wc.genesyslab.com [172.22.70.114]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p3CLCh0h024477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 12 Apr 2011 16:12:44 -0500 Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out1.wc.genesyslab.com (8.13.8+Sun/8.13.8) with ESMTP id p3CLCgFi004024; Tue, 12 Apr 2011 14:12:42 -0700 (PDT) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.93]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Apr 2011 14:12:42 -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, 12 Apr 2011 14:12:42 -0700 Message-ID: <059AF07365DC474393A19A3AF187DF7406EF2378@NAHALD.us.int.genesyslab.com> In-Reply-To: <1D062974A4845E4D8A343C65380492020533B45B@XMB-BGL-414.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] start/stop times & the metamodel Thread-Index: Acv4ar9mNRoQAPkwSImkiZlfghuuTgAIWrigAApMiDAAJ/uhEA== References: <4D9CDADD.1020403@cisco.com> <4DA2FC17.1060100@cisco.com><07465C1D981ABC41A344374066AE1A2C38AB6E1DE4@TLVMBX01.nice.com><4DA334F0.9050301@cisco.com> <059AF07365DC474393A19A3AF187DF7406E67CB4@NAHALD.us.int.genesyslab.com> <1D062974A4845E4D8A343C65380492020533B45B@XMB-BGL-414.cisco.com> From: "Henry Lum" To: "Muthu ArulMozhi Perumal (mperumal)" , "Paul Kyzivat (pkyzivat)" , "Leon Portman" X-OriginalArrivalTime: 12 Apr 2011 21:12:42.0936 (UTC) FILETIME=[5CC8D380:01CBF956] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: siprec@ietf.org Subject: Re: [siprec] start/stop times & the metamodel X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2011 21:13:04 -0000 I don't think it is guaranteed that participants will send SR reports (or any RTCP), plus we will also have to assume that the NTP timestamps are in sync. We could mandate the SRC to generate SR reports but then we are fixing the RTP model for the SRC.=20 Regards, Henry > -----Original Message----- > From: Muthu ArulMozhi Perumal (mperumal) [mailto:mperumal@cisco.com] > Sent: Monday, April 11, 2011 10:45 PM > To: Henry Lum; Paul Kyzivat (pkyzivat); Leon Portman > Cc: siprec@ietf.org > Subject: RE: [siprec] start/stop times & the metamodel >=20 > While I see it may be useful for the SRS to know when certain things > happened in CS signaling (participant joining, leaving, going mute etc) > I don't see how useful it would be for it know how those things are > related to when the participant actually sent/received (or stopped > sending/receiving) RTP. >=20 > If we see any use, one way to do it is using the NTP timestamp carried > in RTCP SR reports, provided the SRC, SRS and the participants have > access to the same reference wallclock. >=20 > Muthu >=20 > |-----Original Message----- > |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Henry Lum > |Sent: Tuesday, April 12, 2011 2:56 AM > |To: Paul Kyzivat (pkyzivat); Leon Portman > |Cc: siprec@ietf.org > |Subject: Re: [siprec] start/stop times & the metamodel > | > |A related question on the RTP model is that if the SRC as an RTP > |translator chooses to relay the RTP timestamps, then how would the SRC > |synchronize the timestamps between the SIP messages the multiple RTP > |streams? > | > |Henry > | > |> -----Original Message----- > |> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > |> Behalf Of Paul Kyzivat > |> Sent: Monday, April 11, 2011 1:06 PM > |> To: Leon Portman > |> Cc: siprec@ietf.org > |> Subject: Re: [siprec] start/stop times & the metamodel > |> > |> > |> > |> On 4/11/2011 9:36 AM, Leon Portman wrote: > |> > Paul Hi > |> > > |> > I agree with proposed method of time stamping metadata elements > with > |> SRC clock (it is like a wall clock from the requirement document). > |> > About RTP time synchronization to metadata events, we either > should > |> have some low latency event from SRC to SRS with SRC time that will > |> allow SRS to maintain time difference between its clock and SRC > clock > |> and then apply it also to receive time of RTP packet (assuming no > |> buffering) > |> > |> ISTM the issue isn't the latency of the event - it is what it is - > but > |> rather how to correlate a sip message containing metadata with a > |> particular RTP packet. I suspect that needs to be tied into the > |> discussion of the various models for how the SRC might handle RDP. > |> > |> Thanks, > |> Paul > |> > |> > Leon > |> > > |> > -----Original Message----- > |> > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > |> Behalf Of Paul Kyzivat > |> > Sent: Monday, April 11, 2011 4:03 PM > |> > To: Elwell, John > |> > Cc: siprec@ietf.org > |> > Subject: Re: [siprec] start/stop times& the metamodel > |> > > |> > > |> > > |> > On 4/8/2011 11:53 AM, Elwell, John wrote: > |> >> Paul, > |> >> > |> >> I think much of what you say makes sense. I was concerned that we > |> probably need to record when a participant stops or starts sending > or > |> receiving a stream, which seems to be covered by your statement: > |> "Changes to media streams should similarly be tagged with the time > |they > |> occurred in the CS signaling. Each participant relationship change > |> (send, receive, inactive,) will be there." That doesn't seem to be > in > |> the model at present. > |> > > |> > John, > |> > > |> > I agree the current model doesn't reflect this - it was a private > |> thought by me, provoked by the work and discussion to date. It is a > |bit > |> of a change of direction, so I'm interested in what others think > about > |> it. > |> > > |> > Thanks, > |> > Paul > |> > > |> >> John (as individual) > |> >> > |> >> > |> >>> -----Original Message----- > |> >>> From: siprec-bounces@ietf.org > |> >>> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > |> >>> Sent: 06 April 2011 22:28 > |> >>> To: siprec@ietf.org > |> >>> Subject: [siprec] start/stop times& the metamodel > |> >>> > |> >>> In Prague, one of the open issues was around start/stop times. > The > |> >>> format draft floated the possibility of having explicit > start/stop > |> >>> times signaled for each of the metatdata elements. But then we > |> asked > |> >>> for feedback on which make sense. > |> >>> > |> >>> IMO explicit start/stop times make more sense for some things > than > |> >>> others. > |> >>> > |> >>> One place where we potentially have explicit times to report > with > |> the > |> >>> dialogs that constitute a CS. Each such dialog presumably has a > |> start > |> >>> and stop time observable by the SRC, which might differ, at > least > |a > |> >>> bit, from the corresponding signaling on the RS. > |> >>> > |> >>> We might want to report those times. Or, since we abstract the > CS > |> >>> away from the dialog, we might want to report the start time of > |the > |> >>> first dialog in the CS as the CS start time, and the stop time > of > |> the > |> >>> last dialog in the CS as the CS stop time. > |> >>> > |> >>> Similarly, we have abstracted media streams away from the media > |> >>> streams in the sip dialogs that make up the CS. We might want to > |> >>> report the start time of a media stream as the time (according > to > |> the > |> >>> CS) of the first participant to a new media stream, and the stop > |> time > |> >>> as the time that the last participant leaves the media stream. > |> >>> > |> >>> There are several things that complicate this: > |> >>> > |> >>> - Do we consider the case of a stream that starts with recvonly > |> >>> or inactive participants, and only later gets a sender? If > |so, > |> >>> is the start time of the stream when the first participant > |> arrived, > |> >>> or when the first sender arrived? > |> >>> > |> >>> - How do we get the clock times for the media streams? > |> >>> IIUC the correct ones are in the RTP/RTCP, but the > reporting > |> of > |> >>> these events is driven by the signaling, and we don't have > |> good > |> >>> sync between those. (E.g. media could start flowing before > |the > |> >>> corresponding signaling, and we would like to include that > if > |> we > |> >>> can figure it out.) So, even if the clocks used for media > and > |> >>> signaling are in sync, we might see media packets arrive > with > |> >>> a timestamp prior to the timestamp for the signaling that > |> >>> indicates the send state of the participant. This could > cause > |> >>> trouble in playback. > |> >>> > |> >>> - There isn't any guarantee that the clock used for signaling > |> >>> messages is synchronized with the clock used in RTP/RTCP. > |> >>> > |> >>> - There isn't any guarantee that there will be any RTCP at all, > |> >>> to provide correlation of the RTP to clocktime. > |> >>> > |> >>> The best I can see to deal with all of this is: > |> >>> > |> >>> - All the metadata messages should be timestamped by the SRC > |> >>> using its local clock. This is easily achieved by the Date > |> >>> header in the sip message. > |> >>> > |> >>> - Changes to a CS, including changes of participants, should > |> >>> be explicitly tagged with the time they occurred in the > |> >>> CS signaling, according to the SRC's clock. (If that is > |> >>> unavailable for some reason, then use the time the SRC > |> >>> became aware of it.) > |> >>> > |> >>> - We could provide a metadata update element to indicate end > |> >>> of a CS, but I suggest this just be shorthand for > indicating > |> >>> removal of all participants from it. (While its possible to > |> >>> mark that the CS is truly ended, that simply introduces an > |> >>> error case if added metadata about it is subsequently > sent.) > |> >>> The actual start/stop time would be determined by the SRS > |> >>> based on the timestamps of first and last data about it. > |> >>> > |> >>> - Changes to media streams should similarly be tagged with > |> >>> the time they occurred in the CS signaling. Each > participant > |> >>> relationship change (send, receive, inactive,) will be > there. > |> >>> The actual start/stop time of the media stream again would > be > |> >>> derived by the SRS. > |> >>> > |> >>> - CS-Groups can simply be tagged by the timestamps of the > |> >>> updates that put CSs into them. Explicit start/stop times > |> don't > |> >>> seem useful. If desired, the SRS can derive start/stop > times > |> >>> from the start/stop times of the contained stuff. > |> >>> > |> >>> - I now think that CS-Groups should not be "contained" within > |> >>> a recording. This just seems to introduce unnecessary error > |> >>> conditions, and limitations on future enhancements. The > |> >>> lifetime of CS-Groups will probably be naturally limited by > |> >>> the ability of the SRC to remember the IDs of old ones. > |> >>> For instance, if a CS-G is created during one Recording, > |> >>> and then another CS is added to it from a different > recording > |> >>> session, would we prefer to fail that, or just allow it? > |> >>> (I think allow.) > |> >>> > |> >>> - Rather, I think every update transmitted during a recording > |> >>> session can be tagged with a link to the metadata of the > |> >>> recording session it came from. This need not be explicit - > |> the > |> >>> SRS can do it automatically. The recording session entity > |> >>> itself will also have a start/stop time which is the start/ > |> >>> stop of the RS dialog as observed by the SRS. > |> >>> > |> >>> (Note the above doesn't solve the problem of getting correct > clock > |> >>> times for RTP media. If anyone has a suggestion for this I'm all > |> >>> ears.) > |> >>> > |> >>> Thanks, > |> >>> Paul > |> >>> _______________________________________________ > |> >>> siprec mailing 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 > | > | > |---------------------------------------------------------------------- > - > ------------------------------- > |------------- > |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. > | > |_______________________________________________ > |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 yuepeiyu@huawei.com Tue Apr 12 19:09:57 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 15899E06F0 for ; Tue, 12 Apr 2011 19:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.8 X-Spam-Level: X-Spam-Status: No, score=-98.8 tagged_above=-999 required=5 tests=[AWL=-3.394, BAYES_00=-2.599, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MANGLED_VIDEO=2.3, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLmKXLCvwl2L for ; Tue, 12 Apr 2011 19:09:56 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by ietfc.amsl.com (Postfix) with ESMTP id C4851E06C3 for ; Tue, 12 Apr 2011 19:09:51 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJK00ASZJBZC4@szxga05-in.huawei.com> for siprec@ietf.org; Wed, 13 Apr 2011 10:09:35 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJK000O3JBYVE@szxga05-in.huawei.com> for siprec@ietf.org; Wed, 13 Apr 2011 10:09:34 +0800 (CST) Received: from Y58865A ([10.138.73.89]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LJK00JKWJBU3Y@szxml06-in.huawei.com> for siprec@ietf.org; Wed, 13 Apr 2011 10:09:34 +0800 (CST) Date: Wed, 13 Apr 2011 10:09:30 +0800 From: Roy In-reply-to: <101C6067BEC68246B0C3F6843BCCC1E30B6D5C888D@MCHP058A.global-ad.net> To: "'Hutton, Andrew'" , "'Elwell, John'" , siprec@ietf.org Message-id: <00d201cbf97f$d2e22570$78a67050$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=gb2312 Content-language: zh-cn Content-transfer-encoding: quoted-printable Thread-index: Acv42ubXHfPE7b2ZSIutkk8YPChNPgABXVYQAAUKXIAAIklWQA== References: <007b01cbf8da$e72ff570$b58fe050$@com> <101C6067BEC68246B0C3F6843BCCC1E30B6D5C888D@MCHP058A.global-ad.net> Subject: Re: [siprec] Question on the scope X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 13 Apr 2011 02:09:57 -0000 Hi Andy, The session between UA-A and the Media Server does not convey any media. This SIP session mainly tells the B2BUA what to be recorded. As background, to watch a IPTV program, the UA-A initiates a SIP session = to setup a media session between UA-A and Media Server. The media session = could be a unicast or multicast session. While in the NPVR case, the user (with UA-A) may not be able to watch = the live program, and want to record and watch the program at a later time.=20 Therefore, when initiates the recording session, the UA-A will only = tells what to record, without any media conveying.=20 Hope this clarifies! Best regards, Roy -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: Hutton, Andrew = [mailto:andrew.hutton@siemens-enterprise.com]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA4=D4=C212=C8=D5 17:37 =CA=D5=BC=FE=C8=CB: Elwell, John; Roy; siprec@ietf.org =D6=F7=CC=E2: RE: [siprec] Question on the scope Hi Roy, Your diagram shows a SIP session from UA-A to the B2BUA and between the B2BUA and the Media Server. I assume this is logically a session between = the UA-A and the Media Server with the B2BUA in the middle.=20 Does this session convey any media between UA-A and the Media Server and = if so what is the relationship between this and the media sent to the = recording server? What is the SIP Session used for at UA-A? Regards Andy > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > Sent: 12 April 2011 08:14 > To: Roy; siprec@ietf.org > Subject: Re: [siprec] Question on the scope >=20 > Roy, >=20 > I am not sure I understand your use case correctly, but it=20 > seems some content from inside a media server is being=20 > recorded, as opposed to recording content that is transported=20 > between two or more users as part of a communication session.=20 > I believe that is outside the scope of the working group. See=20 > the charter and draft-ietf-siprec-req (requirements). Our=20 > work is concerned with recording a session, so content that=20 > is held internally to a media server, as opposed to being=20 > transported as part of a session is out of scope. >=20 > John >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org=20 > > [mailto:siprec-bounces@ietf.org] On Behalf Of Roy > > Sent: 12 April 2011 07:29 > > To: siprec@ietf.org > > Subject: [siprec] Question on the scope > >=20 > > Hello > >=20 > > =20 > >=20 > > I find this work group during Prague meeting. The work here=20 > > is quite interesting although I have some questions as below: > >=20 > > =20 > >=20 > > All through the architecture and requirement document, we are=20 > > talking about recording a media session between two UA.=20 > >=20 > > However, there is also use cases that a UA1 requests a=20 > > recording server (SRS) to record a media content in media=20 > > server (UA2) while there is not any direct media session=20 > > between UA1 and media server. Following is a general architecture. > >=20 > > +-----------+ > >=20 > > (Recording Session) | | > >=20 > > ; +----- ding | > >=20 > > | | Server | > >=20 > > | +---MetaData---->| | > >=20 > > &n | +-----------+ > >=20 > > | | ^ > >=20 > > | | | > >=20 > > &n sp; | | RTP > >=20 > > V V unicast or multicast > >=20 > > +------------------+ | > >=20 > > nbsp; | B2BUA | | > >=20 > > +--------+ | Service Control | +---------+ > >=20 > > | |<- SIP ->| Function |<- SIP ->| | > >=20 > > | UA-A | +--------- -------- ; | Media | > >=20 > > | | | Server | > >=20 > > +--------+ +---------+ > >=20 > > =20 > >=20 > > This case is very common in IPTV industry, known as Network=20 > > Personal Vide o Record ery similar with the work here. > >=20 > > Does current document cover this use case already or did you=20 > > discussed similar case ever? > >=20 > > =20 > >=20 > > Many thanks and best regards, > >=20 > > Roy > >=20 > >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec >=20 From partr@cisco.com Tue Apr 12 22:50:34 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 31F91E06CE for ; Tue, 12 Apr 2011 22:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.94 X-Spam-Level: X-Spam-Status: No, score=-9.94 tagged_above=-999 required=5 tests=[AWL=0.659, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrRsSQgZxsg0 for ; Tue, 12 Apr 2011 22:50:31 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfc.amsl.com (Postfix) with ESMTP id 93E6AE0695 for ; Tue, 12 Apr 2011 22:50:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=31501; q=dns/txt; s=iport; t=1302673830; x=1303883430; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=phGY+t66irhPOqgmvlyX6Ylf93nbQQJS6muG7Guw54I=; b=AzAMQmmURmzNoJZ9+RAXgGCzIa0dm92/VBUqcAvPEPwah4rOza8Aj9Yk SiRjSqXGKGV0uKpy2GGvboeGrd6PC4LNOiIzXuskAw87FHKtkOnTI0+uH ukJSwJNag4GZ+mvs9epfK4luZWmcgKhmuZMCpTeyoZsY18VXyGyUO/2zP M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AusAAC05pU2Q/khR/2dsb2JhbACYHo1pd4h6nkydAYJ+gnAEhVyMBg X-IronPort-AV: E=Sophos;i="4.64,202,1301875200"; d="scan'208";a="25489915" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 13 Apr 2011 05:50:26 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3D5oP4N014323; Wed, 13 Apr 2011 05:50:26 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Apr 2011 11:20:00 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CBF99E.A090034D" Date: Wed, 13 Apr 2011 11:20:00 +0530 Message-ID: In-Reply-To: <059AF07365DC474393A19A3AF187DF7406EF2378@NAHALD.us.int.genesyslab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] start/stop times & the metamodel Thread-Index: Acv4ar9mNRoQAPkwSImkiZlfghuuTgAIWrigAApMiDAAJ/uhEAASQRUg References: <4D9CDADD.1020403@cisco.com> <4DA2FC17.1060100@cisco.com><07465C1D981ABC41A344374066AE1A2C38AB6E1DE4@TLVMBX01.nice.com><4DA334F0.9050301@cisco.com><059AF07365DC474393A19A3AF187DF7406E67CB4@NAHALD.us.int.genesyslab.com><1D062974A4845E4D8A343C65380492020533B45B@XMB-BGL-414.cisco.com> <059AF07365DC474393A19A3AF187DF7406EF2378@NAHALD.us.int.genesyslab.com> From: "Parthasarathi R (partr)" To: "Henry Lum" , "Muthu ArulMozhi Perumal (mperumal)" , "Paul Kyzivat (pkyzivat)" , "Leon Portman" X-OriginalArrivalTime: 13 Apr 2011 05:50:00.0773 (UTC) FILETIME=[A0C6E750:01CBF99E] Cc: siprec@ietf.org Subject: Re: [siprec] start/stop times & the metamodel X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 13 Apr 2011 05:50:34 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBF99E.A090034D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Henry, I attached the follow up mail to below mail thread. Till now, We don't have strong requirement to solve in SIPREC. Let us identify the requirement before going to the solution. Thanks Partha -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Henry Lum Sent: Wednesday, April 13, 2011 2:43 AM To: Muthu ArulMozhi Perumal (mperumal); Paul Kyzivat (pkyzivat); Leon Portman Cc: siprec@ietf.org Subject: Re: [siprec] start/stop times & the metamodel I don't think it is guaranteed that participants will send SR reports (or any RTCP), plus we will also have to assume that the NTP timestamps are in sync. We could mandate the SRC to generate SR reports but then we are fixing the RTP model for the SRC.=20 Regards, Henry > -----Original Message----- > From: Muthu ArulMozhi Perumal (mperumal) [mailto:mperumal@cisco.com] > Sent: Monday, April 11, 2011 10:45 PM > To: Henry Lum; Paul Kyzivat (pkyzivat); Leon Portman > Cc: siprec@ietf.org > Subject: RE: [siprec] start/stop times & the metamodel >=20 > While I see it may be useful for the SRS to know when certain things=20 > happened in CS signaling (participant joining, leaving, going mute etc) > I don't see how useful it would be for it know how those things are=20 > related to when the participant actually sent/received (or stopped > sending/receiving) RTP. >=20 > If we see any use, one way to do it is using the NTP timestamp carried > in RTCP SR reports, provided the SRC, SRS and the participants have=20 > access to the same reference wallclock. >=20 > Muthu >=20 > |-----Original Message----- > |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Henry Lum > |Sent: Tuesday, April 12, 2011 2:56 AM > |To: Paul Kyzivat (pkyzivat); Leon Portman > |Cc: siprec@ietf.org > |Subject: Re: [siprec] start/stop times & the metamodel > | > |A related question on the RTP model is that if the SRC as an RTP=20 > |translator chooses to relay the RTP timestamps, then how would the SRC > |synchronize the timestamps between the SIP messages the multiple RTP=20 > |streams? > | > |Henry > | > |> -----Original Message----- > |> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > |> Behalf Of Paul Kyzivat > |> Sent: Monday, April 11, 2011 1:06 PM > |> To: Leon Portman > |> Cc: siprec@ietf.org > |> Subject: Re: [siprec] start/stop times & the metamodel > |> > |> > |> > |> On 4/11/2011 9:36 AM, Leon Portman wrote: > |> > Paul Hi > |> > > |> > I agree with proposed method of time stamping metadata elements > with > |> SRC clock (it is like a wall clock from the requirement document). > |> > About RTP time synchronization to metadata events, we either > should > |> have some low latency event from SRC to SRS with SRC time that will > |> allow SRS to maintain time difference between its clock and SRC > clock > |> and then apply it also to receive time of RTP packet (assuming no > |> buffering) > |> > |> ISTM the issue isn't the latency of the event - it is what it is - > but > |> rather how to correlate a sip message containing metadata with a=20 > |> particular RTP packet. I suspect that needs to be tied into the=20 > |> discussion of the various models for how the SRC might handle RDP. > |> > |> Thanks, > |> Paul > |> > |> > Leon > |> > > |> > -----Original Message----- > |> > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > |> Behalf Of Paul Kyzivat > |> > Sent: Monday, April 11, 2011 4:03 PM > |> > To: Elwell, John > |> > Cc: siprec@ietf.org > |> > Subject: Re: [siprec] start/stop times& the metamodel > |> > > |> > > |> > > |> > On 4/8/2011 11:53 AM, Elwell, John wrote: > |> >> Paul, > |> >> > |> >> I think much of what you say makes sense. I was concerned that we > |> probably need to record when a participant stops or starts sending > or > |> receiving a stream, which seems to be covered by your statement: > |> "Changes to media streams should similarly be tagged with the time > |they > |> occurred in the CS signaling. Each participant relationship change=20 > |> (send, receive, inactive,) will be there." That doesn't seem to be > in > |> the model at present. > |> > > |> > John, > |> > > |> > I agree the current model doesn't reflect this - it was a private > |> thought by me, provoked by the work and discussion to date. It is a > |bit > |> of a change of direction, so I'm interested in what others think > about > |> it. > |> > > |> > Thanks, > |> > Paul > |> > > |> >> John (as individual) > |> >> > |> >> > |> >>> -----Original Message----- > |> >>> From: siprec-bounces@ietf.org > |> >>> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > |> >>> Sent: 06 April 2011 22:28 > |> >>> To: siprec@ietf.org > |> >>> Subject: [siprec] start/stop times& the metamodel > |> >>> > |> >>> In Prague, one of the open issues was around start/stop times. > The > |> >>> format draft floated the possibility of having explicit > start/stop > |> >>> times signaled for each of the metatdata elements. But then we > |> asked > |> >>> for feedback on which make sense. > |> >>> > |> >>> IMO explicit start/stop times make more sense for some things > than > |> >>> others. > |> >>> > |> >>> One place where we potentially have explicit times to report > with > |> the > |> >>> dialogs that constitute a CS. Each such dialog presumably has a > |> start > |> >>> and stop time observable by the SRC, which might differ, at > least > |a > |> >>> bit, from the corresponding signaling on the RS. > |> >>> > |> >>> We might want to report those times. Or, since we abstract the > CS > |> >>> away from the dialog, we might want to report the start time of > |the > |> >>> first dialog in the CS as the CS start time, and the stop time > of > |> the > |> >>> last dialog in the CS as the CS stop time. > |> >>> > |> >>> Similarly, we have abstracted media streams away from the media > |> >>> streams in the sip dialogs that make up the CS. We might want to > |> >>> report the start time of a media stream as the time (according > to > |> the > |> >>> CS) of the first participant to a new media stream, and the stop > |> time > |> >>> as the time that the last participant leaves the media stream. > |> >>> > |> >>> There are several things that complicate this: > |> >>> > |> >>> - Do we consider the case of a stream that starts with recvonly > |> >>> or inactive participants, and only later gets a sender? If > |so, > |> >>> is the start time of the stream when the first participant > |> arrived, > |> >>> or when the first sender arrived? > |> >>> > |> >>> - How do we get the clock times for the media streams? > |> >>> IIUC the correct ones are in the RTP/RTCP, but the > reporting > |> of > |> >>> these events is driven by the signaling, and we don't have > |> good > |> >>> sync between those. (E.g. media could start flowing before > |the > |> >>> corresponding signaling, and we would like to include that > if > |> we > |> >>> can figure it out.) So, even if the clocks used for media > and > |> >>> signaling are in sync, we might see media packets arrive > with > |> >>> a timestamp prior to the timestamp for the signaling that > |> >>> indicates the send state of the participant. This could > cause > |> >>> trouble in playback. > |> >>> > |> >>> - There isn't any guarantee that the clock used for signaling > |> >>> messages is synchronized with the clock used in RTP/RTCP. > |> >>> > |> >>> - There isn't any guarantee that there will be any RTCP at all, > |> >>> to provide correlation of the RTP to clocktime. > |> >>> > |> >>> The best I can see to deal with all of this is: > |> >>> > |> >>> - All the metadata messages should be timestamped by the SRC > |> >>> using its local clock. This is easily achieved by the Date > |> >>> header in the sip message. > |> >>> > |> >>> - Changes to a CS, including changes of participants, should > |> >>> be explicitly tagged with the time they occurred in the > |> >>> CS signaling, according to the SRC's clock. (If that is > |> >>> unavailable for some reason, then use the time the SRC > |> >>> became aware of it.) > |> >>> > |> >>> - We could provide a metadata update element to indicate end > |> >>> of a CS, but I suggest this just be shorthand for > indicating > |> >>> removal of all participants from it. (While its possible to > |> >>> mark that the CS is truly ended, that simply introduces an > |> >>> error case if added metadata about it is subsequently > sent.) > |> >>> The actual start/stop time would be determined by the SRS > |> >>> based on the timestamps of first and last data about it. > |> >>> > |> >>> - Changes to media streams should similarly be tagged with > |> >>> the time they occurred in the CS signaling. Each > participant > |> >>> relationship change (send, receive, inactive,) will be > there. > |> >>> The actual start/stop time of the media stream again would > be > |> >>> derived by the SRS. > |> >>> > |> >>> - CS-Groups can simply be tagged by the timestamps of the > |> >>> updates that put CSs into them. Explicit start/stop times > |> don't > |> >>> seem useful. If desired, the SRS can derive start/stop > times > |> >>> from the start/stop times of the contained stuff. > |> >>> > |> >>> - I now think that CS-Groups should not be "contained" within > |> >>> a recording. This just seems to introduce unnecessary error > |> >>> conditions, and limitations on future enhancements. The > |> >>> lifetime of CS-Groups will probably be naturally limited by > |> >>> the ability of the SRC to remember the IDs of old ones. > |> >>> For instance, if a CS-G is created during one Recording, > |> >>> and then another CS is added to it from a different > recording > |> >>> session, would we prefer to fail that, or just allow it? > |> >>> (I think allow.) > |> >>> > |> >>> - Rather, I think every update transmitted during a recording > |> >>> session can be tagged with a link to the metadata of the > |> >>> recording session it came from. This need not be explicit - > |> the > |> >>> SRS can do it automatically. The recording session entity > |> >>> itself will also have a start/stop time which is the start/ > |> >>> stop of the RS dialog as observed by the SRS. > |> >>> > |> >>> (Note the above doesn't solve the problem of getting correct > clock > |> >>> times for RTP media. If anyone has a suggestion for this I'm all > |> >>> ears.) > |> >>> > |> >>> Thanks, > |> >>> Paul > |> >>> _______________________________________________ > |> >>> siprec mailing 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 > | > | > |---------------------------------------------------------------------- > - > ------------------------------- > |------------- > |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. > | > |_______________________________________________ > |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 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. =09 _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec ------_=_NextPart_001_01CBF99E.A090034D Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from xbh-bgl-411.cisco.com ([72.163.129.201]) by xmb-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Apr 2011 15:08:41 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Received: from xbh-rcd-301.cisco.com ([72.163.63.8]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Apr 2011 15:08:41 +0530 Received: from sj-iport-3.cisco.com ([171.71.176.72]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Apr 2011 04:38:20 -0500 Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-3.cisco.com with ESMTP; 12 Apr 2011 09:38:15 +0000 Received: from sj-inbound-b.cisco.com (sj-inbound-b.cisco.com [128.107.234.205]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3C9cADc032653; Tue, 12 Apr 2011 09:38:15 GMT Received: from mail.ietf.org ([208.66.40.236]) by sj-inbound-b.cisco.com with ESMTP; 12 Apr 2011 09:38:14 +0000 Received: from ietfc.amsl.com (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 18048E06D5; Tue, 12 Apr 2011 02:38:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 47E89E06D4 for ; Tue, 12 Apr 2011 02:38:13 -0700 (PDT) Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X0YNxW2pPtnb for ; Tue, 12 Apr 2011 02:38:11 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfc.amsl.com (Postfix) with ESMTP id E87B3E06BE for ; Tue, 12 Apr 2011 02:38:10 -0700 (PDT) Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 12 Apr 2011 09:38:10 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3C9bnMX026072; Tue, 12 Apr 2011 09:38:09 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Apr 2011 15:08:00 +0530 Content-class: urn:content-classes:message Subject: Re: [siprec] start/stop times & the metamodel Date: Tue, 12 Apr 2011 15:08:00 +0530 Message-ID: In-Reply-To: <1D062974A4845E4D8A343C65380492020533B572@XMB-BGL-414.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] start/stop times & the metamodel Thread-Index: Acv4ar9mNRoQAPkwSImkiZlfghuuTgAIWrigAApMiDAABxSCkAAEak0wAANKJPA= References: <4D9CDADD.1020403@cisco.com> <4DA2FC17.1060100@cisco.com><07465C1D981ABC41A344374066AE1A2C38AB6E1DE4@TLVMBX01.nice.com><4DA334F0.9050301@cisco.com><059AF07365DC474393A19A3AF187DF7406E67CB4@NAHALD.us.int.genesyslab.com><1D062974A4845E4D8A343C65380492020533B45B@XMB-BGL-414.cisco.com><1D062974A4845E4D8A343C65380492020533B572@XMB-BGL-414.cisco.com> List-Help: List-Subscribe: , List-Unsubscribe: , From: "Parthasarathi R (partr)" Sender: To: "Muthu ArulMozhi Perumal (mperumal)" , "Henry Lum" , "Paul Kyzivat (pkyzivat)" , "Leon Portman" Cc: Muthu, I agree with you that till now there is no strong usecase for SRS to have the timestamp information about media (RTP/RTCP) packets.=20 I added further and mentioned even if somebody looks for it, the timestamp information about media packet is not possible to be achieved in all architecture without delay/latency. Thanks Partha=20 -----Original Message----- From: Muthu ArulMozhi Perumal (mperumal)=20 Sent: Tuesday, April 12, 2011 1:17 PM To: Parthasarathi R (partr); 'Henry Lum'; Paul Kyzivat (pkyzivat); 'Leon Portman' Cc: 'siprec@ietf.org' Subject: RE: [siprec] start/stop times & the metamodel |In case AS & MS are two different physical devices, it is highly tough=20 |to sync CS RTP timestamp with RS metadata timestamp because the delay=20 |between AS & MS communication for RTP timestamp has to be considered. As Paul mentioned before, the delay/latency b/w call signaling and media is what it is -- I don't see it as a problem as well. The question is whether there is need to correlate the time of occurrence of events conveyed through call signaling with the transmission/reception time of media packets when those events occurred -- I don't see why the SRC/SRS would find that useful, yet. Muthu |-----Original Message----- |From: Parthasarathi R (partr) |Sent: Tuesday, April 12, 2011 12:11 PM |To: Muthu ArulMozhi Perumal (mperumal); Henry Lum; Paul Kyzivat=20 |(pkyzivat); Leon Portman |Cc: siprec@ietf.org |Subject: RE: [siprec] start/stop times & the metamodel | |This is one of the usecase wherein I'm interested in SRC architecture=20 |with Application server (AS) & Media server (MS) as a different logical |entity. In case AS & MS are two different physical devices, it is=20 |highly tough to sync CS RTP timestamp with RS metadata timestamp=20 |because the delay between AS & MS communication for RTP timestamp has to be considered. IMO, AS has to aware of the change in the signaling plane and inform in RS metadata with timestamp rather than depend upon media (RTP). | |Thanks |Partha | |-----Original Message----- |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 |Behalf Of Muthu ArulMozhi Perumal |(mperumal) |Sent: Tuesday, April 12, 2011 8:15 AM |To: Henry Lum; Paul Kyzivat (pkyzivat); Leon Portman |Cc: siprec@ietf.org |Subject: Re: [siprec] start/stop times & the metamodel | |While I see it may be useful for the SRS to know when certain things=20 |happened in CS signaling (participant joining, leaving, going mute etc) |I don't see how useful it would be for it know how those things are=20 |related to when the participant actually sent/received (or stopped |sending/receiving) RTP. | |If we see any use, one way to do it is using the NTP timestamp carried=20 |in RTCP SR reports, provided the SRC, SRS and the participants have access to the same reference wallclock. | |Muthu | ||-----Original Message----- ||From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On |Behalf Of Henry Lum ||Sent: Tuesday, April 12, 2011 2:56 AM ||To: Paul Kyzivat (pkyzivat); Leon Portman ||Cc: siprec@ietf.org ||Subject: Re: [siprec] start/stop times & the metamodel || ||A related question on the RTP model is that if the SRC as an RTP=20 ||translator chooses to relay the RTP timestamps, then how would the SRC ||synchronize the timestamps between the SIP messages the multiple RTP=20 ||streams? || ||Henry || ||> -----Original Message----- ||> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 ||> Behalf Of Paul Kyzivat ||> Sent: Monday, April 11, 2011 1:06 PM ||> To: Leon Portman ||> Cc: siprec@ietf.org ||> Subject: Re: [siprec] start/stop times & the metamodel ||> ||> ||> ||> On 4/11/2011 9:36 AM, Leon Portman wrote: ||> > Paul Hi ||> > ||> > I agree with proposed method of time stamping metadata elements |with ||> SRC clock (it is like a wall clock from the requirement document). ||> > About RTP time synchronization to metadata events, we either=20 ||> > should ||> have some low latency event from SRC to SRS with SRC time that will=20 ||> allow SRS to maintain time difference between its clock and SRC=20 ||> clock and then apply it also to receive time of RTP packet (assuming ||> no ||> buffering) ||> ||> ISTM the issue isn't the latency of the event - it is what it is - |but ||> rather how to correlate a sip message containing metadata with a=20 ||> particular RTP packet. I suspect that needs to be tied into the=20 ||> discussion of the various models for how the SRC might handle RDP. ||> ||> Thanks, ||> Paul ||> ||> > Leon ||> > ||> > -----Original Message----- ||> > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On ||> Behalf Of Paul Kyzivat ||> > Sent: Monday, April 11, 2011 4:03 PM ||> > To: Elwell, John ||> > Cc: siprec@ietf.org ||> > Subject: Re: [siprec] start/stop times& the metamodel ||> > ||> > ||> > ||> > On 4/8/2011 11:53 AM, Elwell, John wrote: ||> >> Paul, ||> >> ||> >> I think much of what you say makes sense. I was concerned that we ||> probably need to record when a participant stops or starts sending=20 ||> or receiving a stream, which seems to be covered by your statement: ||> "Changes to media streams should similarly be tagged with the time ||they ||> occurred in the CS signaling. Each participant relationship change=20 ||> (send, receive, inactive,) will be there." That doesn't seem to be=20 ||> in the model at present. ||> > ||> > John, ||> > ||> > I agree the current model doesn't reflect this - it was a private ||> thought by me, provoked by the work and discussion to date. It is a ||bit ||> of a change of direction, so I'm interested in what others think |about ||> it. ||> > ||> > Thanks, ||> > Paul ||> > ||> >> John (as individual) ||> >> ||> >> ||> >>> -----Original Message----- ||> >>> From: siprec-bounces@ietf.org ||> >>> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat ||> >>> Sent: 06 April 2011 22:28 ||> >>> To: siprec@ietf.org ||> >>> Subject: [siprec] start/stop times& the metamodel ||> >>> ||> >>> In Prague, one of the open issues was around start/stop times. |The ||> >>> format draft floated the possibility of having explicit |start/stop ||> >>> times signaled for each of the metatdata elements. But then we ||> asked ||> >>> for feedback on which make sense. ||> >>> ||> >>> IMO explicit start/stop times make more sense for some things |than ||> >>> others. ||> >>> ||> >>> One place where we potentially have explicit times to report=20 ||> >>> with ||> the ||> >>> dialogs that constitute a CS. Each such dialog presumably has a ||> start ||> >>> and stop time observable by the SRC, which might differ, at=20 ||> >>> least ||a ||> >>> bit, from the corresponding signaling on the RS. ||> >>> ||> >>> We might want to report those times. Or, since we abstract the=20 ||> >>> CS away from the dialog, we might want to report the start time=20 ||> >>> of ||the ||> >>> first dialog in the CS as the CS start time, and the stop time=20 ||> >>> of ||> the ||> >>> last dialog in the CS as the CS stop time. ||> >>> ||> >>> Similarly, we have abstracted media streams away from the media=20 ||> >>> streams in the sip dialogs that make up the CS. We might want to ||> >>> report the start time of a media stream as the time (according=20 ||> >>> to ||> the ||> >>> CS) of the first participant to a new media stream, and the stop ||> time ||> >>> as the time that the last participant leaves the media stream. ||> >>> ||> >>> There are several things that complicate this: ||> >>> ||> >>> - Do we consider the case of a stream that starts with recvonly ||> >>> or inactive participants, and only later gets a sender? If ||so, ||> >>> is the start time of the stream when the first participant ||> arrived, ||> >>> or when the first sender arrived? ||> >>> ||> >>> - How do we get the clock times for the media streams? ||> >>> IIUC the correct ones are in the RTP/RTCP, but the=20 ||> >>> reporting ||> of ||> >>> these events is driven by the signaling, and we don't have ||> good ||> >>> sync between those. (E.g. media could start flowing before ||the ||> >>> corresponding signaling, and we would like to include that |if ||> we ||> >>> can figure it out.) So, even if the clocks used for media |and ||> >>> signaling are in sync, we might see media packets arrive |with ||> >>> a timestamp prior to the timestamp for the signaling that ||> >>> indicates the send state of the participant. This could |cause ||> >>> trouble in playback. ||> >>> ||> >>> - There isn't any guarantee that the clock used for signaling ||> >>> messages is synchronized with the clock used in RTP/RTCP. ||> >>> ||> >>> - There isn't any guarantee that there will be any RTCP at all, ||> >>> to provide correlation of the RTP to clocktime. ||> >>> ||> >>> The best I can see to deal with all of this is: ||> >>> ||> >>> - All the metadata messages should be timestamped by the SRC ||> >>> using its local clock. This is easily achieved by the Date ||> >>> header in the sip message. ||> >>> ||> >>> - Changes to a CS, including changes of participants, should ||> >>> be explicitly tagged with the time they occurred in the ||> >>> CS signaling, according to the SRC's clock. (If that is ||> >>> unavailable for some reason, then use the time the SRC ||> >>> became aware of it.) ||> >>> ||> >>> - We could provide a metadata update element to indicate end ||> >>> of a CS, but I suggest this just be shorthand for indicating ||> >>> removal of all participants from it. (While its possible to ||> >>> mark that the CS is truly ended, that simply introduces an ||> >>> error case if added metadata about it is subsequently sent.) ||> >>> The actual start/stop time would be determined by the SRS ||> >>> based on the timestamps of first and last data about it. ||> >>> ||> >>> - Changes to media streams should similarly be tagged with ||> >>> the time they occurred in the CS signaling. Each participant ||> >>> relationship change (send, receive, inactive,) will be |there. ||> >>> The actual start/stop time of the media stream again would |be ||> >>> derived by the SRS. ||> >>> ||> >>> - CS-Groups can simply be tagged by the timestamps of the ||> >>> updates that put CSs into them. Explicit start/stop times ||> don't ||> >>> seem useful. If desired, the SRS can derive start/stop times ||> >>> from the start/stop times of the contained stuff. ||> >>> ||> >>> - I now think that CS-Groups should not be "contained" within ||> >>> a recording. This just seems to introduce unnecessary error ||> >>> conditions, and limitations on future enhancements. The ||> >>> lifetime of CS-Groups will probably be naturally limited by ||> >>> the ability of the SRC to remember the IDs of old ones. ||> >>> For instance, if a CS-G is created during one Recording, ||> >>> and then another CS is added to it from a different |recording ||> >>> session, would we prefer to fail that, or just allow it? ||> >>> (I think allow.) ||> >>> ||> >>> - Rather, I think every update transmitted during a recording ||> >>> session can be tagged with a link to the metadata of the ||> >>> recording session it came from. This need not be explicit - ||> the ||> >>> SRS can do it automatically. The recording session entity ||> >>> itself will also have a start/stop time which is the start/ ||> >>> stop of the RS dialog as observed by the SRS. ||> >>> ||> >>> (Note the above doesn't solve the problem of getting correct |clock ||> >>> times for RTP media. If anyone has a suggestion for this I'm all ||> >>> ears.) ||> >>> ||> >>> Thanks, ||> >>> Paul ||> >>> _______________________________________________ ||> >>> siprec mailing 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 || || ||---------------------------------------------------------------------- ||- |------------------------------- ||------------- ||CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain |confidential and proprietary ||information of Alcatel-Lucent and/or its affiliated entities. Access=20 ||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. || ||_______________________________________________ ||siprec mailing 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 ------_=_NextPart_001_01CBF99E.A090034D-- From mperumal@cisco.com Tue Apr 12 23:39:41 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BAD77E06DB for ; Tue, 12 Apr 2011 23:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.749 X-Spam-Level: X-Spam-Status: No, score=-9.749 tagged_above=-999 required=5 tests=[AWL=0.850, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJZN9T27xyuT for ; Tue, 12 Apr 2011 23:39:39 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfc.amsl.com (Postfix) with ESMTP id 07663E06BC for ; Tue, 12 Apr 2011 23:39:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=17911; q=dns/txt; s=iport; t=1302676779; x=1303886379; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=a1rBgzQlJ0XuMSfx1S9ZBfCfTLZCxUPfseFiBBkcPF4=; b=dWCMwx+uj5rKenlDLRM7ezDonhA6cHi6KuwDNuBdMrrhcy+8+rjigSDW iwoduv7w/Z2Iq1Psz7tYbh5o3/XvLpq0Xv6bfi0O1v5x11l4IA47BkZIm o5RtUTreI+HUJPNcZGQqBDVMESeOjAE4mUP4lS4D+sfmtl/ZkFWyddahR g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuQAANtEpU2Q/khMgWdsb2JhbACYHo1pFAEBFiYlp1edBYVuBIVcjAY X-IronPort-AV: E=Sophos;i="4.64,203,1301875200"; d="scan'208";a="25495190" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 13 Apr 2011 06:39:38 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3D6dawp019426; Wed, 13 Apr 2011 06:39:37 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Apr 2011 12:09:35 +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: Wed, 13 Apr 2011 12:09:32 +0530 Message-ID: <1D062974A4845E4D8A343C65380492020533B85E@XMB-BGL-414.cisco.com> In-Reply-To: <4DA44843.9090507@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] start/stop times & the metamodel Thread-Index: Acv5DtYXyc92iuYYT7K9DNfh7z/3tAAbCVNw References: <4D9CDADD.1020403@cisco.com> <4DA2FC17.1060100@cisco.com><07465C1D981ABC41A344374066AE1A2C38AB6E1DE4@TLVMBX01.nice.com><4DA334F0.9050301@cisco.com><059AF07365DC474393A19A3AF187DF7406E67CB4@NAHALD.us.int.genesyslab.com> <1D062974A4845E4D8A343C65380492020533B45B@XMB-BGL-414.cisco.com> <1D062974A4845E4D8A343C65380492020533B572@XMB-BGL-414.cisco.com> <4DA44843.9090507@cisco.com> From: "Muthu ArulMozhi Perumal (mperumal)" To: "Paul Kyzivat (pkyzivat)" , "Parthasarathi R (partr)" X-OriginalArrivalTime: 13 Apr 2011 06:39:35.0843 (UTC) FILETIME=[8E0E8F30:01CBF9A5] Cc: siprec@ietf.org Subject: Re: [siprec] start/stop times & the metamodel X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 13 Apr 2011 06:39:41 -0000 That's a good use-case and I think we need to still consider those aspects of SRC that would enable meaningful interpretation of the recorded data for queries/playback, within the scope of our work.=20 A few possibilities I can think of in the decreasing order of accuracy for synchronization: 1. The SRC is a mixer and does the synchronization b/w the media streams, generating a single (mixed) stream towards the SRS with its own timestamps. It generates metadata with the wallclock time in sync with the recorded media. If needed, it indicates the correlation b/w the wallcalock time and the RTP timestamps by generating RTCP. 2. The SRC is neither a mixer nor a translator, but is capable of rewriting the RTP/RTCP timestamps in the media streams it sends towards the SRS. It generates metadata with the wallclock time in sync with the recorded media. 3. The SRC is a translator capable of indicating only the start/end time of each CS to the SRS. It generates metadata placing the start/stop wallclock time at which it notices the corresponding events in the CS, in the metadata. Muthu=20 |-----Original Message----- |From: Paul Kyzivat (pkyzivat) |Sent: Tuesday, April 12, 2011 6:11 PM |To: Parthasarathi R (partr) |Cc: Muthu ArulMozhi Perumal (mperumal); Henry Lum; Leon Portman; siprec@ietf.org |Subject: Re: [siprec] start/stop times & the metamodel | |The problem I see (which is out of scope for now of our work) is how one |queries/plays back the data and metadata captured by the SRS. Presumably |one wants to look for a particular CS and then play it back, and have |the events unfold in the same sequence they did in realtime. That means |correlating events in the metadata with recorded media. | |And its not just clocks for the signaling vs media. Its also |synchronizing the different media streams. If you have one media stream |from A to B, and another from B to A, then it can be very important to |synchronize those for playback. But they may have been generated with |very different clocks. And there is also the possibility that they |didn't have RTCP at all, and so have no mapping to clock time. | |In some cases there will be insufficient data to precisely synchronize |the clocks, but even an imprecise sync done "at the time" is likely to |be better than trying to figure it out after the fact with insufficient |data. | |The alternative seems to be to partition the recorded media independent |of its clocking, and then associate the start time of the partition with |some metadata that is assumed to have happened at about the same time. |But that doesn't necessarily work very well, especially for persistent |recording. | | Thanks, | Paul | |On 4/12/2011 5:38 AM, Parthasarathi R (partr) wrote: |> Muthu, |> |> I agree with you that till now there is no strong usecase for SRS to |> have the timestamp information about media (RTP/RTCP) packets. |> |> I added further and mentioned even if somebody looks for it, the |> timestamp information about media packet is not possible to be achieved |> in all architecture without delay/latency. |> |> Thanks |> Partha |> |> -----Original Message----- |> From: Muthu ArulMozhi Perumal (mperumal) |> Sent: Tuesday, April 12, 2011 1:17 PM |> To: Parthasarathi R (partr); 'Henry Lum'; Paul Kyzivat (pkyzivat); 'Leon |> Portman' |> Cc: 'siprec@ietf.org' |> Subject: RE: [siprec] start/stop times& the metamodel |> |> |In case AS& MS are two different physical devices, it is highly tough |> |to sync CS RTP timestamp with RS metadata timestamp because the delay |> |between AS& MS communication for RTP timestamp has to be considered. |> |> As Paul mentioned before, the delay/latency b/w call signaling and media |> is what it is -- I don't see it as a problem as well. The question is |> whether there is need to correlate the time of occurrence of events |> conveyed through call signaling with the transmission/reception time of |> media packets when those events occurred -- I don't see why the SRC/SRS |> would find that useful, yet. |> |> Muthu |> |> |-----Original Message----- |> |From: Parthasarathi R (partr) |> |Sent: Tuesday, April 12, 2011 12:11 PM |> |To: Muthu ArulMozhi Perumal (mperumal); Henry Lum; Paul Kyzivat |> |(pkyzivat); Leon Portman |> |Cc: siprec@ietf.org |> |Subject: RE: [siprec] start/stop times& the metamodel |> | |> |This is one of the usecase wherein I'm interested in SRC architecture |> |with Application server (AS)& Media server (MS) as a different logical |> |> |entity. In case AS& MS are two different physical devices, it is |> |highly tough to sync CS RTP timestamp with RS metadata timestamp |> |because the delay between AS& MS communication for RTP timestamp has |> to be considered. IMO, AS has to aware of the change in the signaling |> plane and inform in RS metadata with timestamp rather than depend upon |> media (RTP). |> | |> |Thanks |> |Partha |> | |> |-----Original Message----- |> |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On |> |Behalf Of Muthu ArulMozhi Perumal |> |(mperumal) |> |Sent: Tuesday, April 12, 2011 8:15 AM |> |To: Henry Lum; Paul Kyzivat (pkyzivat); Leon Portman |> |Cc: siprec@ietf.org |> |Subject: Re: [siprec] start/stop times& the metamodel |> | |> |While I see it may be useful for the SRS to know when certain things |> |happened in CS signaling (participant joining, leaving, going mute etc) |> |> |I don't see how useful it would be for it know how those things are |> |related to when the participant actually sent/received (or stopped |> |sending/receiving) RTP. |> | |> |If we see any use, one way to do it is using the NTP timestamp carried |> |in RTCP SR reports, provided the SRC, SRS and the participants have |> access to the same reference wallclock. |> | |> |Muthu |> | |> ||-----Original Message----- |> ||From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On |> |Behalf Of Henry Lum |> ||Sent: Tuesday, April 12, 2011 2:56 AM |> ||To: Paul Kyzivat (pkyzivat); Leon Portman |> ||Cc: siprec@ietf.org |> ||Subject: Re: [siprec] start/stop times& the metamodel |> || |> ||A related question on the RTP model is that if the SRC as an RTP |> ||translator chooses to relay the RTP timestamps, then how would the SRC |> |> ||synchronize the timestamps between the SIP messages the multiple RTP |> ||streams? |> || |> ||Henry |> || |> ||> -----Original Message----- |> ||> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On |> ||> Behalf Of Paul Kyzivat |> ||> Sent: Monday, April 11, 2011 1:06 PM |> ||> To: Leon Portman |> ||> Cc: siprec@ietf.org |> ||> Subject: Re: [siprec] start/stop times& the metamodel |> ||> |> ||> |> ||> |> ||> On 4/11/2011 9:36 AM, Leon Portman wrote: |> ||> > Paul Hi |> ||> > |> ||> > I agree with proposed method of time stamping metadata elements |> |with |> ||> SRC clock (it is like a wall clock from the requirement document). |> ||> > About RTP time synchronization to metadata events, we either |> ||> > should |> ||> have some low latency event from SRC to SRS with SRC time that will |> ||> allow SRS to maintain time difference between its clock and SRC |> ||> clock and then apply it also to receive time of RTP packet (assuming |> |> ||> no |> ||> buffering) |> ||> |> ||> ISTM the issue isn't the latency of the event - it is what it is - |> |but |> ||> rather how to correlate a sip message containing metadata with a |> ||> particular RTP packet. I suspect that needs to be tied into the |> ||> discussion of the various models for how the SRC might handle RDP. |> ||> |> ||> Thanks, |> ||> Paul |> ||> |> ||> > Leon |> ||> > |> ||> > -----Original Message----- |> ||> > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On |> ||> Behalf Of Paul Kyzivat |> ||> > Sent: Monday, April 11, 2011 4:03 PM |> ||> > To: Elwell, John |> ||> > Cc: siprec@ietf.org |> ||> > Subject: Re: [siprec] start/stop times& the metamodel |> ||> > |> ||> > |> ||> > |> ||> > On 4/8/2011 11:53 AM, Elwell, John wrote: |> ||> >> Paul, |> ||> >> |> ||> >> I think much of what you say makes sense. I was concerned that we |> ||> probably need to record when a participant stops or starts sending |> ||> or receiving a stream, which seems to be covered by your statement: |> ||> "Changes to media streams should similarly be tagged with the time |> ||they |> ||> occurred in the CS signaling. Each participant relationship change |> ||> (send, receive, inactive,) will be there." That doesn't seem to be |> ||> in the model at present. |> ||> > |> ||> > John, |> ||> > |> ||> > I agree the current model doesn't reflect this - it was a private |> ||> thought by me, provoked by the work and discussion to date. It is a |> ||bit |> ||> of a change of direction, so I'm interested in what others think |> |about |> ||> it. |> ||> > |> ||> > Thanks, |> ||> > Paul |> ||> > |> ||> >> John (as individual) |> ||> >> |> ||> >> |> ||> >>> -----Original Message----- |> ||> >>> From: siprec-bounces@ietf.org |> ||> >>> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat |> ||> >>> Sent: 06 April 2011 22:28 |> ||> >>> To: siprec@ietf.org |> ||> >>> Subject: [siprec] start/stop times& the metamodel |> ||> >>> |> ||> >>> In Prague, one of the open issues was around start/stop times. |> |The |> ||> >>> format draft floated the possibility of having explicit |> |start/stop |> ||> >>> times signaled for each of the metatdata elements. But then we |> ||> asked |> ||> >>> for feedback on which make sense. |> ||> >>> |> ||> >>> IMO explicit start/stop times make more sense for some things |> |than |> ||> >>> others. |> ||> >>> |> ||> >>> One place where we potentially have explicit times to report |> ||> >>> with |> ||> the |> ||> >>> dialogs that constitute a CS. Each such dialog presumably has a |> ||> start |> ||> >>> and stop time observable by the SRC, which might differ, at |> ||> >>> least |> ||a |> ||> >>> bit, from the corresponding signaling on the RS. |> ||> >>> |> ||> >>> We might want to report those times. Or, since we abstract the |> ||> >>> CS away from the dialog, we might want to report the start time |> ||> >>> of |> ||the |> ||> >>> first dialog in the CS as the CS start time, and the stop time |> ||> >>> of |> ||> the |> ||> >>> last dialog in the CS as the CS stop time. |> ||> >>> |> ||> >>> Similarly, we have abstracted media streams away from the media |> ||> >>> streams in the sip dialogs that make up the CS. We might want to |> |> ||> >>> report the start time of a media stream as the time (according |> ||> >>> to |> ||> the |> ||> >>> CS) of the first participant to a new media stream, and the stop |> ||> time |> ||> >>> as the time that the last participant leaves the media stream. |> ||> >>> |> ||> >>> There are several things that complicate this: |> ||> >>> |> ||> >>> - Do we consider the case of a stream that starts with recvonly |> ||> >>> or inactive participants, and only later gets a sender? If |> ||so, |> ||> >>> is the start time of the stream when the first participant |> ||> arrived, |> ||> >>> or when the first sender arrived? |> ||> >>> |> ||> >>> - How do we get the clock times for the media streams? |> ||> >>> IIUC the correct ones are in the RTP/RTCP, but the |> ||> >>> reporting |> ||> of |> ||> >>> these events is driven by the signaling, and we don't have |> ||> good |> ||> >>> sync between those. (E.g. media could start flowing before |> ||the |> ||> >>> corresponding signaling, and we would like to include that |> |if |> ||> we |> ||> >>> can figure it out.) So, even if the clocks used for media |> |and |> ||> >>> signaling are in sync, we might see media packets arrive |> |with |> ||> >>> a timestamp prior to the timestamp for the signaling that |> ||> >>> indicates the send state of the participant. This could |> |cause |> ||> >>> trouble in playback. |> ||> >>> |> ||> >>> - There isn't any guarantee that the clock used for signaling |> ||> >>> messages is synchronized with the clock used in RTP/RTCP. |> ||> >>> |> ||> >>> - There isn't any guarantee that there will be any RTCP at all, |> ||> >>> to provide correlation of the RTP to clocktime. |> ||> >>> |> ||> >>> The best I can see to deal with all of this is: |> ||> >>> |> ||> >>> - All the metadata messages should be timestamped by the SRC |> ||> >>> using its local clock. This is easily achieved by the Date |> ||> >>> header in the sip message. |> ||> >>> |> ||> >>> - Changes to a CS, including changes of participants, should |> ||> >>> be explicitly tagged with the time they occurred in the |> ||> >>> CS signaling, according to the SRC's clock. (If that is |> ||> >>> unavailable for some reason, then use the time the SRC |> ||> >>> became aware of it.) |> ||> >>> |> ||> >>> - We could provide a metadata update element to indicate end |> ||> >>> of a CS, but I suggest this just be shorthand for |> indicating |> ||> >>> removal of all participants from it. (While its possible to |> ||> >>> mark that the CS is truly ended, that simply introduces an |> ||> >>> error case if added metadata about it is subsequently |> sent.) |> ||> >>> The actual start/stop time would be determined by the SRS |> ||> >>> based on the timestamps of first and last data about it. |> ||> >>> |> ||> >>> - Changes to media streams should similarly be tagged with |> ||> >>> the time they occurred in the CS signaling. Each |> participant |> ||> >>> relationship change (send, receive, inactive,) will be |> |there. |> ||> >>> The actual start/stop time of the media stream again would |> |be |> ||> >>> derived by the SRS. |> ||> >>> |> ||> >>> - CS-Groups can simply be tagged by the timestamps of the |> ||> >>> updates that put CSs into them. Explicit start/stop times |> ||> don't |> ||> >>> seem useful. If desired, the SRS can derive start/stop |> times |> ||> >>> from the start/stop times of the contained stuff. |> ||> >>> |> ||> >>> - I now think that CS-Groups should not be "contained" within |> ||> >>> a recording. This just seems to introduce unnecessary error |> ||> >>> conditions, and limitations on future enhancements. The |> ||> >>> lifetime of CS-Groups will probably be naturally limited by |> ||> >>> the ability of the SRC to remember the IDs of old ones. |> ||> >>> For instance, if a CS-G is created during one Recording, |> ||> >>> and then another CS is added to it from a different |> |recording |> ||> >>> session, would we prefer to fail that, or just allow it? |> ||> >>> (I think allow.) |> ||> >>> |> ||> >>> - Rather, I think every update transmitted during a recording |> ||> >>> session can be tagged with a link to the metadata of the |> ||> >>> recording session it came from. This need not be explicit - |> ||> the |> ||> >>> SRS can do it automatically. The recording session entity |> ||> >>> itself will also have a start/stop time which is the start/ |> ||> >>> stop of the RS dialog as observed by the SRS. |> ||> >>> |> ||> >>> (Note the above doesn't solve the problem of getting correct |> |clock |> ||> >>> times for RTP media. If anyone has a suggestion for this I'm all |> ||> >>> ears.) |> ||> >>> |> ||> >>> Thanks, |> ||> >>> Paul |> ||> >>> _______________________________________________ |> ||> >>> siprec mailing 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 |> || |> || |> ||---------------------------------------------------------------------- |> ||- |> |------------------------------- |> ||------------- |> ||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. |> || |> ||_______________________________________________ |> ||siprec mailing 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 mperumal@cisco.com Tue Apr 12 23:44:40 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C50DBE06ED for ; Tue, 12 Apr 2011 23:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.826 X-Spam-Level: X-Spam-Status: No, score=-9.826 tagged_above=-999 required=5 tests=[AWL=0.773, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mq6ZKE3Y3-3h for ; Tue, 12 Apr 2011 23:44:39 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfc.amsl.com (Postfix) with ESMTP id A631FE06EC for ; Tue, 12 Apr 2011 23:44:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=13608; q=dns/txt; s=iport; t=1302677078; x=1303886678; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=CoMtcvj8nqD8wRvJNQN/Ajh8VM1jwjstlX06j/goH6Q=; b=kqncriKXqL2MQ4b7TpriEejoM0ZxUQxylWzsKQUyNoQy53xSjTObxAB5 GAAxmZ+KmWgNLvL9qL20NRcBTzMtZiC4zUzd5vei9tKS6Zqt2T55Movgo oLZ4zTjCGJRU+XKWEmrpAnjsatW0+KvDlzP0+ZDKSty/ONjSUoMyhLedZ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuwAAAhGpU2Q/khR/2dsb2JhbAAjl3uNaXenRJ0FhW4EhVyMBg X-IronPort-AV: E=Sophos;i="4.64,203,1301875200"; d="scan'208";a="25495789" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 13 Apr 2011 06:44:37 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3D6iPW8024993; Wed, 13 Apr 2011 06:44:37 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Apr 2011 12:14:35 +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: Wed, 13 Apr 2011 12:14:35 +0530 Message-ID: <1D062974A4845E4D8A343C65380492020533B864@XMB-BGL-414.cisco.com> In-Reply-To: <059AF07365DC474393A19A3AF187DF7406EF2378@NAHALD.us.int.genesyslab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] start/stop times & the metamodel Thread-Index: Acv4ar9mNRoQAPkwSImkiZlfghuuTgAIWrigAApMiDAAJ/uhEAAUHfJQ References: <4D9CDADD.1020403@cisco.com> <4DA2FC17.1060100@cisco.com><07465C1D981ABC41A344374066AE1A2C38AB6E1DE4@TLVMBX01.nice.com><4DA334F0.9050301@cisco.com> <059AF07365DC474393A19A3AF187DF7406E67CB4@NAHALD.us.int.genesyslab.com> <1D062974A4845E4D8A343C65380492020533B45B@XMB-BGL-414.cisco.com> <059AF07365DC474393A19A3AF187DF7406EF2378@NAHALD.us.int.genesyslab.com> From: "Muthu ArulMozhi Perumal (mperumal)" To: "Henry Lum" , "Paul Kyzivat (pkyzivat)" , "Leon Portman" X-OriginalArrivalTime: 13 Apr 2011 06:44:35.0767 (UTC) FILETIME=[40D35470:01CBF9A6] Cc: siprec@ietf.org Subject: Re: [siprec] start/stop times & the metamodel X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 13 Apr 2011 06:44:40 -0000 Agree, instead of banking on just one model, we need to consider various aspects of the common ones we anticipate, to enable useful interpretation of the recorded data. Muthu |-----Original Message----- |From: Henry Lum [mailto:Henry.Lum@alcatel-lucent.com] |Sent: Wednesday, April 13, 2011 2:43 AM |To: Muthu ArulMozhi Perumal (mperumal); Paul Kyzivat (pkyzivat); Leon Portman |Cc: siprec@ietf.org |Subject: RE: [siprec] start/stop times & the metamodel | |I don't think it is guaranteed that participants will send SR reports |(or any RTCP), plus we will also have to assume that the NTP timestamps |are in sync. We could mandate the SRC to generate SR reports but then we |are fixing the RTP model for the SRC. | |Regards, |Henry | |> -----Original Message----- |> From: Muthu ArulMozhi Perumal (mperumal) [mailto:mperumal@cisco.com] |> Sent: Monday, April 11, 2011 10:45 PM |> To: Henry Lum; Paul Kyzivat (pkyzivat); Leon Portman |> Cc: siprec@ietf.org |> Subject: RE: [siprec] start/stop times & the metamodel |> |> While I see it may be useful for the SRS to know when certain things |> happened in CS signaling (participant joining, leaving, going mute |etc) |> I don't see how useful it would be for it know how those things are |> related to when the participant actually sent/received (or stopped |> sending/receiving) RTP. |> |> If we see any use, one way to do it is using the NTP timestamp carried |> in RTCP SR reports, provided the SRC, SRS and the participants have |> access to the same reference wallclock. |> |> Muthu |> |> |-----Original Message----- |> |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On |> Behalf Of Henry Lum |> |Sent: Tuesday, April 12, 2011 2:56 AM |> |To: Paul Kyzivat (pkyzivat); Leon Portman |> |Cc: siprec@ietf.org |> |Subject: Re: [siprec] start/stop times & the metamodel |> | |> |A related question on the RTP model is that if the SRC as an RTP |> |translator chooses to relay the RTP timestamps, then how would the |SRC |> |synchronize the timestamps between the SIP messages the multiple RTP |> |streams? |> | |> |Henry |> | |> |> -----Original Message----- |> |> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On |> |> Behalf Of Paul Kyzivat |> |> Sent: Monday, April 11, 2011 1:06 PM |> |> To: Leon Portman |> |> Cc: siprec@ietf.org |> |> Subject: Re: [siprec] start/stop times & the metamodel |> |> |> |> |> |> |> |> On 4/11/2011 9:36 AM, Leon Portman wrote: |> |> > Paul Hi |> |> > |> |> > I agree with proposed method of time stamping metadata elements |> with |> |> SRC clock (it is like a wall clock from the requirement document). |> |> > About RTP time synchronization to metadata events, we either |> should |> |> have some low latency event from SRC to SRS with SRC time that will |> |> allow SRS to maintain time difference between its clock and SRC |> clock |> |> and then apply it also to receive time of RTP packet (assuming no |> |> buffering) |> |> |> |> ISTM the issue isn't the latency of the event - it is what it is - |> but |> |> rather how to correlate a sip message containing metadata with a |> |> particular RTP packet. I suspect that needs to be tied into the |> |> discussion of the various models for how the SRC might handle RDP. |> |> |> |> Thanks, |> |> Paul |> |> |> |> > Leon |> |> > |> |> > -----Original Message----- |> |> > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On |> |> Behalf Of Paul Kyzivat |> |> > Sent: Monday, April 11, 2011 4:03 PM |> |> > To: Elwell, John |> |> > Cc: siprec@ietf.org |> |> > Subject: Re: [siprec] start/stop times& the metamodel |> |> > |> |> > |> |> > |> |> > On 4/8/2011 11:53 AM, Elwell, John wrote: |> |> >> Paul, |> |> >> |> |> >> I think much of what you say makes sense. I was concerned that |we |> |> probably need to record when a participant stops or starts sending |> or |> |> receiving a stream, which seems to be covered by your statement: |> |> "Changes to media streams should similarly be tagged with the time |> |they |> |> occurred in the CS signaling. Each participant relationship change |> |> (send, receive, inactive,) will be there." That doesn't seem to be |> in |> |> the model at present. |> |> > |> |> > John, |> |> > |> |> > I agree the current model doesn't reflect this - it was a private |> |> thought by me, provoked by the work and discussion to date. It is a |> |bit |> |> of a change of direction, so I'm interested in what others think |> about |> |> it. |> |> > |> |> > Thanks, |> |> > Paul |> |> > |> |> >> John (as individual) |> |> >> |> |> >> |> |> >>> -----Original Message----- |> |> >>> From: siprec-bounces@ietf.org |> |> >>> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat |> |> >>> Sent: 06 April 2011 22:28 |> |> >>> To: siprec@ietf.org |> |> >>> Subject: [siprec] start/stop times& the metamodel |> |> >>> |> |> >>> In Prague, one of the open issues was around start/stop times. |> The |> |> >>> format draft floated the possibility of having explicit |> start/stop |> |> >>> times signaled for each of the metatdata elements. But then we |> |> asked |> |> >>> for feedback on which make sense. |> |> >>> |> |> >>> IMO explicit start/stop times make more sense for some things |> than |> |> >>> others. |> |> >>> |> |> >>> One place where we potentially have explicit times to report |> with |> |> the |> |> >>> dialogs that constitute a CS. Each such dialog presumably has a |> |> start |> |> >>> and stop time observable by the SRC, which might differ, at |> least |> |a |> |> >>> bit, from the corresponding signaling on the RS. |> |> >>> |> |> >>> We might want to report those times. Or, since we abstract the |> CS |> |> >>> away from the dialog, we might want to report the start time of |> |the |> |> >>> first dialog in the CS as the CS start time, and the stop time |> of |> |> the |> |> >>> last dialog in the CS as the CS stop time. |> |> >>> |> |> >>> Similarly, we have abstracted media streams away from the media |> |> >>> streams in the sip dialogs that make up the CS. We might want |to |> |> >>> report the start time of a media stream as the time (according |> to |> |> the |> |> >>> CS) of the first participant to a new media stream, and the |stop |> |> time |> |> >>> as the time that the last participant leaves the media stream. |> |> >>> |> |> >>> There are several things that complicate this: |> |> >>> |> |> >>> - Do we consider the case of a stream that starts with recvonly |> |> >>> or inactive participants, and only later gets a sender? If |> |so, |> |> >>> is the start time of the stream when the first participant |> |> arrived, |> |> >>> or when the first sender arrived? |> |> >>> |> |> >>> - How do we get the clock times for the media streams? |> |> >>> IIUC the correct ones are in the RTP/RTCP, but the |> reporting |> |> of |> |> >>> these events is driven by the signaling, and we don't have |> |> good |> |> >>> sync between those. (E.g. media could start flowing before |> |the |> |> >>> corresponding signaling, and we would like to include that |> if |> |> we |> |> >>> can figure it out.) So, even if the clocks used for media |> and |> |> >>> signaling are in sync, we might see media packets arrive |> with |> |> >>> a timestamp prior to the timestamp for the signaling that |> |> >>> indicates the send state of the participant. This could |> cause |> |> >>> trouble in playback. |> |> >>> |> |> >>> - There isn't any guarantee that the clock used for signaling |> |> >>> messages is synchronized with the clock used in RTP/RTCP. |> |> >>> |> |> >>> - There isn't any guarantee that there will be any RTCP at all, |> |> >>> to provide correlation of the RTP to clocktime. |> |> >>> |> |> >>> The best I can see to deal with all of this is: |> |> >>> |> |> >>> - All the metadata messages should be timestamped by the SRC |> |> >>> using its local clock. This is easily achieved by the Date |> |> >>> header in the sip message. |> |> >>> |> |> >>> - Changes to a CS, including changes of participants, should |> |> >>> be explicitly tagged with the time they occurred in the |> |> >>> CS signaling, according to the SRC's clock. (If that is |> |> >>> unavailable for some reason, then use the time the SRC |> |> >>> became aware of it.) |> |> >>> |> |> >>> - We could provide a metadata update element to indicate end |> |> >>> of a CS, but I suggest this just be shorthand for |> indicating |> |> >>> removal of all participants from it. (While its possible |to |> |> >>> mark that the CS is truly ended, that simply introduces an |> |> >>> error case if added metadata about it is subsequently |> sent.) |> |> >>> The actual start/stop time would be determined by the SRS |> |> >>> based on the timestamps of first and last data about it. |> |> >>> |> |> >>> - Changes to media streams should similarly be tagged with |> |> >>> the time they occurred in the CS signaling. Each |> participant |> |> >>> relationship change (send, receive, inactive,) will be |> there. |> |> >>> The actual start/stop time of the media stream again would |> be |> |> >>> derived by the SRS. |> |> >>> |> |> >>> - CS-Groups can simply be tagged by the timestamps of the |> |> >>> updates that put CSs into them. Explicit start/stop times |> |> don't |> |> >>> seem useful. If desired, the SRS can derive start/stop |> times |> |> >>> from the start/stop times of the contained stuff. |> |> >>> |> |> >>> - I now think that CS-Groups should not be "contained" within |> |> >>> a recording. This just seems to introduce unnecessary |error |> |> >>> conditions, and limitations on future enhancements. The |> |> >>> lifetime of CS-Groups will probably be naturally limited |by |> |> >>> the ability of the SRC to remember the IDs of old ones. |> |> >>> For instance, if a CS-G is created during one Recording, |> |> >>> and then another CS is added to it from a different |> recording |> |> >>> session, would we prefer to fail that, or just allow it? |> |> >>> (I think allow.) |> |> >>> |> |> >>> - Rather, I think every update transmitted during a recording |> |> >>> session can be tagged with a link to the metadata of the |> |> >>> recording session it came from. This need not be explicit |- |> |> the |> |> >>> SRS can do it automatically. The recording session entity |> |> >>> itself will also have a start/stop time which is the |start/ |> |> >>> stop of the RS dialog as observed by the SRS. |> |> >>> |> |> >>> (Note the above doesn't solve the problem of getting correct |> clock |> |> >>> times for RTP media. If anyone has a suggestion for this I'm |all |> |> >>> ears.) |> |> >>> |> |> >>> Thanks, |> |> >>> Paul |> |> >>> _______________________________________________ |> |> >>> siprec mailing 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 |> | |> | |> ||---------------------------------------------------------------------- |> - |> ------------------------------- |> |------------- |> |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. |> | |> |_______________________________________________ |> |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 mperumal@cisco.com Wed Apr 13 00:05:42 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 12236E0716 for ; Wed, 13 Apr 2011 00:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.89 X-Spam-Level: X-Spam-Status: No, score=-9.89 tagged_above=-999 required=5 tests=[AWL=0.709, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2F1rfQhFf6NT for ; Wed, 13 Apr 2011 00:05:40 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfc.amsl.com (Postfix) with ESMTP id 4644EE0711 for ; Wed, 13 Apr 2011 00:05:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=14391; q=dns/txt; s=iport; t=1302678334; x=1303887934; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=gJZOSePap9TakMqMvYX41GuLfvtM/9Y4QKIhc+lS5CY=; b=as5gRcgBmLOlQ0+gzDD2fNFm8vFfrHaTWJtDEREiB0ugDJ1t6QbEjo3j ZG6aKx98hJxRTLWd6P0yMP7yjvCJXnmQoCvju8Q4FiK91zcavpOVmhEbB ZdTJJupfdZXdMoUdBst+UeMM9U3m6xSaBonVhd7kCXj4UA18alte7dDib o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuQAANxJpU2Q/khNgWdsb2JhbACYHo1pFAEBFiYlpzidBoJ+gnAEhVyMBg X-IronPort-AV: E=Sophos;i="4.64,203,1301875200"; d="scan'208";a="83347206" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 13 Apr 2011 07:05:33 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3D75Vjk017402; Wed, 13 Apr 2011 07:05:32 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Apr 2011 12:35: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: Wed, 13 Apr 2011 12:35:31 +0530 Message-ID: <1D062974A4845E4D8A343C65380492020533B880@XMB-BGL-414.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] start/stop times & the metamodel Thread-Index: Acv4ar9mNRoQAPkwSImkiZlfghuuTgAIWrigAApMiDAAJ/uhEAASQRUgAAJ0TuA= References: <4D9CDADD.1020403@cisco.com> <4DA2FC17.1060100@cisco.com><07465C1D981ABC41A344374066AE1A2C38AB6E1DE4@TLVMBX01.nice.com><4DA334F0.9050301@cisco.com><059AF07365DC474393A19A3AF187DF7406E67CB4@NAHALD.us.int.genesyslab.com><1D062974A4845E4D8A343C65380492020533B45B@XMB-BGL-414.cisco.com> <059AF07365DC474393A19A3AF187DF7406EF2378@NAHALD.us.int.genesyslab.com> From: "Muthu ArulMozhi Perumal (mperumal)" To: "Parthasarathi R (partr)" , "Henry Lum" , "Paul Kyzivat (pkyzivat)" , "Leon Portman" X-OriginalArrivalTime: 13 Apr 2011 07:05:31.0708 (UTC) FILETIME=[2D6CB7C0:01CBF9A9] Cc: siprec@ietf.org Subject: Re: [siprec] start/stop times & the metamodel X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 13 Apr 2011 07:05:42 -0000 After the use-case Paul described, it seem to me that if we keep out of scope it will put a lot of burden on the SRS to support synchronized querying/playback which looks an important aspect for media recording. So, we may want to consider the ways in which the SRC can facilitate it. Muthu |-----Original Message----- |From: Parthasarathi R (partr) |Sent: Wednesday, April 13, 2011 11:20 AM |To: Henry Lum; Muthu ArulMozhi Perumal (mperumal); Paul Kyzivat (pkyzivat); Leon Portman |Cc: siprec@ietf.org |Subject: RE: [siprec] start/stop times & the metamodel | |Henry, | |I attached the follow up mail to below mail thread. Till now, We don't have strong requirement to |solve in SIPREC. Let us identify the requirement before going to the solution. | |Thanks |Partha | |-----Original Message----- |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Henry Lum |Sent: Wednesday, April 13, 2011 2:43 AM |To: Muthu ArulMozhi Perumal (mperumal); Paul Kyzivat (pkyzivat); Leon Portman |Cc: siprec@ietf.org |Subject: Re: [siprec] start/stop times & the metamodel | |I don't think it is guaranteed that participants will send SR reports (or any RTCP), plus we will also |have to assume that the NTP timestamps are in sync. We could mandate the SRC to generate SR reports |but then we are fixing the RTP model for the SRC. | |Regards, |Henry | |> -----Original Message----- |> From: Muthu ArulMozhi Perumal (mperumal) [mailto:mperumal@cisco.com] |> Sent: Monday, April 11, 2011 10:45 PM |> To: Henry Lum; Paul Kyzivat (pkyzivat); Leon Portman |> Cc: siprec@ietf.org |> Subject: RE: [siprec] start/stop times & the metamodel |> |> While I see it may be useful for the SRS to know when certain things |> happened in CS signaling (participant joining, leaving, going mute |etc) |> I don't see how useful it would be for it know how those things are |> related to when the participant actually sent/received (or stopped |> sending/receiving) RTP. |> |> If we see any use, one way to do it is using the NTP timestamp carried |> in RTCP SR reports, provided the SRC, SRS and the participants have |> access to the same reference wallclock. |> |> Muthu |> |> |-----Original Message----- |> |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On |> Behalf Of Henry Lum |> |Sent: Tuesday, April 12, 2011 2:56 AM |> |To: Paul Kyzivat (pkyzivat); Leon Portman |> |Cc: siprec@ietf.org |> |Subject: Re: [siprec] start/stop times & the metamodel |> | |> |A related question on the RTP model is that if the SRC as an RTP |> |translator chooses to relay the RTP timestamps, then how would the |SRC |> |synchronize the timestamps between the SIP messages the multiple RTP |> |streams? |> | |> |Henry |> | |> |> -----Original Message----- |> |> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On |> |> Behalf Of Paul Kyzivat |> |> Sent: Monday, April 11, 2011 1:06 PM |> |> To: Leon Portman |> |> Cc: siprec@ietf.org |> |> Subject: Re: [siprec] start/stop times & the metamodel |> |> |> |> |> |> |> |> On 4/11/2011 9:36 AM, Leon Portman wrote: |> |> > Paul Hi |> |> > |> |> > I agree with proposed method of time stamping metadata elements |> with |> |> SRC clock (it is like a wall clock from the requirement document). |> |> > About RTP time synchronization to metadata events, we either |> should |> |> have some low latency event from SRC to SRS with SRC time that will |> |> allow SRS to maintain time difference between its clock and SRC |> clock |> |> and then apply it also to receive time of RTP packet (assuming no |> |> buffering) |> |> |> |> ISTM the issue isn't the latency of the event - it is what it is - |> but |> |> rather how to correlate a sip message containing metadata with a |> |> particular RTP packet. I suspect that needs to be tied into the |> |> discussion of the various models for how the SRC might handle RDP. |> |> |> |> Thanks, |> |> Paul |> |> |> |> > Leon |> |> > |> |> > -----Original Message----- |> |> > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On |> |> Behalf Of Paul Kyzivat |> |> > Sent: Monday, April 11, 2011 4:03 PM |> |> > To: Elwell, John |> |> > Cc: siprec@ietf.org |> |> > Subject: Re: [siprec] start/stop times& the metamodel |> |> > |> |> > |> |> > |> |> > On 4/8/2011 11:53 AM, Elwell, John wrote: |> |> >> Paul, |> |> >> |> |> >> I think much of what you say makes sense. I was concerned that |we |> |> probably need to record when a participant stops or starts sending |> or |> |> receiving a stream, which seems to be covered by your statement: |> |> "Changes to media streams should similarly be tagged with the time |> |they |> |> occurred in the CS signaling. Each participant relationship change |> |> (send, receive, inactive,) will be there." That doesn't seem to be |> in |> |> the model at present. |> |> > |> |> > John, |> |> > |> |> > I agree the current model doesn't reflect this - it was a private |> |> thought by me, provoked by the work and discussion to date. It is a |> |bit |> |> of a change of direction, so I'm interested in what others think |> about |> |> it. |> |> > |> |> > Thanks, |> |> > Paul |> |> > |> |> >> John (as individual) |> |> >> |> |> >> |> |> >>> -----Original Message----- |> |> >>> From: siprec-bounces@ietf.org |> |> >>> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat |> |> >>> Sent: 06 April 2011 22:28 |> |> >>> To: siprec@ietf.org |> |> >>> Subject: [siprec] start/stop times& the metamodel |> |> >>> |> |> >>> In Prague, one of the open issues was around start/stop times. |> The |> |> >>> format draft floated the possibility of having explicit |> start/stop |> |> >>> times signaled for each of the metatdata elements. But then we |> |> asked |> |> >>> for feedback on which make sense. |> |> >>> |> |> >>> IMO explicit start/stop times make more sense for some things |> than |> |> >>> others. |> |> >>> |> |> >>> One place where we potentially have explicit times to report |> with |> |> the |> |> >>> dialogs that constitute a CS. Each such dialog presumably has a |> |> start |> |> >>> and stop time observable by the SRC, which might differ, at |> least |> |a |> |> >>> bit, from the corresponding signaling on the RS. |> |> >>> |> |> >>> We might want to report those times. Or, since we abstract the |> CS |> |> >>> away from the dialog, we might want to report the start time of |> |the |> |> >>> first dialog in the CS as the CS start time, and the stop time |> of |> |> the |> |> >>> last dialog in the CS as the CS stop time. |> |> >>> |> |> >>> Similarly, we have abstracted media streams away from the media |> |> >>> streams in the sip dialogs that make up the CS. We might want |to |> |> >>> report the start time of a media stream as the time (according |> to |> |> the |> |> >>> CS) of the first participant to a new media stream, and the |stop |> |> time |> |> >>> as the time that the last participant leaves the media stream. |> |> >>> |> |> >>> There are several things that complicate this: |> |> >>> |> |> >>> - Do we consider the case of a stream that starts with recvonly |> |> >>> or inactive participants, and only later gets a sender? If |> |so, |> |> >>> is the start time of the stream when the first participant |> |> arrived, |> |> >>> or when the first sender arrived? |> |> >>> |> |> >>> - How do we get the clock times for the media streams? |> |> >>> IIUC the correct ones are in the RTP/RTCP, but the |> reporting |> |> of |> |> >>> these events is driven by the signaling, and we don't have |> |> good |> |> >>> sync between those. (E.g. media could start flowing before |> |the |> |> >>> corresponding signaling, and we would like to include that |> if |> |> we |> |> >>> can figure it out.) So, even if the clocks used for media |> and |> |> >>> signaling are in sync, we might see media packets arrive |> with |> |> >>> a timestamp prior to the timestamp for the signaling that |> |> >>> indicates the send state of the participant. This could |> cause |> |> >>> trouble in playback. |> |> >>> |> |> >>> - There isn't any guarantee that the clock used for signaling |> |> >>> messages is synchronized with the clock used in RTP/RTCP. |> |> >>> |> |> >>> - There isn't any guarantee that there will be any RTCP at all, |> |> >>> to provide correlation of the RTP to clocktime. |> |> >>> |> |> >>> The best I can see to deal with all of this is: |> |> >>> |> |> >>> - All the metadata messages should be timestamped by the SRC |> |> >>> using its local clock. This is easily achieved by the Date |> |> >>> header in the sip message. |> |> >>> |> |> >>> - Changes to a CS, including changes of participants, should |> |> >>> be explicitly tagged with the time they occurred in the |> |> >>> CS signaling, according to the SRC's clock. (If that is |> |> >>> unavailable for some reason, then use the time the SRC |> |> >>> became aware of it.) |> |> >>> |> |> >>> - We could provide a metadata update element to indicate end |> |> >>> of a CS, but I suggest this just be shorthand for |> indicating |> |> >>> removal of all participants from it. (While its possible |to |> |> >>> mark that the CS is truly ended, that simply introduces an |> |> >>> error case if added metadata about it is subsequently |> sent.) |> |> >>> The actual start/stop time would be determined by the SRS |> |> >>> based on the timestamps of first and last data about it. |> |> >>> |> |> >>> - Changes to media streams should similarly be tagged with |> |> >>> the time they occurred in the CS signaling. Each |> participant |> |> >>> relationship change (send, receive, inactive,) will be |> there. |> |> >>> The actual start/stop time of the media stream again would |> be |> |> >>> derived by the SRS. |> |> >>> |> |> >>> - CS-Groups can simply be tagged by the timestamps of the |> |> >>> updates that put CSs into them. Explicit start/stop times |> |> don't |> |> >>> seem useful. If desired, the SRS can derive start/stop |> times |> |> >>> from the start/stop times of the contained stuff. |> |> >>> |> |> >>> - I now think that CS-Groups should not be "contained" within |> |> >>> a recording. This just seems to introduce unnecessary |error |> |> >>> conditions, and limitations on future enhancements. The |> |> >>> lifetime of CS-Groups will probably be naturally limited |by |> |> >>> the ability of the SRC to remember the IDs of old ones. |> |> >>> For instance, if a CS-G is created during one Recording, |> |> >>> and then another CS is added to it from a different |> recording |> |> >>> session, would we prefer to fail that, or just allow it? |> |> >>> (I think allow.) |> |> >>> |> |> >>> - Rather, I think every update transmitted during a recording |> |> >>> session can be tagged with a link to the metadata of the |> |> >>> recording session it came from. This need not be explicit |- |> |> the |> |> >>> SRS can do it automatically. The recording session entity |> |> >>> itself will also have a start/stop time which is the |start/ |> |> >>> stop of the RS dialog as observed by the SRS. |> |> >>> |> |> >>> (Note the above doesn't solve the problem of getting correct |> clock |> |> >>> times for RTP media. If anyone has a suggestion for this I'm |all |> |> >>> ears.) |> |> >>> |> |> >>> Thanks, |> |> >>> Paul |> |> >>> _______________________________________________ |> |> >>> siprec mailing 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 |> | |> | |> ||---------------------------------------------------------------------- |> - |> ------------------------------- |> |------------- |> |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. |> | |> |_______________________________________________ |> |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. | |_______________________________________________ |siprec mailing list |siprec@ietf.org |https://www.ietf.org/mailman/listinfo/siprec From mperumal@cisco.com Wed Apr 13 00:25:36 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D2A98E0711 for ; Wed, 13 Apr 2011 00:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.945 X-Spam-Level: X-Spam-Status: No, score=-9.945 tagged_above=-999 required=5 tests=[AWL=0.654, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HX83UXgSaDNo for ; Wed, 13 Apr 2011 00:25:35 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfc.amsl.com (Postfix) with ESMTP id 6B859E0723 for ; Wed, 13 Apr 2011 00:25:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=15078; q=dns/txt; s=iport; t=1302679534; x=1303889134; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=lGY6tG05OZWnYAAb6mwfkowYNxD2L4GzI5VNjhBG7uM=; b=KC5HVj2C4UPd0VTiGD9xuWH+GchoORFlozx2ceTbfYHcd/UP9+nbq1C2 qeoi2e3BIyoLEl5N3yzdlA8OIipyVy5lK7pRhqAnmuvvWZCRGnftR6sAI EBXhIhlbg/YuggJnTv72Nv0b6dpX/sEwRA1erXqnOpHVeuIcXkUQFgiMN E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuQAAGdPpU2Q/khNgWdsb2JhbACYH41pFAEBFiYliHqeIZ0GgwCCbgSFXIwG X-IronPort-AV: E=Sophos;i="4.64,203,1301875200"; d="scan'208";a="25501901" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 13 Apr 2011 07:25:30 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3D7PSVJ023362; Wed, 13 Apr 2011 07:25:30 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Apr 2011 12:55:28 +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: Wed, 13 Apr 2011 12:55:28 +0530 Message-ID: <1D062974A4845E4D8A343C65380492020533B88D@XMB-BGL-414.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD060094A3@XMB-BGL-417.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] start/stop times & the metamodel Thread-Index: Acv4SNxgbqUl8VtvRLKQD5NvHQX6rQAlVKGAAAKS0cAAAV1ToAAAMo/QAAGAW9AAAJR2kAAs3aUw References: <4D9CDADD.1020403@cisco.com><4DA2FC17.1060100@cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD06009405@XMB-BGL-417.cisco.com> <1D062974A4845E4D8A343C65380492020533B590@XMB-BGL-414.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD06009443@XMB-BGL-417.cisco.com> <1D062974A4845E4D8A343C65380492020533B5BE@XMB-BGL-414.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD060094A3@XMB-BGL-417.cisco.com> From: "Muthu ArulMozhi Perumal (mperumal)" To: "Ram Mohan R (rmohanr)" , "Elwell, John" , "Paul Kyzivat (pkyzivat)" X-OriginalArrivalTime: 13 Apr 2011 07:25:28.0251 (UTC) FILETIME=[F69EB0B0:01CBF9AB] Cc: siprec@ietf.org Subject: Re: [siprec] start/stop times & the metamodel X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 13 Apr 2011 07:25:37 -0000 |If we are ok to abstract the details and indicate=20 |starting/stopping sending/receiving a media stream, |the current model already does it. Do you see a need=20 |to have anything else in the model to accommodate this ? What is supported currently looks good to me. However, I am thinking if we could carry both the wallclock time and the RTP timestamp in the metadata's media stream object if the later is available to the SRC when this object is generated. This can avoid having to generate RTCP for this purpose alone. Muthu |-----Original Message----- |From: Ram Mohan R (rmohanr) |Sent: Tuesday, April 12, 2011 3:23 PM |To: Elwell, John; Muthu ArulMozhi Perumal (mperumal); Paul Kyzivat (pkyzivat) |Cc: siprec@ietf.org |Subject: RE: [siprec] start/stop times & the metamodel | |Hi John, | |Inline | |> -----Original Message----- |> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] |> Sent: Tuesday, April 12, 2011 3:12 PM |> To: Muthu ArulMozhi Perumal (mperumal); Ram Mohan R (rmohanr); Paul |> Kyzivat (pkyzivat) |> Cc: siprec@ietf.org |> Subject: RE: [siprec] start/stop times & the metamodel |> |> I think the indication in the metadata can be constructed by the SRC |> based on information it sends or receives in CS SDP, but this does not |> necessarily mean that it should be conveyed in RS SDP - it should be |> conveyed in XML. So I agree with Muthu. |> |> Note that starting to send a particular Media Stream can be a result of |> various changes in CS SDP, e.g: |> - addition of an m-line; |> - changing m-line port from zero to non-zero; |> - changing from inactive to sendrecv; |> - changing from recvonly to sendrecv; |> - changing from inactive to sendonly. |> |> Similarly starting to receive, ceasing to send and ceasing to receive |> can all arise from a number of different changes to CS SDP. |> |> The SRS should not need to understand all the details of CS SDP |> changes, but should just be given an abstraction, i.e., it should be |> told that a given participant is starting/stopping sending/receiving a |> media stream, in line with the metadata model. | |If we are ok to abstract the details and indicate starting/stopping sending/receiving a media stream, |the current model already does it. Do you see a need to have anything else in the model to accommodate |this ? | |Ram | |> |> John (as individual) |> |> > -----Original Message----- |> > From: Muthu ArulMozhi Perumal (mperumal) [mailto:mperumal@cisco.com] |> > Sent: 12 April 2011 10:20 |> > To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat); Elwell, John |> > Cc: siprec@ietf.org |> > Subject: RE: [siprec] start/stop times & the metamodel |> > |> > |SRC to SRS indication of participant hold/resume can |> > |happen through updates in RS SIP dialog. What I am |> > |asking here is if there is a need to report the original |> > |CS SDP media params (say direction attribute) explicitly |> > |in the metadata to RS. |> > |> > The SRC might have its own policy of when (and when not) to pause the |> > recording, which it can achieve through the RS dialog. The SRS on the |> > other hand might also have policies on when (and when not) to record |> > based on the participants media state. So, I see it might be useful |> to |> > convey this information in metadata if the SRS wants to take |> decisions |> > independent of the SRC. Also, since only metadata is |> > persistent, making |> > it available in metadata might be handy for the SRS, for future |> > interpretation. |> > |> > Muthu |> > |> > |-----Original Message----- |> > |From: Ram Mohan R (rmohanr) |> > |Sent: Tuesday, April 12, 2011 2:17 PM |> > |To: Muthu ArulMozhi Perumal (mperumal); Paul Kyzivat (pkyzivat); |> > 'Elwell, John' |> > |Cc: 'siprec@ietf.org' |> > |Subject: RE: [siprec] start/stop times & the metamodel |> > | |> > |Inline |> > | |> > |> -----Original Message----- |> > |> From: Muthu ArulMozhi Perumal (mperumal) |> > |> Sent: Tuesday, April 12, 2011 1:51 PM |> > |> To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat); Elwell, John |> > |> Cc: siprec@ietf.org |> > |> Subject: RE: [siprec] start/stop times & the metamodel |> > |> |> > |> |I agree on sending information of when a participant start/stop |> > |> |sending media [ from SRC perspective - what SRC sees] in the |> > |> |metadata. Do we really need reporting Changes to the media |> > |> |streams of CS like send, receive, inactive ? |> > |> |> > |> Aren't they related? If a participant goes recvonly or |> > inactive it is |> > |> an indication that he isn't going to send anything, so SRS |> > might want |> > |> to know this in order to pause recording the media stream |> > coming from |> > |> that participant and save some disk space -- might be useful in |> > |> environment where occasional small clips in the recorded |> > stream isn't |> > a |> > |> problem. An alternative is for the SRC to run media |> > activity/inactivity |> > |> detection and report it to the SRS (which can also suffer |> > from media |> > |> clipping). However, not every SRC might be capable of doing this. |> > | |> > |SRC to SRS indication of participant hold/resume can happen through |> > updates in RS SIP dialog. What I |> > |am asking here is if there is a need to report the original CS SDP |> > media params (say direction |> > |attribute) explicitly in the metadata to RS. |> > | |> > |Ram |> > | |> > |> |> > |> Muthu |> > |> |> > |> |-----Original Message----- |> > |> |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On |> > |> Behalf Of Ram Mohan R (rmohanr) |> > |> |Sent: Tuesday, April 12, 2011 1:17 PM |> > |> |To: Paul Kyzivat (pkyzivat); Elwell, John |> > |> |Cc: siprec@ietf.org |> > |> |Subject: Re: [siprec] start/stop times & the metamodel |> > |> | |> > |> |Inline |> > |> |A comment on this mail |> > |> | |> > |> | |> > |> |> -----Original Message----- |> > |> |> From: siprec-bounces@ietf.org |> > [mailto:siprec-bounces@ietf.org] On |> > |> |> Behalf Of Paul Kyzivat (pkyzivat) |> > |> |> Sent: Monday, April 11, 2011 6:33 PM |> > |> |> To: Elwell, John |> > |> |> Cc: siprec@ietf.org |> > |> |> Subject: Re: [siprec] start/stop times & the metamodel |> > |> |> |> > |> |> |> > |> |> |> > |> |> On 4/8/2011 11:53 AM, Elwell, John wrote: |> > |> |> > Paul, |> > |> |> > |> > |> |> > I think much of what you say makes sense. I was concerned |> that |> > we |> > |> |> probably need to record when a participant stops or |> > starts sending |> > |> or |> > |> |> receiving a stream, which seems to be covered by your |> statement: |> > |> |> "Changes to media streams should similarly be tagged |> > with the time |> > |> |they |> > |> |> occurred in the CS signaling. Each participant |> > relationship change |> > |> |> (send, receive, inactive,) will be there." That doesn't |> > seem to be |> > |> in |> > |> |> the model at present. |> > |> | |> > |> |I agree on sending information of when a participant start/stop |> > |> sending |> > |> |media [ from SRC perspective - what SRC sees] in the |> > metadata. Do we |> > |> |really need reporting Changes to the media streams of CS |> > like send, |> > |> |receive, inactive ? This would again go back to sending |> > portions of |> > CS |> > |> |SDP [ in this case direction attribute] in metadata. |> > |> | |> > |> |Ram |> > |> | |> > |> |> |> > |> |> John, |> > |> |> |> > |> |> I agree the current model doesn't reflect this - it was |> > a private |> > |> |> thought by me, provoked by the work and discussion to |> > date. It is |> > a |> > |> |bit |> > |> |> of a change of direction, so I'm interested in what others |> think |> > |> about |> > |> |> it. |> > |> |> |> > |> |> Thanks, |> > |> |> Paul |> > |> |> |> > |> |> > John (as individual) |> > |> |> > |> > |> |> > |> > |> |> >> -----Original Message----- |> > |> |> >> From: siprec-bounces@ietf.org |> > |> |> >> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat |> > |> |> >> Sent: 06 April 2011 22:28 |> > |> |> >> To: siprec@ietf.org |> > |> |> >> Subject: [siprec] start/stop times& the metamodel |> > |> |> >> |> > |> |> >> In Prague, one of the open issues was around |> > start/stop times. |> > |> The |> > |> |> >> format draft floated the possibility of having explicit |> > |> |> >> start/stop times |> > |> |> >> signaled for each of the metatdata elements. But |> > then we asked |> > |> for |> > |> |> >> feedback on which make sense. |> > |> |> >> |> > |> |> >> IMO explicit start/stop times make more sense for some |> things |> > |> |> >> than others. |> > |> |> >> |> > |> |> >> One place where we potentially have explicit times to report |> > with |> > |> |> the |> > |> |> >> dialogs that constitute a CS. Each such dialog |> > presumably has a |> > |> |> start |> > |> |> >> and stop time observable by the SRC, which might differ, at |> > |> |> >> least a bit, |> > |> |> >> from the corresponding signaling on the RS. |> > |> |> >> |> > |> |> >> We might want to report those times. Or, since we abstract |> > |> |> >> the CS away |> > |> |> >> from the dialog, we might want to report the start |> > time of the |> > |> |first |> > |> |> >> dialog in the CS as the CS start time, and the stop |> > time of the |> > |> |last |> > |> |> >> dialog in the CS as the CS stop time. |> > |> |> >> |> > |> |> >> Similarly, we have abstracted media streams away from the |> > |> |> >> media streams |> > |> |> >> in the sip dialogs that make up the CS. We might |> > want to report |> > |> the |> > |> |> >> start time of a media stream as the time (according |> > to the CS) |> > of |> > |> |> the |> > |> |> >> first participant to a new media stream, and the stop time |> as |> > |> |> >> the time |> > |> |> >> that the last participant leaves the media stream. |> > |> |> >> |> > |> |> >> There are several things that complicate this: |> > |> |> >> |> > |> |> >> - Do we consider the case of a stream that starts |> > with recvonly |> > |> |> >> or inactive participants, and only later gets a |> > sender? If |> > |> so, |> > |> |> >> is the start time of the stream when the first |> > participant |> > |> |> arrived, |> > |> |> >> or when the first sender arrived? |> > |> |> >> |> > |> |> >> - How do we get the clock times for the media streams? |> > |> |> >> IIUC the correct ones are in the RTP/RTCP, but the |> > reporting |> > |> of |> > |> |> >> these events is driven by the signaling, and we |> > don't have |> > |> good |> > |> |> >> sync between those. (E.g. media could start |> > flowing before |> > |> the |> > |> |> >> corresponding signaling, and we would like to |> > include that |> > if |> > |> |we |> > |> |> >> can figure it out.) So, even if the clocks used for |> media |> > and |> > |> |> >> signaling are in sync, we might see media packets arrive |> > with |> > |> |> >> a timestamp prior to the timestamp for the signaling |> that |> > |> |> >> indicates the send state of the participant. This could |> > cause |> > |> |> >> trouble in playback. |> > |> |> >> |> > |> |> >> - There isn't any guarantee that the clock used for |> signaling |> > |> |> >> messages is synchronized with the clock used in |> RTP/RTCP. |> > |> |> >> |> > |> |> >> - There isn't any guarantee that there will be any |> > RTCP at all, |> > |> |> >> to provide correlation of the RTP to clocktime. |> > |> |> >> |> > |> |> >> The best I can see to deal with all of this is: |> > |> |> >> |> > |> |> >> - All the metadata messages should be timestamped by the SRC |> > |> |> >> using its local clock. This is easily achieved |> > by the Date |> > |> |> >> header in the sip message. |> > |> |> >> |> > |> |> >> - Changes to a CS, including changes of participants, should |> > |> |> >> be explicitly tagged with the time they occurred in the |> > |> |> >> CS signaling, according to the SRC's clock. (If that is |> > |> |> >> unavailable for some reason, then use the time the SRC |> > |> |> >> became aware of it.) |> > |> |> >> |> > |> |> >> - We could provide a metadata update element to indicate end |> > |> |> >> of a CS, but I suggest this just be shorthand for |> > indicating |> > |> |> >> removal of all participants from it. (While its |> > possible to |> > |> |> >> mark that the CS is truly ended, that simply |> > introduces an |> > |> |> >> error case if added metadata about it is subsequently |> > sent.) |> > |> |> >> The actual start/stop time would be determined by the |> SRS |> > |> |> >> based on the timestamps of first and last data about it. |> > |> |> >> |> > |> |> >> - Changes to media streams should similarly be tagged with |> > |> |> >> the time they occurred in the CS signaling. Each |> > participant |> > |> |> >> relationship change (send, receive, inactive,) will be |> > there. |> > |> |> >> The actual start/stop time of the media stream |> > again would |> > be |> > |> |> >> derived by the SRS. |> > |> |> >> |> > |> |> >> - CS-Groups can simply be tagged by the timestamps of the |> > |> |> >> updates that put CSs into them. Explicit start/stop |> times |> > |> don't |> > |> |> >> seem useful. If desired, the SRS can derive start/stop |> > times |> > |> |> >> from the start/stop times of the contained stuff. |> > |> |> >> |> > |> |> >> - I now think that CS-Groups should not be "contained" |> within |> > |> |> >> a recording. This just seems to introduce |> > unnecessary error |> > |> |> >> conditions, and limitations on future enhancements. The |> > |> |> >> lifetime of CS-Groups will probably be naturally |> > limited by |> > |> |> >> the ability of the SRC to remember the IDs of old ones. |> > |> |> >> For instance, if a CS-G is created during one Recording, |> > |> |> >> and then another CS is added to it from a different |> > recording |> > |> |> >> session, would we prefer to fail that, or just allow it? |> > |> |> >> (I think allow.) |> > |> |> >> |> > |> |> >> - Rather, I think every update transmitted during a |> recording |> > |> |> >> session can be tagged with a link to the metadata of the |> > |> |> >> recording session it came from. This need not be |> > explicit - |> > |> the |> > |> |> >> SRS can do it automatically. The recording session |> entity |> > |> |> >> itself will also have a start/stop time which is |> > the start/ |> > |> |> >> stop of the RS dialog as observed by the SRS. |> > |> |> >> |> > |> |> >> (Note the above doesn't solve the problem of getting correct |> > |> |> >> clock times |> > |> |> >> for RTP media. If anyone has a suggestion for this I'm all |> > ears.) |> > |> |> >> |> > |> |> >> Thanks, |> > |> |> >> Paul From john.elwell@siemens-enterprise.com Wed Apr 13 00:46:06 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E1DC0E074D for ; Wed, 13 Apr 2011 00:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.736 X-Spam-Level: X-Spam-Status: No, score=-104.736 tagged_above=-999 required=5 tests=[AWL=1.863, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vmMq0dAENmKz for ; Wed, 13 Apr 2011 00:46:05 -0700 (PDT) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfc.amsl.com (Postfix) with SMTP id 1D1EFE0747 for ; Wed, 13 Apr 2011 00:46:05 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1302680761!25036377!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 15145 invoked from network); 13 Apr 2011 07:46:01 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-4.tower-27.messagelabs.com with SMTP; 13 Apr 2011 07:46:01 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 5CF4E23F03DB for ; Wed, 13 Apr 2011 09:46:03 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 13 Apr 2011 09:46:03 +0200 From: "Elwell, John" To: "siprec@ietf.org" Date: Wed, 13 Apr 2011 09:46:01 +0200 Thread-Topic: Last day for indicating your preferences for next SIPREC virtual interim meeting Thread-Index: Acv0XM0zNUOYNxbUQh+UouIMTh5WBwAADoowAVRD2fA= 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: [siprec] Last day for indicating your preferences for next SIPREC virtual 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: Wed, 13 Apr 2011 07:46:07 -0000 Would those who haven't filled in the poll for the virtual interim meeting = please do so today? At present it looks like the only feasible dates are 9t= h and 12th May. I would also like advice from the various document authors whether this wou= ld be too early (it is less than one month away). However, in my opinion th= ere is already substantial discussion on the list, so it should be possible= to have a useful meeting that week. John > -----Original Message----- > From: Elwell, John=20 > Sent: 06 April 2011 14:22 > To: siprec@ietf.org > Subject: FW: Doodle: Link for poll "SIPREC virtual interim" >=20 > In Prague it was suggested we hold a virtual interim meeting=20 > in May. Below is the link to the Doodle poll - please vote by=20 > 2011-04-13. The time range is deliberately restricted because=20 > we have participants from 3 continents. >=20 > John=20 >=20 > > -----Original Message----- > > From: Doodle [mailto:mailer@doodle.com]=20 > > Sent: 06 April 2011 14:16 > > To: Elwell, John > > Subject: Doodle: Link for poll "SIPREC virtual interim" > >=20 > > You have initiated a poll "SIPREC virtual interim" at Doodle.=20 > > The link to your poll is: > >=20 > > http://doodle.com/2s7w4dpgd5i9x6zc > >=20 > > Share this link with all those who should cast their votes.=20 > > Do not forget to cast your vote, too. > > (If you did not initiate this poll, somebody must=20 > > accidentally have used your e-mail address; simply ignore=20 > > this e-mail, please.) > >=20 > >=20 > > = From rmohanr@cisco.com Wed Apr 13 01:48:17 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2A3FDE06FE for ; Wed, 13 Apr 2011 01:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BTT5-Ohr74YJ for ; Wed, 13 Apr 2011 01:48:16 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfc.amsl.com (Postfix) with ESMTP id 18A91E0689 for ; Wed, 13 Apr 2011 01:48:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=2211; q=dns/txt; s=iport; t=1302684496; x=1303894096; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=mGwgvks1T/1ZKPUMNUH7Ge2mpBRADwZ6dKoatBqumNo=; b=O3J5nsfvbr8YjuZJyKMopaVmEZoi9lfzxd0oXdffTk13KZYFaWV4x97E YO3EE/9Uxh6ZsqQBrSOBlMKJNQ74rqzl6y+9G0pShM4Y8rfGG34c1lIWr MzGGy46KS2S13SumNnKIFXuklGDpnMjJr8wP68qwtx/+ZZOe8/HKDyf6v g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AusAALVipU2Q/khR/2dsb2JhbACYHo1pd6Y9jxgBjV6FbgSFXIwG X-IronPort-AV: E=Sophos;i="4.64,203,1301875200"; d="scan'208";a="83365067" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 13 Apr 2011 08:48:15 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3D8m9Xd029334; Wed, 13 Apr 2011 08:48:14 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); Wed, 13 Apr 2011 14:18:11 +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: Wed, 13 Apr 2011 14:18:09 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD060097DD@XMB-BGL-417.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Last day for indicating your preferences for next SIPREC virtual interim meeting Thread-Index: Acv0XM0zNUOYNxbUQh+UouIMTh5WBwAADoowAVRD2fAAAjzhAA== References: From: "Ram Mohan R (rmohanr)" To: "Elwell, John" , X-OriginalArrivalTime: 13 Apr 2011 08:48:11.0496 (UTC) FILETIME=[84F1C680:01CBF9B7] Subject: Re: [siprec] Last day for indicating your preferences for next SIPREC virtual 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: Wed, 13 Apr 2011 08:48:17 -0000 I see a definite value in having this meeting that week. We have already seen several discussions on metamodel/format and I think it's useful to have a virtual interim meeting. Ram > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Elwell, John > Sent: Wednesday, April 13, 2011 1:16 PM > To: siprec@ietf.org > Subject: [siprec] Last day for indicating your preferences for next > SIPREC virtual interim meeting >=20 > Would those who haven't filled in the poll for the virtual interim > meeting please do so today? At present it looks like the only feasible > dates are 9th and 12th May. >=20 > I would also like advice from the various document authors whether this > would be too early (it is less than one month away). However, in my > opinion there is already substantial discussion on the list, so it > should be possible to have a useful meeting that week. >=20 > John >=20 >=20 > > -----Original Message----- > > From: Elwell, John > > Sent: 06 April 2011 14:22 > > To: siprec@ietf.org > > Subject: FW: Doodle: Link for poll "SIPREC virtual interim" > > > > In Prague it was suggested we hold a virtual interim meeting > > in May. Below is the link to the Doodle poll - please vote by > > 2011-04-13. The time range is deliberately restricted because > > we have participants from 3 continents. > > > > John > > > > > -----Original Message----- > > > From: Doodle [mailto:mailer@doodle.com] > > > Sent: 06 April 2011 14:16 > > > To: Elwell, John > > > Subject: Doodle: Link for poll "SIPREC virtual interim" > > > > > > You have initiated a poll "SIPREC virtual interim" at Doodle. > > > The link to your poll is: > > > > > > http://doodle.com/2s7w4dpgd5i9x6zc > > > > > > Share this link with all those who should cast their votes. > > > Do not forget to cast your vote, too. > > > (If you did not initiate this poll, somebody must > > > accidentally have used your e-mail address; simply ignore > > > this e-mail, please.) > > > > > > > > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From partr@cisco.com Wed Apr 13 02:16:23 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 90DD5E06E7 for ; Wed, 13 Apr 2011 02:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.995 X-Spam-Level: X-Spam-Status: No, score=-9.995 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0grNpQp90XwM for ; Wed, 13 Apr 2011 02:16:21 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfc.amsl.com (Postfix) with ESMTP id 0701FE0689 for ; Wed, 13 Apr 2011 02:16:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=15231; q=dns/txt; s=iport; t=1302686181; x=1303895781; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=C2ALo86+Dr49rU3GCSAzKjuG5NNeiDP8IwQDOy4y+C0=; b=E2jGflsf25BSm0URd/WOwlwauqX/tfmezzHiaVk6c6aa6XkK+tPgHEFo XC1WixuJAagtbN6x1/NY1EPT47ePp57bHDXdPZ4EdlTlosRl2JUNxWISV N4H2ulcYHV1O068CjqORGe5TrJp7wK8mV1EdjnCVyYkCdaYfCxaa7ux6y E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuQAALVppU2Q/khLgWdsb2JhbACYII1pFAEBFiYlpkOcf4J+gnAEhVyMBg X-IronPort-AV: E=Sophos;i="4.64,203,1301875200"; d="scan'208";a="83370352" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 13 Apr 2011 09:16:20 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3D9GH2K018678; Wed, 13 Apr 2011 09:16:19 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Apr 2011 14:46:05 +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: Wed, 13 Apr 2011 14:46:05 +0530 Message-ID: In-Reply-To: <1D062974A4845E4D8A343C65380492020533B880@XMB-BGL-414.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] start/stop times & the metamodel Thread-Index: Acv4ar9mNRoQAPkwSImkiZlfghuuTgAIWrigAApMiDAAJ/uhEAASQRUgAAJ0TuAABJfvgA== References: <4D9CDADD.1020403@cisco.com> <4DA2FC17.1060100@cisco.com><07465C1D981ABC41A344374066AE1A2C38AB6E1DE4@TLVMBX01.nice.com><4DA334F0.9050301@cisco.com><059AF07365DC474393A19A3AF187DF7406E67CB4@NAHALD.us.int.genesyslab.com><1D062974A4845E4D8A343C65380492020533B45B@XMB-BGL-414.cisco.com> <059AF07365DC474393A19A3AF187DF7406EF2378@NAHALD.us.int.genesyslab.com> <1D062974A4845E4D8A343C65380492020533B880@XMB-BGL-414.cisco.com> From: "Parthasarathi R (partr)" To: "Muthu ArulMozhi Perumal (mperumal)" , "Henry Lum" , "Paul Kyzivat (pkyzivat)" , "Leon Portman" X-OriginalArrivalTime: 13 Apr 2011 09:16:05.0835 (UTC) FILETIME=[6AEDA1B0:01CBF9BB] Cc: siprec@ietf.org Subject: Re: [siprec] start/stop times & the metamodel X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 13 Apr 2011 09:16:23 -0000 ISTM, SRC has to act only as RTP Endpoint or RTP Mixer (not RTP translator) in case these requirement has to be considered within SIPREC. IMO, these requirement has to be mentioned in SIPREC requirement document to define the exact role what SRC does with media timestamp and what SRS does with media timestamp? Thanks Partha=20 -----Original Message----- From: Muthu ArulMozhi Perumal (mperumal)=20 Sent: Wednesday, April 13, 2011 12:36 PM To: Parthasarathi R (partr); 'Henry Lum'; Paul Kyzivat (pkyzivat); 'Leon Portman' Cc: 'siprec@ietf.org' Subject: RE: [siprec] start/stop times & the metamodel After the use-case Paul described, it seem to me that if we keep out of scope it will put a lot of burden on the SRS to support synchronized querying/playback which looks an important aspect for media recording. So, we may want to consider the ways in which the SRC can facilitate it. Muthu |-----Original Message----- |From: Parthasarathi R (partr) |Sent: Wednesday, April 13, 2011 11:20 AM |To: Henry Lum; Muthu ArulMozhi Perumal (mperumal); Paul Kyzivat=20 |(pkyzivat); Leon Portman |Cc: siprec@ietf.org |Subject: RE: [siprec] start/stop times & the metamodel | |Henry, | |I attached the follow up mail to below mail thread. Till now, We don't=20 |have strong requirement to solve in SIPREC. Let us identify the requirement before going to the solution. | |Thanks |Partha | |-----Original Message----- |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 |Behalf Of Henry Lum |Sent: Wednesday, April 13, 2011 2:43 AM |To: Muthu ArulMozhi Perumal (mperumal); Paul Kyzivat (pkyzivat); Leon=20 |Portman |Cc: siprec@ietf.org |Subject: Re: [siprec] start/stop times & the metamodel | |I don't think it is guaranteed that participants will send SR reports=20 |(or any RTCP), plus we will also have to assume that the NTP timestamps |are in sync. We could mandate the SRC to generate SR reports but then we are fixing the RTP model for the SRC. | |Regards, |Henry | |> -----Original Message----- |> From: Muthu ArulMozhi Perumal (mperumal) [mailto:mperumal@cisco.com] |> Sent: Monday, April 11, 2011 10:45 PM |> To: Henry Lum; Paul Kyzivat (pkyzivat); Leon Portman |> Cc: siprec@ietf.org |> Subject: RE: [siprec] start/stop times & the metamodel |> |> While I see it may be useful for the SRS to know when certain things=20 |> happened in CS signaling (participant joining, leaving, going mute |etc) |> I don't see how useful it would be for it know how those things are=20 |> related to when the participant actually sent/received (or stopped |> sending/receiving) RTP. |> |> If we see any use, one way to do it is using the NTP timestamp=20 |> carried in RTCP SR reports, provided the SRC, SRS and the=20 |> participants have access to the same reference wallclock. |> |> Muthu |> |> |-----Original Message----- |> |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On |> Behalf Of Henry Lum |> |Sent: Tuesday, April 12, 2011 2:56 AM |> |To: Paul Kyzivat (pkyzivat); Leon Portman |> |Cc: siprec@ietf.org |> |Subject: Re: [siprec] start/stop times & the metamodel |> | |> |A related question on the RTP model is that if the SRC as an RTP=20 |> |translator chooses to relay the RTP timestamps, then how would the |SRC |> |synchronize the timestamps between the SIP messages the multiple RTP |> |streams? |> | |> |Henry |> | |> |> -----Original Message----- |> |> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 |> |> Behalf Of Paul Kyzivat |> |> Sent: Monday, April 11, 2011 1:06 PM |> |> To: Leon Portman |> |> Cc: siprec@ietf.org |> |> Subject: Re: [siprec] start/stop times & the metamodel |> |> |> |> |> |> |> |> On 4/11/2011 9:36 AM, Leon Portman wrote: |> |> > Paul Hi |> |> > |> |> > I agree with proposed method of time stamping metadata elements |> with |> |> SRC clock (it is like a wall clock from the requirement document). |> |> > About RTP time synchronization to metadata events, we either |> should |> |> have some low latency event from SRC to SRS with SRC time that=20 |> |> will allow SRS to maintain time difference between its clock and=20 |> |> SRC |> clock |> |> and then apply it also to receive time of RTP packet (assuming no |> |> buffering) |> |> |> |> ISTM the issue isn't the latency of the event - it is what it is - |> but |> |> rather how to correlate a sip message containing metadata with a=20 |> |> particular RTP packet. I suspect that needs to be tied into the=20 |> |> discussion of the various models for how the SRC might handle RDP. |> |> |> |> Thanks, |> |> Paul |> |> |> |> > Leon |> |> > |> |> > -----Original Message----- |> |> > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org]=20 |> |> > On |> |> Behalf Of Paul Kyzivat |> |> > Sent: Monday, April 11, 2011 4:03 PM |> |> > To: Elwell, John |> |> > Cc: siprec@ietf.org |> |> > Subject: Re: [siprec] start/stop times& the metamodel |> |> > |> |> > |> |> > |> |> > On 4/8/2011 11:53 AM, Elwell, John wrote: |> |> >> Paul, |> |> >> |> |> >> I think much of what you say makes sense. I was concerned that |we |> |> probably need to record when a participant stops or starts sending |> or |> |> receiving a stream, which seems to be covered by your statement: |> |> "Changes to media streams should similarly be tagged with the time |> |they |> |> occurred in the CS signaling. Each participant relationship change |> |> (send, receive, inactive,) will be there." That doesn't seem to be |> in |> |> the model at present. |> |> > |> |> > John, |> |> > |> |> > I agree the current model doesn't reflect this - it was a=20 |> |> > private |> |> thought by me, provoked by the work and discussion to date. It is=20 |> |> a |> |bit |> |> of a change of direction, so I'm interested in what others think |> about |> |> it. |> |> > |> |> > Thanks, |> |> > Paul |> |> > |> |> >> John (as individual) |> |> >> |> |> >> |> |> >>> -----Original Message----- |> |> >>> From: siprec-bounces@ietf.org |> |> >>> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat |> |> >>> Sent: 06 April 2011 22:28 |> |> >>> To: siprec@ietf.org |> |> >>> Subject: [siprec] start/stop times& the metamodel |> |> >>> |> |> >>> In Prague, one of the open issues was around start/stop times. |> The |> |> >>> format draft floated the possibility of having explicit |> start/stop |> |> >>> times signaled for each of the metatdata elements. But then we |> |> asked |> |> >>> for feedback on which make sense. |> |> >>> |> |> >>> IMO explicit start/stop times make more sense for some things |> than |> |> >>> others. |> |> >>> |> |> >>> One place where we potentially have explicit times to report |> with |> |> the |> |> >>> dialogs that constitute a CS. Each such dialog presumably has=20 |> |> >>> a |> |> start |> |> >>> and stop time observable by the SRC, which might differ, at |> least |> |a |> |> >>> bit, from the corresponding signaling on the RS. |> |> >>> |> |> >>> We might want to report those times. Or, since we abstract the |> CS |> |> >>> away from the dialog, we might want to report the start time=20 |> |> >>> of |> |the |> |> >>> first dialog in the CS as the CS start time, and the stop time |> of |> |> the |> |> >>> last dialog in the CS as the CS stop time. |> |> >>> |> |> >>> Similarly, we have abstracted media streams away from the=20 |> |> >>> media streams in the sip dialogs that make up the CS. We might |> |> >>> want |to |> |> >>> report the start time of a media stream as the time (according |> to |> |> the |> |> >>> CS) of the first participant to a new media stream, and the |stop |> |> time |> |> >>> as the time that the last participant leaves the media stream. |> |> >>> |> |> >>> There are several things that complicate this: |> |> >>> |> |> >>> - Do we consider the case of a stream that starts with recvonly |> |> >>> or inactive participants, and only later gets a sender?=20 |> |> >>> If |> |so, |> |> >>> is the start time of the stream when the first=20 |> |> >>> participant |> |> arrived, |> |> >>> or when the first sender arrived? |> |> >>> |> |> >>> - How do we get the clock times for the media streams? |> |> >>> IIUC the correct ones are in the RTP/RTCP, but the |> reporting |> |> of |> |> >>> these events is driven by the signaling, and we don't=20 |> |> >>> have |> |> good |> |> >>> sync between those. (E.g. media could start flowing=20 |> |> >>> before |> |the |> |> >>> corresponding signaling, and we would like to include=20 |> |> >>> that |> if |> |> we |> |> >>> can figure it out.) So, even if the clocks used for media |> and |> |> >>> signaling are in sync, we might see media packets arrive |> with |> |> >>> a timestamp prior to the timestamp for the signaling that |> |> >>> indicates the send state of the participant. This could |> cause |> |> >>> trouble in playback. |> |> >>> |> |> >>> - There isn't any guarantee that the clock used for signaling |> |> >>> messages is synchronized with the clock used in RTP/RTCP. |> |> >>> |> |> >>> - There isn't any guarantee that there will be any RTCP at all, |> |> >>> to provide correlation of the RTP to clocktime. |> |> >>> |> |> >>> The best I can see to deal with all of this is: |> |> >>> |> |> >>> - All the metadata messages should be timestamped by the SRC |> |> >>> using its local clock. This is easily achieved by the Date |> |> >>> header in the sip message. |> |> >>> |> |> >>> - Changes to a CS, including changes of participants, should |> |> >>> be explicitly tagged with the time they occurred in the |> |> >>> CS signaling, according to the SRC's clock. (If that is |> |> >>> unavailable for some reason, then use the time the SRC |> |> >>> became aware of it.) |> |> >>> |> |> >>> - We could provide a metadata update element to indicate end |> |> >>> of a CS, but I suggest this just be shorthand for |> indicating |> |> >>> removal of all participants from it. (While its possible |to |> |> >>> mark that the CS is truly ended, that simply introduces an |> |> >>> error case if added metadata about it is subsequently |> sent.) |> |> >>> The actual start/stop time would be determined by the SRS |> |> >>> based on the timestamps of first and last data about it. |> |> >>> |> |> >>> - Changes to media streams should similarly be tagged with |> |> >>> the time they occurred in the CS signaling. Each |> participant |> |> >>> relationship change (send, receive, inactive,) will be |> there. |> |> >>> The actual start/stop time of the media stream again=20 |> |> >>> would |> be |> |> >>> derived by the SRS. |> |> >>> |> |> >>> - CS-Groups can simply be tagged by the timestamps of the |> |> >>> updates that put CSs into them. Explicit start/stop times |> |> don't |> |> >>> seem useful. If desired, the SRS can derive start/stop |> times |> |> >>> from the start/stop times of the contained stuff. |> |> >>> |> |> >>> - I now think that CS-Groups should not be "contained" within |> |> >>> a recording. This just seems to introduce unnecessary |error |> |> >>> conditions, and limitations on future enhancements. The |> |> >>> lifetime of CS-Groups will probably be naturally limited |by |> |> >>> the ability of the SRC to remember the IDs of old ones. |> |> >>> For instance, if a CS-G is created during one Recording, |> |> >>> and then another CS is added to it from a different |> recording |> |> >>> session, would we prefer to fail that, or just allow it? |> |> >>> (I think allow.) |> |> >>> |> |> >>> - Rather, I think every update transmitted during a recording |> |> >>> session can be tagged with a link to the metadata of the |> |> >>> recording session it came from. This need not be explicit |- |> |> the |> |> >>> SRS can do it automatically. The recording session entity |> |> >>> itself will also have a start/stop time which is the |start/ |> |> >>> stop of the RS dialog as observed by the SRS. |> |> >>> |> |> >>> (Note the above doesn't solve the problem of getting correct |> clock |> |> >>> times for RTP media. If anyone has a suggestion for this I'm |all |> |> >>> ears.) |> |> >>> |> |> >>> Thanks, |> |> >>> Paul |> |> >>> _______________________________________________ |> |> >>> siprec mailing 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 |> | |> | |> ||---------------------------------------------------------------------- |> - |> ------------------------------- |> |------------- |> |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. |> | |> |_______________________________________________ |> |siprec mailing list |> |siprec@ietf.org |> |https://www.ietf.org/mailman/listinfo/siprec | | |----------------------------------------------------------------------- |------------------------------- |------------- |CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain=20 |confidential and proprietary information of Alcatel-Lucent and/or its=20 |affiliated entities. Access by the intended recipient only is=20 |authorized. Any liability arising from any party acting, or refraining=20 |from acting, on any information contained in this e-mail is hereby=20 |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. | |_______________________________________________ |siprec mailing list |siprec@ietf.org |https://www.ietf.org/mailman/listinfo/siprec From andrew.hutton@siemens-enterprise.com Wed Apr 13 03:04:20 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B478CE0752 for ; Wed, 13 Apr 2011 03:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-1.542, BAYES_00=-2.599, CN_BODY_35=0.339, MANGLED_VIDEO=2.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VS1qppY-nLT3 for ; Wed, 13 Apr 2011 03:04:20 -0700 (PDT) Received: from mail182.messagelabs.com (mail182.messagelabs.com [85.158.139.83]) by ietfc.amsl.com (Postfix) with SMTP id 801F9E0663 for ; Wed, 13 Apr 2011 03:04:19 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: andrew.hutton@siemens-enterprise.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1302689058!4972147!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 30390 invoked from network); 13 Apr 2011 10:04:18 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-9.tower-182.messagelabs.com with SMTP; 13 Apr 2011 10:04:18 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id EEAFE23F03DB; Wed, 13 Apr 2011 12:04:17 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 13 Apr 2011 12:04:17 +0200 From: "Hutton, Andrew" To: Roy , "Elwell, John" , "siprec@ietf.org" Date: Wed, 13 Apr 2011 12:04:17 +0200 Thread-Topic: [siprec] Question on the scope Thread-Index: Acv42ubXHfPE7b2ZSIutkk8YPChNPgABXVYQAAUKXIAAIklWQAARANqg Message-ID: <101C6067BEC68246B0C3F6843BCCC1E30B6D639EEE@MCHP058A.global-ad.net> References: <007b01cbf8da$e72ff570$b58fe050$@com> <101C6067BEC68246B0C3F6843BCCC1E30B6D5C888D@MCHP058A.global-ad.net> <00d201cbf97f$d2e22570$78a67050$@com> In-Reply-To: <00d201cbf97f$d2e22570$78a67050$@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="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [siprec] Question on the scope X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 13 Apr 2011 10:04:20 -0000 SGkgUm95LA0KDQpTbyB3aGF0IHByb3RvY29sIGlzIHVzZWQgdG8gdGVsbCB0aGUgQjJCVUEgd2hh dCBpcyB0byBiZSByZWNvcmRlZCBpcyB0aGlzIHNvbWV0aGluZyB0aGF0IGlzIGNvbnZleWVkIGlu IGEgU0lQIGJvZHkgb3Igc29tZXRoaW5nIGVsc2UgYW5kIGlzIGl0IHN0YW5kYXJkaXplZCA/DQoN Ckl0IHNvdW5kcyBsaWtlIHRoaXMgaXMgbm90IHdpdGhpbiBzY29wZSBvZiB0aGUgSUVURiBTSVBS RUMgZ3JvdXAgYnV0IEkgd291bGQgbGlrZSB0byB1bmRlcnN0YW5kIHRoZSBtZWNoYW5pc20gdXNl ZC4NCg0KUmVnYXJkcw0KQW5keQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZy b206IFJveSBbbWFpbHRvOnl1ZXBlaXl1QGh1YXdlaS5jb21dIA0KPiBTZW50OiAxMyBBcHJpbCAy MDExIDAzOjA5DQo+IFRvOiBIdXR0b24sIEFuZHJldzsgRWx3ZWxsLCBKb2huOyBzaXByZWNAaWV0 Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtzaXByZWNdIFF1ZXN0aW9uIG9uIHRoZSBzY29wZQ0KPiAN Cj4gSGkgQW5keSwNCj4gDQo+IFRoZSBzZXNzaW9uIGJldHdlZW4gVUEtQSBhbmQgdGhlIE1lZGlh IFNlcnZlciBkb2VzIG5vdCBjb252ZXkgDQo+IGFueSBtZWRpYS4NCj4gVGhpcyBTSVAgc2Vzc2lv biBtYWlubHkgdGVsbHMgdGhlIEIyQlVBIHdoYXQgdG8gYmUgcmVjb3JkZWQuDQo+IA0KPiBBcyBi YWNrZ3JvdW5kLCB0byB3YXRjaCBhIElQVFYgcHJvZ3JhbSwgdGhlIFVBLUEgaW5pdGlhdGVzIGEg DQo+IFNJUCBzZXNzaW9uIHRvDQo+IHNldHVwIGEgbWVkaWEgc2Vzc2lvbiBiZXR3ZWVuIFVBLUEg YW5kIE1lZGlhIFNlcnZlci4gVGhlIA0KPiBtZWRpYSBzZXNzaW9uIGNvdWxkDQo+IGJlIGEgdW5p Y2FzdCBvciBtdWx0aWNhc3Qgc2Vzc2lvbi4NCj4gV2hpbGUgaW4gdGhlIE5QVlIgY2FzZSwgdGhl IHVzZXIgKHdpdGggVUEtQSkgbWF5IG5vdCBiZSBhYmxlIA0KPiB0byB3YXRjaCB0aGUNCj4gbGl2 ZSBwcm9ncmFtLCBhbmQgd2FudCB0byByZWNvcmQgYW5kIHdhdGNoIHRoZSBwcm9ncmFtIGF0IGEg DQo+IGxhdGVyIHRpbWUuIA0KPiBUaGVyZWZvcmUsIHdoZW4gaW5pdGlhdGVzIHRoZSByZWNvcmRp bmcgc2Vzc2lvbiwgdGhlIFVBLUEgDQo+IHdpbGwgb25seSB0ZWxscw0KPiB3aGF0IHRvIHJlY29y ZCwgd2l0aG91dCBhbnkgbWVkaWEgY29udmV5aW5nLiANCj4gDQo+IEhvcGUgdGhpcyBjbGFyaWZp ZXMhDQo+IA0KPiBCZXN0IHJlZ2FyZHMsDQo+IFJveQ0KPiANCj4gLS0tLS3Tyrz+1K28/i0tLS0t DQo+ILeivP7IyzogSHV0dG9uLCBBbmRyZXcgW21haWx0bzphbmRyZXcuaHV0dG9uQHNpZW1lbnMt ZW50ZXJwcmlzZS5jb21dIA0KPiC3osvNyrG85DogMjAxMcTqNNTCMTLI1SAxNzozNw0KPiDK1bz+ yMs6IEVsd2VsbCwgSm9objsgUm95OyBzaXByZWNAaWV0Zi5vcmcNCj4g1vfM4jogUkU6IFtzaXBy ZWNdIFF1ZXN0aW9uIG9uIHRoZSBzY29wZQ0KPiANCj4gSGkgUm95LA0KPiANCj4gWW91ciBkaWFn cmFtIHNob3dzIGEgU0lQIHNlc3Npb24gZnJvbSBVQS1BIHRvIHRoZSBCMkJVQSBhbmQgDQo+IGJl dHdlZW4gdGhlDQo+IEIyQlVBIGFuZCB0aGUgTWVkaWEgU2VydmVyLiBJIGFzc3VtZSB0aGlzIGlz IGxvZ2ljYWxseSBhIA0KPiBzZXNzaW9uIGJldHdlZW4gdGhlDQo+IFVBLUEgYW5kIHRoZSBNZWRp YSBTZXJ2ZXIgd2l0aCB0aGUgQjJCVUEgaW4gdGhlIG1pZGRsZS4gDQo+IA0KPiBEb2VzIHRoaXMg c2Vzc2lvbiBjb252ZXkgYW55IG1lZGlhIGJldHdlZW4gVUEtQSBhbmQgdGhlIE1lZGlhIA0KPiBT ZXJ2ZXIgYW5kIGlmDQo+IHNvIHdoYXQgaXMgdGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoaXMg YW5kIHRoZSBtZWRpYSBzZW50IA0KPiB0byB0aGUgcmVjb3JkaW5nDQo+IHNlcnZlcj8NCj4gDQo+ IFdoYXQgaXMgdGhlIFNJUCBTZXNzaW9uIHVzZWQgZm9yIGF0IFVBLUE/DQo+IA0KPiBSZWdhcmRz DQo+IEFuZHkNCj4gDQo+IA0KPiANCj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gPiBGcm9tOiBzaXByZWMtYm91bmNlc0BpZXRmLm9yZyANCj4gPiBbbWFpbHRvOnNpcHJlYy1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRWx3ZWxsLCBKb2huDQo+ID4gU2VudDogMTIg QXByaWwgMjAxMSAwODoxNA0KPiA+IFRvOiBSb3k7IHNpcHJlY0BpZXRmLm9yZw0KPiA+IFN1Ympl Y3Q6IFJlOiBbc2lwcmVjXSBRdWVzdGlvbiBvbiB0aGUgc2NvcGUNCj4gPiANCj4gPiBSb3ksDQo+ ID4gDQo+ID4gSSBhbSBub3Qgc3VyZSBJIHVuZGVyc3RhbmQgeW91ciB1c2UgY2FzZSBjb3JyZWN0 bHksIGJ1dCBpdCANCj4gPiBzZWVtcyBzb21lIGNvbnRlbnQgZnJvbSBpbnNpZGUgYSBtZWRpYSBz ZXJ2ZXIgaXMgYmVpbmcgDQo+ID4gcmVjb3JkZWQsIGFzIG9wcG9zZWQgdG8gcmVjb3JkaW5nIGNv bnRlbnQgdGhhdCBpcyB0cmFuc3BvcnRlZCANCj4gPiBiZXR3ZWVuIHR3byBvciBtb3JlIHVzZXJz IGFzIHBhcnQgb2YgYSBjb21tdW5pY2F0aW9uIHNlc3Npb24uIA0KPiA+IEkgYmVsaWV2ZSB0aGF0 IGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoZSB3b3JraW5nIGdyb3VwLiBTZWUgDQo+ID4gdGhl IGNoYXJ0ZXIgYW5kIGRyYWZ0LWlldGYtc2lwcmVjLXJlcSAocmVxdWlyZW1lbnRzKS4gT3VyIA0K PiA+IHdvcmsgaXMgY29uY2VybmVkIHdpdGggcmVjb3JkaW5nIGEgc2Vzc2lvbiwgc28gY29udGVu dCB0aGF0IA0KPiA+IGlzIGhlbGQgaW50ZXJuYWxseSB0byBhIG1lZGlhIHNlcnZlciwgYXMgb3Bw b3NlZCB0byBiZWluZyANCj4gPiB0cmFuc3BvcnRlZCBhcyBwYXJ0IG9mIGEgc2Vzc2lvbiBpcyBv dXQgb2Ygc2NvcGUuDQo+ID4gDQo+ID4gSm9obg0KPiA+IA0KPiA+ID4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206IHNpcHJlYy1ib3VuY2VzQGlldGYub3JnIA0KPiA+ID4g W21haWx0bzpzaXByZWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJveQ0KPiA+ID4g U2VudDogMTIgQXByaWwgMjAxMSAwNzoyOQ0KPiA+ID4gVG86IHNpcHJlY0BpZXRmLm9yZw0KPiA+ ID4gU3ViamVjdDogW3NpcHJlY10gUXVlc3Rpb24gb24gdGhlIHNjb3BlDQo+ID4gPiANCj4gPiA+ IEhlbGxvDQo+ID4gPiANCj4gPiA+ICANCj4gPiA+IA0KPiA+ID4gSSBmaW5kIHRoaXMgd29yayBn cm91cCBkdXJpbmcgUHJhZ3VlIG1lZXRpbmcuIFRoZSB3b3JrIGhlcmUgDQo+ID4gPiBpcyBxdWl0 ZSBpbnRlcmVzdGluZyBhbHRob3VnaCBJIGhhdmUgc29tZSBxdWVzdGlvbnMgYXMgYmVsb3c6DQo+ ID4gPiANCj4gPiA+ICANCj4gPiA+IA0KPiA+ID4gQWxsIHRocm91Z2ggdGhlIGFyY2hpdGVjdHVy ZSBhbmQgcmVxdWlyZW1lbnQgZG9jdW1lbnQsIHdlIGFyZSANCj4gPiA+IHRhbGtpbmcgYWJvdXQg cmVjb3JkaW5nIGEgbWVkaWEgc2Vzc2lvbiBiZXR3ZWVuIHR3byBVQS4gDQo+ID4gPiANCj4gPiA+ IEhvd2V2ZXIsIHRoZXJlIGlzIGFsc28gdXNlIGNhc2VzIHRoYXQgYSBVQTEgcmVxdWVzdHMgYSAN Cj4gPiA+IHJlY29yZGluZyBzZXJ2ZXIgKFNSUykgdG8gcmVjb3JkIGEgbWVkaWEgY29udGVudCBp biBtZWRpYSANCj4gPiA+IHNlcnZlciAoVUEyKSB3aGlsZSB0aGVyZSBpcyBub3QgYW55IGRpcmVj dCBtZWRpYSBzZXNzaW9uIA0KPiA+ID4gYmV0d2VlbiBVQTEgYW5kIG1lZGlhIHNlcnZlci4gRm9s bG93aW5nIGlzIGEgZ2VuZXJhbCBhcmNoaXRlY3R1cmUuDQo+ID4gPiANCj4gPiA+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tKw0K PiA+ID4gDQo+ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgIChSZWNvcmRpbmcgU2Vzc2lv bikgICAgIHwgICAgICAgICAgIHwNCj4gPiA+IA0KPiA+ID4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICA7ICstLS0tLSBkaW5nIHwNCj4gPiA+IA0KPiA+ID4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICB8ICBTZXJ2ZXIgICB8DQo+ID4gPiANCj4g PiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICstLS1NZXRhRGF0YS0tLS0+fCAg ICAgICAgICAgfA0KPiA+ID4gDQo+ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAmbiB8 ICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLSsNCj4gPiA+IA0KPiA+ID4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB8ICAgfCAgICAgICAgICAgICAgICAgICAgIF4NCj4gPiA+IA0KPiA+ ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgfCAgICAgICAgICAgICAgICAgICAg IHwNCj4gPiA+IA0KPiA+ID4gICAgICAmbiBzcDsgICAgICAgICAgICAgICAgICAgIHwgICB8ICAg ICAgICAgICAgICAgICAgICBSVFANCj4gPiA+IA0KPiA+ID4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBWICAgViAgICAgICAgICAgIHVuaWNhc3Qgb3IgbXVsdGljYXN0DQo+ID4gPiANCj4g PiA+ICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0rICAgICAgICAg ICB8DQo+ID4gPiANCj4gPiA+IG5ic3A7ICAgICAgICAgICAgICAgICAgIHwgICAgICBCMkJVQSAg ICAgICB8ICAgICAgICAgICB8DQo+ID4gPiANCj4gPiA+ICAgICAgKy0tLS0tLS0tKyAgICAgICAg IHwgU2VydmljZSBDb250cm9sICB8ICAgICAgICAgKy0tLS0tLS0tLSsNCj4gPiA+IA0KPiA+ID4g ICAgICB8ICAgICAgICB8PC0gU0lQIC0+fCAgIEZ1bmN0aW9uICAgICAgIHw8LSBTSVAgLT58ICAg ICAgICAgfA0KPiA+ID4gDQo+ID4gPiAgICAgIHwgIFVBLUEgIHwgICAgICAgICArLS0tLS0tLS0t IC0tLS0tLS0tIDsgICAgIHwgIE1lZGlhICB8DQo+ID4gPiANCj4gPiA+ICAgICAgfCAgICAgICAg fCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgU2VydmVyIHwNCj4gPiA+ IA0KPiA+ID4gICAgICArLS0tLS0tLS0rICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICArLS0tLS0tLS0tKw0KPiA+ID4gDQo+ID4gPiAgDQo+ID4gPiANCj4gPiA+IFRoaXMgY2Fz ZSBpcyB2ZXJ5IGNvbW1vbiBpbiBJUFRWIGluZHVzdHJ5LCBrbm93biBhcyBOZXR3b3JrIA0KPiA+ ID4gUGVyc29uYWwgVmlkZSBvIFJlY29yZCBlcnkgc2ltaWxhciB3aXRoIHRoZSB3b3JrIGhlcmUu DQo+ID4gPiANCj4gPiA+IERvZXMgY3VycmVudCBkb2N1bWVudCBjb3ZlciB0aGlzIHVzZSBjYXNl IGFscmVhZHkgb3IgZGlkIHlvdSANCj4gPiA+IGRpc2N1c3NlZCBzaW1pbGFyIGNhc2UgZXZlcj8N Cj4gPiA+IA0KPiA+ID4gIA0KPiA+ID4gDQo+ID4gPiBNYW55IHRoYW5rcyBhbmQgYmVzdCByZWdh cmRzLA0KPiA+ID4gDQo+ID4gPiBSb3kNCj4gPiA+IA0KPiA+ID4gDQo+ID4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBzaXByZWMgbWFpbGluZyBs aXN0DQo+ID4gc2lwcmVjQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zaXByZWMNCj4gPiANCj4gDQo+IA0KPiA= From andrew.hutton@siemens-enterprise.com Wed Apr 13 03:07:13 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CFBF6E06EF for ; Wed, 13 Apr 2011 03:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.528 X-Spam-Level: X-Spam-Status: No, score=-4.528 tagged_above=-999 required=5 tests=[AWL=2.071, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AeQV51YV64h2 for ; Wed, 13 Apr 2011 03:07:13 -0700 (PDT) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfc.amsl.com (Postfix) with SMTP id 26495E0707 for ; Wed, 13 Apr 2011 03:07:06 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: andrew.hutton@siemens-enterprise.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1302689222!20742473!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 28677 invoked from network); 13 Apr 2011 10:07:03 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-14.tower-27.messagelabs.com with SMTP; 13 Apr 2011 10:07:03 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 17CFC23F03E2; Wed, 13 Apr 2011 12:07:05 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 13 Apr 2011 12:07:05 +0200 From: "Hutton, Andrew" To: "Ram Mohan R (rmohanr)" , "Elwell, John" , "siprec@ietf.org" Date: Wed, 13 Apr 2011 12:07:03 +0200 Thread-Topic: [siprec] Last day for indicating your preferences for next SIPREC virtual interim meeting Thread-Index: Acv0XM0zNUOYNxbUQh+UouIMTh5WBwAADoowAVRD2fAAAjzhAAAC20zw Message-ID: <101C6067BEC68246B0C3F6843BCCC1E30B6D639EF2@MCHP058A.global-ad.net> References: <35BCE99A477D6A4986FB2216D8CF2CFD060097DD@XMB-BGL-417.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD060097DD@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] Last day for indicating your preferences for next SIPREC virtual 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: Wed, 13 Apr 2011 10:07:14 -0000 I also think this would be useful I will submit an updated architecture dra= ft hopefully later today. Regards Andy=20 > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Ram Mohan R (rmohanr) > Sent: 13 April 2011 09:48 > To: Elwell, John; siprec@ietf.org > Subject: Re: [siprec] Last day for indicating your=20 > preferences for next SIPREC virtual interim meeting >=20 > I see a definite value in having this meeting that week. We=20 > have already > seen several discussions on metamodel/format and I think it's=20 > useful to > have a virtual interim meeting. >=20 > Ram >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Elwell, John > > Sent: Wednesday, April 13, 2011 1:16 PM > > To: siprec@ietf.org > > Subject: [siprec] Last day for indicating your preferences for next > > SIPREC virtual interim meeting > >=20 > > Would those who haven't filled in the poll for the virtual interim > > meeting please do so today? At present it looks like the=20 > only feasible > > dates are 9th and 12th May. > >=20 > > I would also like advice from the various document authors whether > this > > would be too early (it is less than one month away). However, in my > > opinion there is already substantial discussion on the list, so it > > should be possible to have a useful meeting that week. > >=20 > > John > >=20 > >=20 > > > -----Original Message----- > > > From: Elwell, John > > > Sent: 06 April 2011 14:22 > > > To: siprec@ietf.org > > > Subject: FW: Doodle: Link for poll "SIPREC virtual interim" > > > > > > In Prague it was suggested we hold a virtual interim meeting > > > in May. Below is the link to the Doodle poll - please vote by > > > 2011-04-13. The time range is deliberately restricted because > > > we have participants from 3 continents. > > > > > > John > > > > > > > -----Original Message----- > > > > From: Doodle [mailto:mailer@doodle.com] > > > > Sent: 06 April 2011 14:16 > > > > To: Elwell, John > > > > Subject: Doodle: Link for poll "SIPREC virtual interim" > > > > > > > > You have initiated a poll "SIPREC virtual interim" at Doodle. > > > > The link to your poll is: > > > > > > > > http://doodle.com/2s7w4dpgd5i9x6zc > > > > > > > > Share this link with all those who should cast their votes. > > > > Do not forget to cast your vote, too. > > > > (If you did not initiate this poll, somebody must > > > > accidentally have used your e-mail address; simply ignore > > > > this e-mail, please.) > > > > > > > > > > > > > > _______________________________________________ > > siprec mailing 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 mperumal@cisco.com Wed Apr 13 03:36:57 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id ACC5BE06CA for ; Wed, 13 Apr 2011 03:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.992 X-Spam-Level: X-Spam-Status: No, score=-9.992 tagged_above=-999 required=5 tests=[AWL=0.607, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IIkc0xkybV2N for ; Wed, 13 Apr 2011 03:36:55 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfc.amsl.com (Postfix) with ESMTP id 24357E0613 for ; Wed, 13 Apr 2011 03:36:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=16212; q=dns/txt; s=iport; t=1302691009; x=1303900609; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=zdwUuOI+D6MBCaKE1Ntb+Y4k++xkuNQS6J9YnWOkf20=; b=U0f3MqqvOnM2SkLJVs7ItlNAiTTqm2VsMUbd3VTbc9gc2MayjdWILu01 ntsEjVFr5l+tM7bOPlvuUBcNZpEDeQ/7u8n5SLVsHHTLRnp137+WjGYtR mmiWDMa0J2OqHp81ue8uXGymDs2PqW5FZcHmKwbWqp0Q1kHiYG/UJuszO E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuQAAGt8pU2Q/khMgWdsb2JhbACYIY1pFAEBFiYlplSdBYJ+gnAEhVyMBg X-IronPort-AV: E=Sophos;i="4.64,203,1301875200"; d="scan'208";a="83383799" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 13 Apr 2011 10:36:48 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3DAajNC015854; Wed, 13 Apr 2011 10:36:47 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Apr 2011 16:06:45 +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: Wed, 13 Apr 2011 16:06:41 +0530 Message-ID: <1D062974A4845E4D8A343C65380492020533B93C@XMB-BGL-414.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] start/stop times & the metamodel Thread-Index: Acv4ar9mNRoQAPkwSImkiZlfghuuTgAIWrigAApMiDAAJ/uhEAASQRUgAAJ0TuAABJfvgAAB6y+w References: <4D9CDADD.1020403@cisco.com> <4DA2FC17.1060100@cisco.com><07465C1D981ABC41A344374066AE1A2C38AB6E1DE4@TLVMBX01.nice.com><4DA334F0.9050301@cisco.com><059AF07365DC474393A19A3AF187DF7406E67CB4@NAHALD.us.int.genesyslab.com><1D062974A4845E4D8A343C65380492020533B45B@XMB-BGL-414.cisco.com> <059AF07365DC474393A19A3AF187DF7406EF2378@NAHALD.us.int.genesyslab.com> <1D062974A4845E4D8A343C65380492020533B880@XMB-BGL-414.cisco.com> From: "Muthu ArulMozhi Perumal (mperumal)" To: "Parthasarathi R (partr)" , "Henry Lum" , "Paul Kyzivat (pkyzivat)" , "Leon Portman" X-OriginalArrivalTime: 13 Apr 2011 10:36:45.0850 (UTC) FILETIME=[AFCD4FA0:01CBF9C6] Cc: siprec@ietf.org Subject: Re: [siprec] start/stop times & the metamodel X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 13 Apr 2011 10:36:57 -0000 I don't think the requirements need to go to the level of RTP timestamp. But it may be useful to add a requirement that the SRC needs to facilitate synchronized querying/playback of the recorded media streams and metadata. I couldn't derive that directly from the requirements we already have, but would like to hear from others if this is already implied. Muthu |-----Original Message----- |From: Parthasarathi R (partr) |Sent: Wednesday, April 13, 2011 2:46 PM |To: Muthu ArulMozhi Perumal (mperumal); 'Henry Lum'; Paul Kyzivat (pkyzivat); 'Leon Portman' |Cc: 'siprec@ietf.org' |Subject: RE: [siprec] start/stop times & the metamodel | |ISTM, SRC has to act only as RTP Endpoint or RTP Mixer (not RTP translator) in case these requirement |has to be considered within SIPREC. IMO, these requirement has to be mentioned in SIPREC requirement |document to define the exact role what SRC does with media timestamp and what SRS does with media |timestamp? | |Thanks |Partha | |-----Original Message----- |From: Muthu ArulMozhi Perumal (mperumal) |Sent: Wednesday, April 13, 2011 12:36 PM |To: Parthasarathi R (partr); 'Henry Lum'; Paul Kyzivat (pkyzivat); 'Leon Portman' |Cc: 'siprec@ietf.org' |Subject: RE: [siprec] start/stop times & the metamodel | |After the use-case Paul described, it seem to me that if we keep out of scope it will put a lot of |burden on the SRS to support synchronized querying/playback which looks an important aspect for media |recording. So, we may want to consider the ways in which the SRC can facilitate it. | |Muthu | ||-----Original Message----- ||From: Parthasarathi R (partr) ||Sent: Wednesday, April 13, 2011 11:20 AM ||To: Henry Lum; Muthu ArulMozhi Perumal (mperumal); Paul Kyzivat ||(pkyzivat); Leon Portman ||Cc: siprec@ietf.org ||Subject: RE: [siprec] start/stop times & the metamodel || ||Henry, || ||I attached the follow up mail to below mail thread. Till now, We don't ||have strong requirement to solve in SIPREC. Let us identify the requirement before going to the |solution. || ||Thanks ||Partha || ||-----Original Message----- ||From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On ||Behalf Of Henry Lum ||Sent: Wednesday, April 13, 2011 2:43 AM ||To: Muthu ArulMozhi Perumal (mperumal); Paul Kyzivat (pkyzivat); Leon ||Portman ||Cc: siprec@ietf.org ||Subject: Re: [siprec] start/stop times & the metamodel || ||I don't think it is guaranteed that participants will send SR reports ||(or any RTCP), plus we will also have to assume that the NTP timestamps ||are in sync. We could mandate the SRC to generate SR reports but then we are fixing the RTP model for |the SRC. || ||Regards, ||Henry || ||> -----Original Message----- ||> From: Muthu ArulMozhi Perumal (mperumal) [mailto:mperumal@cisco.com] ||> Sent: Monday, April 11, 2011 10:45 PM ||> To: Henry Lum; Paul Kyzivat (pkyzivat); Leon Portman ||> Cc: siprec@ietf.org ||> Subject: RE: [siprec] start/stop times & the metamodel ||> ||> While I see it may be useful for the SRS to know when certain things ||> happened in CS signaling (participant joining, leaving, going mute ||etc) ||> I don't see how useful it would be for it know how those things are ||> related to when the participant actually sent/received (or stopped ||> sending/receiving) RTP. ||> ||> If we see any use, one way to do it is using the NTP timestamp ||> carried in RTCP SR reports, provided the SRC, SRS and the ||> participants have access to the same reference wallclock. ||> ||> Muthu ||> ||> |-----Original Message----- ||> |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On ||> Behalf Of Henry Lum ||> |Sent: Tuesday, April 12, 2011 2:56 AM ||> |To: Paul Kyzivat (pkyzivat); Leon Portman ||> |Cc: siprec@ietf.org ||> |Subject: Re: [siprec] start/stop times & the metamodel ||> | ||> |A related question on the RTP model is that if the SRC as an RTP ||> |translator chooses to relay the RTP timestamps, then how would the ||SRC ||> |synchronize the timestamps between the SIP messages the multiple RTP ||> |streams? ||> | ||> |Henry ||> | ||> |> -----Original Message----- ||> |> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On ||> |> Behalf Of Paul Kyzivat ||> |> Sent: Monday, April 11, 2011 1:06 PM ||> |> To: Leon Portman ||> |> Cc: siprec@ietf.org ||> |> Subject: Re: [siprec] start/stop times & the metamodel ||> |> ||> |> ||> |> ||> |> On 4/11/2011 9:36 AM, Leon Portman wrote: ||> |> > Paul Hi ||> |> > ||> |> > I agree with proposed method of time stamping metadata elements ||> with ||> |> SRC clock (it is like a wall clock from the requirement document). ||> |> > About RTP time synchronization to metadata events, we either ||> should ||> |> have some low latency event from SRC to SRS with SRC time that ||> |> will allow SRS to maintain time difference between its clock and ||> |> SRC ||> clock ||> |> and then apply it also to receive time of RTP packet (assuming no ||> |> buffering) ||> |> ||> |> ISTM the issue isn't the latency of the event - it is what it is - ||> but ||> |> rather how to correlate a sip message containing metadata with a ||> |> particular RTP packet. I suspect that needs to be tied into the ||> |> discussion of the various models for how the SRC might handle RDP. ||> |> ||> |> Thanks, ||> |> Paul ||> |> ||> |> > Leon ||> |> > ||> |> > -----Original Message----- ||> |> > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] ||> |> > On ||> |> Behalf Of Paul Kyzivat ||> |> > Sent: Monday, April 11, 2011 4:03 PM ||> |> > To: Elwell, John ||> |> > Cc: siprec@ietf.org ||> |> > Subject: Re: [siprec] start/stop times& the metamodel ||> |> > ||> |> > ||> |> > ||> |> > On 4/8/2011 11:53 AM, Elwell, John wrote: ||> |> >> Paul, ||> |> >> ||> |> >> I think much of what you say makes sense. I was concerned that ||we ||> |> probably need to record when a participant stops or starts sending ||> or ||> |> receiving a stream, which seems to be covered by your statement: ||> |> "Changes to media streams should similarly be tagged with the time ||> |they ||> |> occurred in the CS signaling. Each participant relationship change ||> |> (send, receive, inactive,) will be there." That doesn't seem to be ||> in ||> |> the model at present. ||> |> > ||> |> > John, ||> |> > ||> |> > I agree the current model doesn't reflect this - it was a ||> |> > private ||> |> thought by me, provoked by the work and discussion to date. It is ||> |> a ||> |bit ||> |> of a change of direction, so I'm interested in what others think ||> about ||> |> it. ||> |> > ||> |> > Thanks, ||> |> > Paul ||> |> > ||> |> >> John (as individual) ||> |> >> ||> |> >> ||> |> >>> -----Original Message----- ||> |> >>> From: siprec-bounces@ietf.org ||> |> >>> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat ||> |> >>> Sent: 06 April 2011 22:28 ||> |> >>> To: siprec@ietf.org ||> |> >>> Subject: [siprec] start/stop times& the metamodel ||> |> >>> ||> |> >>> In Prague, one of the open issues was around start/stop times. ||> The ||> |> >>> format draft floated the possibility of having explicit ||> start/stop ||> |> >>> times signaled for each of the metatdata elements. But then we ||> |> asked ||> |> >>> for feedback on which make sense. ||> |> >>> ||> |> >>> IMO explicit start/stop times make more sense for some things ||> than ||> |> >>> others. ||> |> >>> ||> |> >>> One place where we potentially have explicit times to report ||> with ||> |> the ||> |> >>> dialogs that constitute a CS. Each such dialog presumably has ||> |> >>> a ||> |> start ||> |> >>> and stop time observable by the SRC, which might differ, at ||> least ||> |a ||> |> >>> bit, from the corresponding signaling on the RS. ||> |> >>> ||> |> >>> We might want to report those times. Or, since we abstract the ||> CS ||> |> >>> away from the dialog, we might want to report the start time ||> |> >>> of ||> |the ||> |> >>> first dialog in the CS as the CS start time, and the stop time ||> of ||> |> the ||> |> >>> last dialog in the CS as the CS stop time. ||> |> >>> ||> |> >>> Similarly, we have abstracted media streams away from the ||> |> >>> media streams in the sip dialogs that make up the CS. We might ||> |> >>> want ||to ||> |> >>> report the start time of a media stream as the time (according ||> to ||> |> the ||> |> >>> CS) of the first participant to a new media stream, and the ||stop ||> |> time ||> |> >>> as the time that the last participant leaves the media stream. ||> |> >>> ||> |> >>> There are several things that complicate this: ||> |> >>> ||> |> >>> - Do we consider the case of a stream that starts with recvonly ||> |> >>> or inactive participants, and only later gets a sender? ||> |> >>> If ||> |so, ||> |> >>> is the start time of the stream when the first ||> |> >>> participant ||> |> arrived, ||> |> >>> or when the first sender arrived? ||> |> >>> ||> |> >>> - How do we get the clock times for the media streams? ||> |> >>> IIUC the correct ones are in the RTP/RTCP, but the ||> reporting ||> |> of ||> |> >>> these events is driven by the signaling, and we don't ||> |> >>> have ||> |> good ||> |> >>> sync between those. (E.g. media could start flowing ||> |> >>> before ||> |the ||> |> >>> corresponding signaling, and we would like to include ||> |> >>> that ||> if ||> |> we ||> |> >>> can figure it out.) So, even if the clocks used for media ||> and ||> |> >>> signaling are in sync, we might see media packets arrive ||> with ||> |> >>> a timestamp prior to the timestamp for the signaling that ||> |> >>> indicates the send state of the participant. This could ||> cause ||> |> >>> trouble in playback. ||> |> >>> ||> |> >>> - There isn't any guarantee that the clock used for signaling ||> |> >>> messages is synchronized with the clock used in RTP/RTCP. ||> |> >>> ||> |> >>> - There isn't any guarantee that there will be any RTCP at all, ||> |> >>> to provide correlation of the RTP to clocktime. ||> |> >>> ||> |> >>> The best I can see to deal with all of this is: ||> |> >>> ||> |> >>> - All the metadata messages should be timestamped by the SRC ||> |> >>> using its local clock. This is easily achieved by the Date ||> |> >>> header in the sip message. ||> |> >>> ||> |> >>> - Changes to a CS, including changes of participants, should ||> |> >>> be explicitly tagged with the time they occurred in the ||> |> >>> CS signaling, according to the SRC's clock. (If that is ||> |> >>> unavailable for some reason, then use the time the SRC ||> |> >>> became aware of it.) ||> |> >>> ||> |> >>> - We could provide a metadata update element to indicate end ||> |> >>> of a CS, but I suggest this just be shorthand for ||> indicating ||> |> >>> removal of all participants from it. (While its possible ||to ||> |> >>> mark that the CS is truly ended, that simply introduces an ||> |> >>> error case if added metadata about it is subsequently ||> sent.) ||> |> >>> The actual start/stop time would be determined by the SRS ||> |> >>> based on the timestamps of first and last data about it. ||> |> >>> ||> |> >>> - Changes to media streams should similarly be tagged with ||> |> >>> the time they occurred in the CS signaling. Each ||> participant ||> |> >>> relationship change (send, receive, inactive,) will be ||> there. ||> |> >>> The actual start/stop time of the media stream again ||> |> >>> would ||> be ||> |> >>> derived by the SRS. ||> |> >>> ||> |> >>> - CS-Groups can simply be tagged by the timestamps of the ||> |> >>> updates that put CSs into them. Explicit start/stop times ||> |> don't ||> |> >>> seem useful. If desired, the SRS can derive start/stop ||> times ||> |> >>> from the start/stop times of the contained stuff. ||> |> >>> ||> |> >>> - I now think that CS-Groups should not be "contained" within ||> |> >>> a recording. This just seems to introduce unnecessary ||error ||> |> >>> conditions, and limitations on future enhancements. The ||> |> >>> lifetime of CS-Groups will probably be naturally limited ||by ||> |> >>> the ability of the SRC to remember the IDs of old ones. ||> |> >>> For instance, if a CS-G is created during one Recording, ||> |> >>> and then another CS is added to it from a different ||> recording ||> |> >>> session, would we prefer to fail that, or just allow it? ||> |> >>> (I think allow.) ||> |> >>> ||> |> >>> - Rather, I think every update transmitted during a recording ||> |> >>> session can be tagged with a link to the metadata of the ||> |> >>> recording session it came from. This need not be explicit ||- ||> |> the ||> |> >>> SRS can do it automatically. The recording session entity ||> |> >>> itself will also have a start/stop time which is the ||start/ ||> |> >>> stop of the RS dialog as observed by the SRS. ||> |> >>> ||> |> >>> (Note the above doesn't solve the problem of getting correct ||> clock ||> |> >>> times for RTP media. If anyone has a suggestion for this I'm ||all ||> |> >>> ears.) ||> |> >>> ||> |> >>> Thanks, ||> |> >>> Paul ||> |> >>> _______________________________________________ ||> |> >>> siprec mailing 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 ||> | ||> | ||> |||--------------------------------------------------------------------- - ||> - ||> ------------------------------- ||> |------------- ||> |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. ||> | ||> |_______________________________________________ ||> |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. || ||_______________________________________________ ||siprec mailing list ||siprec@ietf.org ||https://www.ietf.org/mailman/listinfo/siprec From partr@cisco.com Wed Apr 13 04:50:26 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5407AE075A for ; Wed, 13 Apr 2011 04:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.041 X-Spam-Level: X-Spam-Status: No, score=-10.041 tagged_above=-999 required=5 tests=[AWL=0.558, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ScUBuv1yR9yB for ; Wed, 13 Apr 2011 04:50:24 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfc.amsl.com (Postfix) with ESMTP id 832D5E0767 for ; Wed, 13 Apr 2011 04:50:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=17429; q=dns/txt; s=iport; t=1302695423; x=1303905023; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=/p5lrbAsyBJD2uOKx9DtOFZk3AcDQddGcpO4zRWEp6Y=; b=P8QH1mn9sgZMpmosEYWJqc5hUzSQ6VfI8Wx75dJyilLzKKzzrc3w8hqO 5H0pHemmWuG8k9U9PDA400jNzEBnevHGDgupSeyvCyd5KuSLSrZqLyfHz HTCHkZ6lGWgWkICcsnpk5PKyWZ+kr3HFmfw7pYmakCzwD1Fn0Jn/FNV4L E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkBAJaNpU2Q/khR/2dsb2JhbACYJo1vd6ZGnQSCfoJwBIVYjAY X-IronPort-AV: E=Sophos;i="4.64,203,1301875200"; d="scan'208";a="25542992" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 13 Apr 2011 11:50:22 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3DBoLLU011703; Wed, 13 Apr 2011 11:50:21 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Apr 2011 17:20:20 +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: Wed, 13 Apr 2011 17:20:19 +0530 Message-ID: In-Reply-To: <1D062974A4845E4D8A343C65380492020533B93C@XMB-BGL-414.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] start/stop times & the metamodel Thread-Index: Acv4ar9mNRoQAPkwSImkiZlfghuuTgAIWrigAApMiDAAJ/uhEAASQRUgAAJ0TuAABJfvgAAB6y+wAAMupBA= References: <4D9CDADD.1020403@cisco.com> <4DA2FC17.1060100@cisco.com><07465C1D981ABC41A344374066AE1A2C38AB6E1DE4@TLVMBX01.nice.com><4DA334F0.9050301@cisco.com><059AF07365DC474393A19A3AF187DF7406E67CB4@NAHALD.us.int.genesyslab.com><1D062974A4845E4D8A343C65380492020533B45B@XMB-BGL-414.cisco.com> <059AF07365DC474393A19A3AF187DF7406EF2378@NAHALD.us.int.genesyslab.com> <1D062974A4845E4D8A343C65380492020533B880@XMB-BGL-414.cisco.com> <1D062974A4845E4D8A343C65380492020533B93C@XMB-BGL-414.cisco.com> From: "Parthasarathi R (partr)" To: "Muthu ArulMozhi Perumal (mperumal)" , "Henry Lum" , "Paul Kyzivat (pkyzivat)" , "Leon Portman" X-OriginalArrivalTime: 13 Apr 2011 11:50:20.0564 (UTC) FILETIME=[F72D3540:01CBF9D0] Cc: siprec@ietf.org Subject: Re: [siprec] start/stop times & the metamodel X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 13 Apr 2011 11:50:26 -0000 Muthu, Even now, Media stream block attributes like start-time, end-time in metadata from SRC facilitates SRS to have synchronized playback media in case SRS maps metadata from SRC with the received raw media. Proposed requirement is going one level deeper wherein the timestamp from SRC has to be based on RTP layer timestamp or SRC SIP signaling?=20 IMO, SIP signaling serves the purpose and there is no need of explicitly mention how SRC find start timestamp. In case you have strong usecase for RTP timestamp based requirement, it requires changes in SIPREC requirement because it is specific mechanism insisted on SRC. Thanks Partha -----Original Message----- From: Muthu ArulMozhi Perumal (mperumal)=20 Sent: Wednesday, April 13, 2011 4:07 PM To: Parthasarathi R (partr); 'Henry Lum'; Paul Kyzivat (pkyzivat); 'Leon Portman' Cc: 'siprec@ietf.org' Subject: RE: [siprec] start/stop times & the metamodel I don't think the requirements need to go to the level of RTP timestamp. But it may be useful to add a requirement that the SRC needs to facilitate synchronized querying/playback of the recorded media streams and metadata. I couldn't derive that directly from the requirements we already have, but would like to hear from others if this is already implied. Muthu |-----Original Message----- |From: Parthasarathi R (partr) |Sent: Wednesday, April 13, 2011 2:46 PM |To: Muthu ArulMozhi Perumal (mperumal); 'Henry Lum'; Paul Kyzivat (pkyzivat); 'Leon Portman' |Cc: 'siprec@ietf.org' |Subject: RE: [siprec] start/stop times & the metamodel | |ISTM, SRC has to act only as RTP Endpoint or RTP Mixer (not RTP=20 |translator) in case these requirement has to be considered within=20 |SIPREC. IMO, these requirement has to be mentioned in SIPREC=20 |requirement document to define the exact role what SRC does with media timestamp and what SRS does with media timestamp? | |Thanks |Partha | |-----Original Message----- |From: Muthu ArulMozhi Perumal (mperumal) |Sent: Wednesday, April 13, 2011 12:36 PM |To: Parthasarathi R (partr); 'Henry Lum'; Paul Kyzivat (pkyzivat); 'Leon Portman' |Cc: 'siprec@ietf.org' |Subject: RE: [siprec] start/stop times & the metamodel | |After the use-case Paul described, it seem to me that if we keep out of |scope it will put a lot of burden on the SRS to support synchronized=20 |querying/playback which looks an important aspect for media recording. So, we may want to consider the ways in which the SRC can facilitate it. | |Muthu | ||-----Original Message----- ||From: Parthasarathi R (partr) ||Sent: Wednesday, April 13, 2011 11:20 AM ||To: Henry Lum; Muthu ArulMozhi Perumal (mperumal); Paul Kyzivat=20 ||(pkyzivat); Leon Portman ||Cc: siprec@ietf.org ||Subject: RE: [siprec] start/stop times & the metamodel || ||Henry, || ||I attached the follow up mail to below mail thread. Till now, We don't ||have strong requirement to solve in SIPREC. Let us identify the=20 ||requirement before going to the |solution. || ||Thanks ||Partha || ||-----Original Message----- ||From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 ||Behalf Of Henry Lum ||Sent: Wednesday, April 13, 2011 2:43 AM ||To: Muthu ArulMozhi Perumal (mperumal); Paul Kyzivat (pkyzivat); Leon=20 ||Portman ||Cc: siprec@ietf.org ||Subject: Re: [siprec] start/stop times & the metamodel || ||I don't think it is guaranteed that participants will send SR reports=20 ||(or any RTCP), plus we will also have to assume that the NTP=20 ||timestamps are in sync. We could mandate the SRC to generate SR=20 ||reports but then we are fixing the RTP model for |the SRC. || ||Regards, ||Henry || ||> -----Original Message----- ||> From: Muthu ArulMozhi Perumal (mperumal) [mailto:mperumal@cisco.com] ||> Sent: Monday, April 11, 2011 10:45 PM ||> To: Henry Lum; Paul Kyzivat (pkyzivat); Leon Portman ||> Cc: siprec@ietf.org ||> Subject: RE: [siprec] start/stop times & the metamodel ||> ||> While I see it may be useful for the SRS to know when certain things ||> happened in CS signaling (participant joining, leaving, going mute ||etc) ||> I don't see how useful it would be for it know how those things are=20 ||> related to when the participant actually sent/received (or stopped ||> sending/receiving) RTP. ||> ||> If we see any use, one way to do it is using the NTP timestamp=20 ||> carried in RTCP SR reports, provided the SRC, SRS and the=20 ||> participants have access to the same reference wallclock. ||> ||> Muthu ||> ||> |-----Original Message----- ||> |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On ||> Behalf Of Henry Lum ||> |Sent: Tuesday, April 12, 2011 2:56 AM ||> |To: Paul Kyzivat (pkyzivat); Leon Portman ||> |Cc: siprec@ietf.org ||> |Subject: Re: [siprec] start/stop times & the metamodel ||> | ||> |A related question on the RTP model is that if the SRC as an RTP=20 ||> |translator chooses to relay the RTP timestamps, then how would the ||SRC ||> |synchronize the timestamps between the SIP messages the multiple=20 ||> |RTP streams? ||> | ||> |Henry ||> | ||> |> -----Original Message----- ||> |> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On ||> |> Behalf Of Paul Kyzivat ||> |> Sent: Monday, April 11, 2011 1:06 PM ||> |> To: Leon Portman ||> |> Cc: siprec@ietf.org ||> |> Subject: Re: [siprec] start/stop times & the metamodel ||> |> ||> |> ||> |> ||> |> On 4/11/2011 9:36 AM, Leon Portman wrote: ||> |> > Paul Hi ||> |> > ||> |> > I agree with proposed method of time stamping metadata elements ||> with ||> |> SRC clock (it is like a wall clock from the requirement document). ||> |> > About RTP time synchronization to metadata events, we either ||> should ||> |> have some low latency event from SRC to SRS with SRC time that=20 ||> |> will allow SRS to maintain time difference between its clock and=20 ||> |> SRC ||> clock ||> |> and then apply it also to receive time of RTP packet (assuming no ||> |> buffering) ||> |> ||> |> ISTM the issue isn't the latency of the event - it is what it is=20 ||> |> - ||> but ||> |> rather how to correlate a sip message containing metadata with a=20 ||> |> particular RTP packet. I suspect that needs to be tied into the=20 ||> |> discussion of the various models for how the SRC might handle RDP. ||> |> ||> |> Thanks, ||> |> Paul ||> |> ||> |> > Leon ||> |> > ||> |> > -----Original Message----- ||> |> > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org]=20 ||> |> > On ||> |> Behalf Of Paul Kyzivat ||> |> > Sent: Monday, April 11, 2011 4:03 PM ||> |> > To: Elwell, John ||> |> > Cc: siprec@ietf.org ||> |> > Subject: Re: [siprec] start/stop times& the metamodel ||> |> > ||> |> > ||> |> > ||> |> > On 4/8/2011 11:53 AM, Elwell, John wrote: ||> |> >> Paul, ||> |> >> ||> |> >> I think much of what you say makes sense. I was concerned that ||we ||> |> probably need to record when a participant stops or starts=20 ||> |> sending ||> or ||> |> receiving a stream, which seems to be covered by your statement: ||> |> "Changes to media streams should similarly be tagged with the=20 ||> |> time ||> |they ||> |> occurred in the CS signaling. Each participant relationship=20 ||> |> change (send, receive, inactive,) will be there." That doesn't=20 ||> |> seem to be ||> in ||> |> the model at present. ||> |> > ||> |> > John, ||> |> > ||> |> > I agree the current model doesn't reflect this - it was a=20 ||> |> > private ||> |> thought by me, provoked by the work and discussion to date. It is ||> |> a ||> |bit ||> |> of a change of direction, so I'm interested in what others think ||> about ||> |> it. ||> |> > ||> |> > Thanks, ||> |> > Paul ||> |> > ||> |> >> John (as individual) ||> |> >> ||> |> >> ||> |> >>> -----Original Message----- ||> |> >>> From: siprec-bounces@ietf.org=20 ||> |> >>> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat ||> |> >>> Sent: 06 April 2011 22:28 ||> |> >>> To: siprec@ietf.org ||> |> >>> Subject: [siprec] start/stop times& the metamodel ||> |> >>> ||> |> >>> In Prague, one of the open issues was around start/stop times. ||> The ||> |> >>> format draft floated the possibility of having explicit ||> start/stop ||> |> >>> times signaled for each of the metatdata elements. But then=20 ||> |> >>> we ||> |> asked ||> |> >>> for feedback on which make sense. ||> |> >>> ||> |> >>> IMO explicit start/stop times make more sense for some things ||> than ||> |> >>> others. ||> |> >>> ||> |> >>> One place where we potentially have explicit times to report ||> with ||> |> the ||> |> >>> dialogs that constitute a CS. Each such dialog presumably has ||> |> >>> a ||> |> start ||> |> >>> and stop time observable by the SRC, which might differ, at ||> least ||> |a ||> |> >>> bit, from the corresponding signaling on the RS. ||> |> >>> ||> |> >>> We might want to report those times. Or, since we abstract=20 ||> |> >>> the ||> CS ||> |> >>> away from the dialog, we might want to report the start time=20 ||> |> >>> of ||> |the ||> |> >>> first dialog in the CS as the CS start time, and the stop=20 ||> |> >>> time ||> of ||> |> the ||> |> >>> last dialog in the CS as the CS stop time. ||> |> >>> ||> |> >>> Similarly, we have abstracted media streams away from the=20 ||> |> >>> media streams in the sip dialogs that make up the CS. We=20 ||> |> >>> might want ||to ||> |> >>> report the start time of a media stream as the time=20 ||> |> >>> (according ||> to ||> |> the ||> |> >>> CS) of the first participant to a new media stream, and the ||stop ||> |> time ||> |> >>> as the time that the last participant leaves the media stream. ||> |> >>> ||> |> >>> There are several things that complicate this: ||> |> >>> ||> |> >>> - Do we consider the case of a stream that starts with recvonly ||> |> >>> or inactive participants, and only later gets a sender? ||> |> >>> If ||> |so, ||> |> >>> is the start time of the stream when the first=20 ||> |> >>> participant ||> |> arrived, ||> |> >>> or when the first sender arrived? ||> |> >>> ||> |> >>> - How do we get the clock times for the media streams? ||> |> >>> IIUC the correct ones are in the RTP/RTCP, but the ||> reporting ||> |> of ||> |> >>> these events is driven by the signaling, and we don't=20 ||> |> >>> have ||> |> good ||> |> >>> sync between those. (E.g. media could start flowing=20 ||> |> >>> before ||> |the ||> |> >>> corresponding signaling, and we would like to include=20 ||> |> >>> that ||> if ||> |> we ||> |> >>> can figure it out.) So, even if the clocks used for=20 ||> |> >>> media ||> and ||> |> >>> signaling are in sync, we might see media packets arrive ||> with ||> |> >>> a timestamp prior to the timestamp for the signaling that ||> |> >>> indicates the send state of the participant. This could ||> cause ||> |> >>> trouble in playback. ||> |> >>> ||> |> >>> - There isn't any guarantee that the clock used for signaling ||> |> >>> messages is synchronized with the clock used in RTP/RTCP. ||> |> >>> ||> |> >>> - There isn't any guarantee that there will be any RTCP at all, ||> |> >>> to provide correlation of the RTP to clocktime. ||> |> >>> ||> |> >>> The best I can see to deal with all of this is: ||> |> >>> ||> |> >>> - All the metadata messages should be timestamped by the SRC ||> |> >>> using its local clock. This is easily achieved by the Date ||> |> >>> header in the sip message. ||> |> >>> ||> |> >>> - Changes to a CS, including changes of participants, should ||> |> >>> be explicitly tagged with the time they occurred in the ||> |> >>> CS signaling, according to the SRC's clock. (If that is ||> |> >>> unavailable for some reason, then use the time the SRC ||> |> >>> became aware of it.) ||> |> >>> ||> |> >>> - We could provide a metadata update element to indicate end ||> |> >>> of a CS, but I suggest this just be shorthand for ||> indicating ||> |> >>> removal of all participants from it. (While its possible ||to ||> |> >>> mark that the CS is truly ended, that simply introduces an ||> |> >>> error case if added metadata about it is subsequently ||> sent.) ||> |> >>> The actual start/stop time would be determined by the SRS ||> |> >>> based on the timestamps of first and last data about it. ||> |> >>> ||> |> >>> - Changes to media streams should similarly be tagged with ||> |> >>> the time they occurred in the CS signaling. Each ||> participant ||> |> >>> relationship change (send, receive, inactive,) will be ||> there. ||> |> >>> The actual start/stop time of the media stream again=20 ||> |> >>> would ||> be ||> |> >>> derived by the SRS. ||> |> >>> ||> |> >>> - CS-Groups can simply be tagged by the timestamps of the ||> |> >>> updates that put CSs into them. Explicit start/stop=20 ||> |> >>> times ||> |> don't ||> |> >>> seem useful. If desired, the SRS can derive start/stop ||> times ||> |> >>> from the start/stop times of the contained stuff. ||> |> >>> ||> |> >>> - I now think that CS-Groups should not be "contained" within ||> |> >>> a recording. This just seems to introduce unnecessary ||error ||> |> >>> conditions, and limitations on future enhancements. The ||> |> >>> lifetime of CS-Groups will probably be naturally limited ||by ||> |> >>> the ability of the SRC to remember the IDs of old ones. ||> |> >>> For instance, if a CS-G is created during one Recording, ||> |> >>> and then another CS is added to it from a different ||> recording ||> |> >>> session, would we prefer to fail that, or just allow it? ||> |> >>> (I think allow.) ||> |> >>> ||> |> >>> - Rather, I think every update transmitted during a recording ||> |> >>> session can be tagged with a link to the metadata of the ||> |> >>> recording session it came from. This need not be=20 ||> |> >>> explicit ||- ||> |> the ||> |> >>> SRS can do it automatically. The recording session entity ||> |> >>> itself will also have a start/stop time which is the ||start/ ||> |> >>> stop of the RS dialog as observed by the SRS. ||> |> >>> ||> |> >>> (Note the above doesn't solve the problem of getting correct ||> clock ||> |> >>> times for RTP media. If anyone has a suggestion for this I'm ||all ||> |> >>> ears.) ||> |> >>> ||> |> >>> Thanks, ||> |> >>> Paul ||> |> >>> _______________________________________________ ||> |> >>> siprec mailing 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 ||> | ||> | ||> |||--------------------------------------------------------------------- |||- ||> - ||> ------------------------------- ||> |------------- ||> |CONFIDENTIALITY NOTICE: This e-mail and any files attached may ||contain ||> confidential and proprietary ||> |information of Alcatel-Lucent and/or its affiliated entities.=20 ||> |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. ||> | ||> |_______________________________________________ ||> |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=20 ||affiliated entities. Access by the intended recipient only is=20 ||authorized. Any liability arising from any party acting, or refraining ||from acting, on any information contained in this e-mail is hereby=20 ||excluded. If you are not the intended recipient, please notify the=20 ||sender immediately, destroy the |original transmission and its attachments and do not disclose the=20 |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. || ||_______________________________________________ ||siprec mailing list ||siprec@ietf.org ||https://www.ietf.org/mailman/listinfo/siprec From john.elwell@siemens-enterprise.com Wed Apr 13 05:52:39 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 80160E0756 for ; Wed, 13 Apr 2011 05:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.771 X-Spam-Level: X-Spam-Status: No, score=-104.771 tagged_above=-999 required=5 tests=[AWL=1.828, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rk7CXSEt15-b for ; Wed, 13 Apr 2011 05:52:37 -0700 (PDT) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfc.amsl.com (Postfix) with SMTP id EF142E0752 for ; Wed, 13 Apr 2011 05:52:36 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1302699153!20763818!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 2165 invoked from network); 13 Apr 2011 12:52:33 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-14.tower-27.messagelabs.com with SMTP; 13 Apr 2011 12:52:33 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 8E6E51EB83EC; Wed, 13 Apr 2011 14:52:35 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 13 Apr 2011 14:52:35 +0200 From: "Elwell, John" To: "Muthu ArulMozhi Perumal (mperumal)" , "Parthasarathi R (partr)" , Henry Lum , "Paul Kyzivat (pkyzivat)" , Leon Portman Date: Wed, 13 Apr 2011 14:52:33 +0200 Thread-Topic: [siprec] start/stop times & the metamodel Thread-Index: Acv4ar9mNRoQAPkwSImkiZlfghuuTgAIWrigAApMiDAAJ/uhEAASQRUgAAJ0TuAABJfvgAAB6y+wAAXBHvA= Message-ID: References: <4D9CDADD.1020403@cisco.com> <4DA2FC17.1060100@cisco.com><07465C1D981ABC41A344374066AE1A2C38AB6E1DE4@TLVMBX01.nice.com><4DA334F0.9050301@cisco.com><059AF07365DC474393A19A3AF187DF7406E67CB4@NAHALD.us.int.genesyslab.com><1D062974A4845E4D8A343C65380492020533B45B@XMB-BGL-414.cisco.com> <059AF07365DC474393A19A3AF187DF7406EF2378@NAHALD.us.int.genesyslab.com> <1D062974A4845E4D8A343C65380492020533B880@XMB-BGL-414.cisco.com> <1D062974A4845E4D8A343C65380492020533B93C@XMB-BGL-414.cisco.com> Keywords: SIPREC In-Reply-To: <1D062974A4845E4D8A343C65380492020533B93C@XMB-BGL-414.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 Cc: "siprec@ietf.org" Subject: Re: [siprec] start/stop times & the metamodel X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 13 Apr 2011 12:52:39 -0000 Muthu, Please note that IETF last call on draft-ietf-siprec-req-09 ends 2011-04-20= . If you don't think the requirements relating to time (e.g., REQ-022 and = REQ-023) are sufficient, please respond to the last call. John (as chair) > -----Original Message----- > From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On Behalf Of Muthu ArulMozhi > Perumal (mperumal) > Sent: 13 April 2011 11:37 > To: Parthasarathi R (partr); Henry Lum; Paul Kyzivat > (pkyzivat); Leon Portman > Cc: siprec@ietf.org > Subject: Re: [siprec] start/stop times & the metamodel > > I don't think the requirements need to go to the level of RTP > timestamp. > But it may be useful to add a requirement that the SRC needs to > facilitate synchronized querying/playback of the recorded > media streams > and metadata. I couldn't derive that directly from the requirements we > already have, but would like to hear from others if this is already > implied. > > Muthu > > |-----Original Message----- > |From: Parthasarathi R (partr) > |Sent: Wednesday, April 13, 2011 2:46 PM > |To: Muthu ArulMozhi Perumal (mperumal); 'Henry Lum'; Paul Kyzivat > (pkyzivat); 'Leon Portman' > |Cc: 'siprec@ietf.org' > |Subject: RE: [siprec] start/stop times & the metamodel > | > |ISTM, SRC has to act only as RTP Endpoint or RTP Mixer (not RTP > translator) in case these requirement > |has to be considered within SIPREC. IMO, these requirement has to be > mentioned in SIPREC requirement > |document to define the exact role what SRC does with media timestamp > and what SRS does with media > |timestamp? > | > |Thanks > |Partha > | > |-----Original Message----- > |From: Muthu ArulMozhi Perumal (mperumal) > |Sent: Wednesday, April 13, 2011 12:36 PM > |To: Parthasarathi R (partr); 'Henry Lum'; Paul Kyzivat (pkyzivat); > 'Leon Portman' > |Cc: 'siprec@ietf.org' > |Subject: RE: [siprec] start/stop times & the metamodel > | > |After the use-case Paul described, it seem to me that if we > keep out of > scope it will put a lot of > |burden on the SRS to support synchronized querying/playback > which looks > an important aspect for media > |recording. So, we may want to consider the ways in which the SRC can > facilitate it. > | > |Muthu > | > ||-----Original Message----- > ||From: Parthasarathi R (partr) > ||Sent: Wednesday, April 13, 2011 11:20 AM > ||To: Henry Lum; Muthu ArulMozhi Perumal (mperumal); Paul Kyzivat > ||(pkyzivat); Leon Portman > ||Cc: siprec@ietf.org > ||Subject: RE: [siprec] start/stop times & the metamodel > || > ||Henry, > || > ||I attached the follow up mail to below mail thread. Till > now, We don't > ||have strong requirement to solve in SIPREC. Let us identify the > requirement before going to the > |solution. > || > ||Thanks > ||Partha > || > ||-----Original Message----- > ||From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > ||Behalf Of Henry Lum > ||Sent: Wednesday, April 13, 2011 2:43 AM > ||To: Muthu ArulMozhi Perumal (mperumal); Paul Kyzivat > (pkyzivat); Leon > ||Portman > ||Cc: siprec@ietf.org > ||Subject: Re: [siprec] start/stop times & the metamodel > || > ||I don't think it is guaranteed that participants will send > SR reports > ||(or any RTCP), plus we will also have to assume that the NTP > timestamps > ||are in sync. We could mandate the SRC to generate SR > reports but then > we are fixing the RTP model for > |the SRC. > || > ||Regards, > ||Henry > || > ||> -----Original Message----- > ||> From: Muthu ArulMozhi Perumal (mperumal) > [mailto:mperumal@cisco.com] > ||> Sent: Monday, April 11, 2011 10:45 PM > ||> To: Henry Lum; Paul Kyzivat (pkyzivat); Leon Portman > ||> Cc: siprec@ietf.org > ||> Subject: RE: [siprec] start/stop times & the metamodel > ||> > ||> While I see it may be useful for the SRS to know when > certain things > ||> happened in CS signaling (participant joining, leaving, going mute > ||etc) > ||> I don't see how useful it would be for it know how those > things are > ||> related to when the participant actually sent/received (or stopped > ||> sending/receiving) RTP. > ||> > ||> If we see any use, one way to do it is using the NTP timestamp > ||> carried in RTCP SR reports, provided the SRC, SRS and the > ||> participants have access to the same reference wallclock. > ||> > ||> Muthu > ||> > ||> |-----Original Message----- > ||> |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > ||> Behalf Of Henry Lum > ||> |Sent: Tuesday, April 12, 2011 2:56 AM > ||> |To: Paul Kyzivat (pkyzivat); Leon Portman > ||> |Cc: siprec@ietf.org > ||> |Subject: Re: [siprec] start/stop times & the metamodel > ||> | > ||> |A related question on the RTP model is that if the SRC as an RTP > ||> |translator chooses to relay the RTP timestamps, then how > would the > ||SRC > ||> |synchronize the timestamps between the SIP messages the multiple > RTP > ||> |streams? > ||> | > ||> |Henry > ||> | > ||> |> -----Original Message----- > ||> |> From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On > ||> |> Behalf Of Paul Kyzivat > ||> |> Sent: Monday, April 11, 2011 1:06 PM > ||> |> To: Leon Portman > ||> |> Cc: siprec@ietf.org > ||> |> Subject: Re: [siprec] start/stop times & the metamodel > ||> |> > ||> |> > ||> |> > ||> |> On 4/11/2011 9:36 AM, Leon Portman wrote: > ||> |> > Paul Hi > ||> |> > > ||> |> > I agree with proposed method of time stamping > metadata elements > ||> with > ||> |> SRC clock (it is like a wall clock from the requirement > document). > ||> |> > About RTP time synchronization to metadata events, we either > ||> should > ||> |> have some low latency event from SRC to SRS with SRC time that > ||> |> will allow SRS to maintain time difference between its > clock and > ||> |> SRC > ||> clock > ||> |> and then apply it also to receive time of RTP packet > (assuming no > ||> |> buffering) > ||> |> > ||> |> ISTM the issue isn't the latency of the event - it is > what it is > - > ||> but > ||> |> rather how to correlate a sip message containing > metadata with a > ||> |> particular RTP packet. I suspect that needs to be tied into the > ||> |> discussion of the various models for how the SRC might handle > RDP. > ||> |> > ||> |> Thanks, > ||> |> Paul > ||> |> > ||> |> > Leon > ||> |> > > ||> |> > -----Original Message----- > ||> |> > From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] > ||> |> > On > ||> |> Behalf Of Paul Kyzivat > ||> |> > Sent: Monday, April 11, 2011 4:03 PM > ||> |> > To: Elwell, John > ||> |> > Cc: siprec@ietf.org > ||> |> > Subject: Re: [siprec] start/stop times& the metamodel > ||> |> > > ||> |> > > ||> |> > > ||> |> > On 4/8/2011 11:53 AM, Elwell, John wrote: > ||> |> >> Paul, > ||> |> >> > ||> |> >> I think much of what you say makes sense. I was > concerned that > ||we > ||> |> probably need to record when a participant stops or starts > sending > ||> or > ||> |> receiving a stream, which seems to be covered by your > statement: > ||> |> "Changes to media streams should similarly be tagged with the > time > ||> |they > ||> |> occurred in the CS signaling. Each participant relationship > change > ||> |> (send, receive, inactive,) will be there." That doesn't seem to > be > ||> in > ||> |> the model at present. > ||> |> > > ||> |> > John, > ||> |> > > ||> |> > I agree the current model doesn't reflect this - it was a > ||> |> > private > ||> |> thought by me, provoked by the work and discussion to > date. It is > ||> |> a > ||> |bit > ||> |> of a change of direction, so I'm interested in what > others think > ||> about > ||> |> it. > ||> |> > > ||> |> > Thanks, > ||> |> > Paul > ||> |> > > ||> |> >> John (as individual) > ||> |> >> > ||> |> >> > ||> |> >>> -----Original Message----- > ||> |> >>> From: siprec-bounces@ietf.org > ||> |> >>> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > ||> |> >>> Sent: 06 April 2011 22:28 > ||> |> >>> To: siprec@ietf.org > ||> |> >>> Subject: [siprec] start/stop times& the metamodel > ||> |> >>> > ||> |> >>> In Prague, one of the open issues was around start/stop > times. > ||> The > ||> |> >>> format draft floated the possibility of having explicit > ||> start/stop > ||> |> >>> times signaled for each of the metatdata elements. But then > we > ||> |> asked > ||> |> >>> for feedback on which make sense. > ||> |> >>> > ||> |> >>> IMO explicit start/stop times make more sense for > some things > ||> than > ||> |> >>> others. > ||> |> >>> > ||> |> >>> One place where we potentially have explicit times > to report > ||> with > ||> |> the > ||> |> >>> dialogs that constitute a CS. Each such dialog > presumably has > ||> |> >>> a > ||> |> start > ||> |> >>> and stop time observable by the SRC, which might differ, at > ||> least > ||> |a > ||> |> >>> bit, from the corresponding signaling on the RS. > ||> |> >>> > ||> |> >>> We might want to report those times. Or, since we abstract > the > ||> CS > ||> |> >>> away from the dialog, we might want to report the > start time > ||> |> >>> of > ||> |the > ||> |> >>> first dialog in the CS as the CS start time, and the stop > time > ||> of > ||> |> the > ||> |> >>> last dialog in the CS as the CS stop time. > ||> |> >>> > ||> |> >>> Similarly, we have abstracted media streams away from the > ||> |> >>> media streams in the sip dialogs that make up the CS. We > might > ||> |> >>> want > ||to > ||> |> >>> report the start time of a media stream as the time > (according > ||> to > ||> |> the > ||> |> >>> CS) of the first participant to a new media stream, and the > ||stop > ||> |> time > ||> |> >>> as the time that the last participant leaves the media > stream. > ||> |> >>> > ||> |> >>> There are several things that complicate this: > ||> |> >>> > ||> |> >>> - Do we consider the case of a stream that starts with > recvonly > ||> |> >>> or inactive participants, and only later gets > a sender? > ||> |> >>> If > ||> |so, > ||> |> >>> is the start time of the stream when the first > ||> |> >>> participant > ||> |> arrived, > ||> |> >>> or when the first sender arrived? > ||> |> >>> > ||> |> >>> - How do we get the clock times for the media streams? > ||> |> >>> IIUC the correct ones are in the RTP/RTCP, but the > ||> reporting > ||> |> of > ||> |> >>> these events is driven by the signaling, and we don't > ||> |> >>> have > ||> |> good > ||> |> >>> sync between those. (E.g. media could start flowing > ||> |> >>> before > ||> |the > ||> |> >>> corresponding signaling, and we would like to include > ||> |> >>> that > ||> if > ||> |> we > ||> |> >>> can figure it out.) So, even if the clocks used for > media > ||> and > ||> |> >>> signaling are in sync, we might see media > packets arrive > ||> with > ||> |> >>> a timestamp prior to the timestamp for the signaling > that > ||> |> >>> indicates the send state of the participant. > This could > ||> cause > ||> |> >>> trouble in playback. > ||> |> >>> > ||> |> >>> - There isn't any guarantee that the clock used > for signaling > ||> |> >>> messages is synchronized with the clock used in > RTP/RTCP. > ||> |> >>> > ||> |> >>> - There isn't any guarantee that there will be any RTCP at > all, > ||> |> >>> to provide correlation of the RTP to clocktime. > ||> |> >>> > ||> |> >>> The best I can see to deal with all of this is: > ||> |> >>> > ||> |> >>> - All the metadata messages should be timestamped > by the SRC > ||> |> >>> using its local clock. This is easily achieved by the > Date > ||> |> >>> header in the sip message. > ||> |> >>> > ||> |> >>> - Changes to a CS, including changes of > participants, should > ||> |> >>> be explicitly tagged with the time they > occurred in the > ||> |> >>> CS signaling, according to the SRC's clock. > (If that is > ||> |> >>> unavailable for some reason, then use the time the SRC > ||> |> >>> became aware of it.) > ||> |> >>> > ||> |> >>> - We could provide a metadata update element to > indicate end > ||> |> >>> of a CS, but I suggest this just be shorthand for > ||> indicating > ||> |> >>> removal of all participants from it. (While > its possible > ||to > ||> |> >>> mark that the CS is truly ended, that simply > introduces > an > ||> |> >>> error case if added metadata about it is subsequently > ||> sent.) > ||> |> >>> The actual start/stop time would be determined by the > SRS > ||> |> >>> based on the timestamps of first and last > data about it. > ||> |> >>> > ||> |> >>> - Changes to media streams should similarly be tagged with > ||> |> >>> the time they occurred in the CS signaling. Each > ||> participant > ||> |> >>> relationship change (send, receive, inactive,) will be > ||> there. > ||> |> >>> The actual start/stop time of the media stream again > ||> |> >>> would > ||> be > ||> |> >>> derived by the SRS. > ||> |> >>> > ||> |> >>> - CS-Groups can simply be tagged by the timestamps of the > ||> |> >>> updates that put CSs into them. Explicit start/stop > times > ||> |> don't > ||> |> >>> seem useful. If desired, the SRS can derive start/stop > ||> times > ||> |> >>> from the start/stop times of the contained stuff. > ||> |> >>> > ||> |> >>> - I now think that CS-Groups should not be > "contained" within > ||> |> >>> a recording. This just seems to introduce unnecessary > ||error > ||> |> >>> conditions, and limitations on future > enhancements. The > ||> |> >>> lifetime of CS-Groups will probably be > naturally limited > ||by > ||> |> >>> the ability of the SRC to remember the IDs of > old ones. > ||> |> >>> For instance, if a CS-G is created during one > Recording, > ||> |> >>> and then another CS is added to it from a different > ||> recording > ||> |> >>> session, would we prefer to fail that, or > just allow it? > ||> |> >>> (I think allow.) > ||> |> >>> > ||> |> >>> - Rather, I think every update transmitted during > a recording > ||> |> >>> session can be tagged with a link to the > metadata of the > ||> |> >>> recording session it came from. This need not be > explicit > ||- > ||> |> the > ||> |> >>> SRS can do it automatically. The recording session > entity > ||> |> >>> itself will also have a start/stop time which is the > ||start/ > ||> |> >>> stop of the RS dialog as observed by the SRS. > ||> |> >>> > ||> |> >>> (Note the above doesn't solve the problem of > getting correct > ||> clock > ||> |> >>> times for RTP media. If anyone has a suggestion > for this I'm > ||all > ||> |> >>> ears.) > ||> |> >>> > ||> |> >>> Thanks, > ||> |> >>> Paul > ||> |> >>> _______________________________________________ > ||> |> >>> siprec mailing 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 > ||> | > ||> | > ||> > |||----------------------------------------------------------- > ---------- > - > ||> - > ||> ------------------------------- > ||> |------------- > ||> |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. > ||> | > ||> |_______________________________________________ > ||> |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. > || > ||_______________________________________________ > ||siprec mailing 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@cisco.com Wed Apr 13 05:58:31 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 53F12E0757 for ; Wed, 13 Apr 2011 05:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.476 X-Spam-Level: X-Spam-Status: No, score=-110.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-E5QVZqe7Eq for ; Wed, 13 Apr 2011 05:58:29 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfc.amsl.com (Postfix) with ESMTP id D9984E0752 for ; Wed, 13 Apr 2011 05:58:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=20032; q=dns/txt; s=iport; t=1302699508; x=1303909108; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=whhiUmTkCzK5TNn64OfUepi8QuYpRr8TGuK6meLI4Ig=; b=Dw5IdrbYuVwGQpZgFga2aAAucxVFoAKs6U0bWQ1OSEqZUaVmpI2AKNfp q/OqZ/+lj0Rm4JCWhs4aUZrB9iwjy8wuyvAOyT3MNCH9K8YKtjWTF8xpD srSqkc5gyIP5nsMIqZ7z6QKwDiQ6AsSptoMIQNSpDzjXS2NlvWoKkPFw1 A=; X-IronPort-AV: E=Sophos;i="4.64,204,1301875200"; d="scan'208";a="428931892" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-1.cisco.com with ESMTP; 13 Apr 2011 12:58:28 +0000 Received: from [161.44.174.125] (dhcp-161-44-174-125.cisco.com [161.44.174.125]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3DCwRIS009176; Wed, 13 Apr 2011 12:58:27 GMT Message-ID: <4DA59DF3.7020500@cisco.com> Date: Wed, 13 Apr 2011 08:58:27 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Parthasarathi R (partr)" References: <4D9CDADD.1020403@cisco.com> <4DA2FC17.1060100@cisco.com><07465C1D981ABC41A344374066AE1A2C38AB6E1DE4@TLVMBX01.nice.com><4DA334F0.9050301@cisco.com><059AF07365DC474393A19A3AF187DF7406E67CB4@NAHALD.us.int.genesyslab.com><1D062974A4845E4D8A343C65380492020533B45B@XMB-BGL-414.cisco.com> <059AF07365DC474393A19A3AF187DF7406EF2378@NAHALD.us.int.genesyslab.com> <1D062974A4845E4D8A343C65380492020533B880@XMB-BGL-414.cisco.com> <1D062974A4845E4D8A343C65380492020533B93C@XMB-BGL-414.cisco.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] start/stop times & the metamodel X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 13 Apr 2011 12:58:31 -0000 On 4/13/2011 7:50 AM, Parthasarathi R (partr) wrote: > Muthu, > > Even now, Media stream block attributes like start-time, end-time in > metadata from SRC facilitates SRS to have synchronized playback media in > case SRS maps metadata from SRC with the received raw media. Proposed > requirement is going one level deeper wherein the timestamp from SRC has > to be based on RTP layer timestamp or SRC SIP signaling? > > IMO, SIP signaling serves the purpose and there is no need of explicitly > mention how SRC find start timestamp. In case you have strong usecase > for RTP timestamp based requirement, it requires changes in SIPREC > requirement because it is specific mechanism insisted on SRC. Let me start out by saying that I don't know what the answer(s) are here - I have a very limited knowledge of RTP. The timestamps in the metadata (or in the sip messages that carry the metadata) are a *piece* of the solution. How *sufficient* they are remains to be seen - perhaps by demonstrating some procedures for using them to achieve a useful playback result in various scenarios. The problem seems to be that even if a timestamp from the CS signaling is passed in the metadata, its not clear how that can be synchronized with RTP data arriving at the SRS. *Perhaps* its enough if you assume that RTP packets will begin to arrive at the SRS concurrently with the signaling that describes the corresponding stream. I'm certain that is *not* true, but I don't know how *far* from true it is, or how much that will vary based on scenario. It does seem to me that it is a mistake to standardize a mechanism that *depends* on such a shaky mechanism. (But a mechanism that uses this as a fallback mechanism might make sense.) Thanks, Paul > Thanks > Partha > > -----Original Message----- > From: Muthu ArulMozhi Perumal (mperumal) > Sent: Wednesday, April 13, 2011 4:07 PM > To: Parthasarathi R (partr); 'Henry Lum'; Paul Kyzivat (pkyzivat); 'Leon > Portman' > Cc: 'siprec@ietf.org' > Subject: RE: [siprec] start/stop times& the metamodel > > I don't think the requirements need to go to the level of RTP timestamp. > But it may be useful to add a requirement that the SRC needs to > facilitate synchronized querying/playback of the recorded media streams > and metadata. I couldn't derive that directly from the requirements we > already have, but would like to hear from others if this is already > implied. > > Muthu > > |-----Original Message----- > |From: Parthasarathi R (partr) > |Sent: Wednesday, April 13, 2011 2:46 PM > |To: Muthu ArulMozhi Perumal (mperumal); 'Henry Lum'; Paul Kyzivat > (pkyzivat); 'Leon Portman' > |Cc: 'siprec@ietf.org' > |Subject: RE: [siprec] start/stop times& the metamodel > | > |ISTM, SRC has to act only as RTP Endpoint or RTP Mixer (not RTP > |translator) in case these requirement has to be considered within > |SIPREC. IMO, these requirement has to be mentioned in SIPREC > |requirement document to define the exact role what SRC does with media > timestamp and what SRS does with media timestamp? > | > |Thanks > |Partha > | > |-----Original Message----- > |From: Muthu ArulMozhi Perumal (mperumal) > |Sent: Wednesday, April 13, 2011 12:36 PM > |To: Parthasarathi R (partr); 'Henry Lum'; Paul Kyzivat (pkyzivat); > 'Leon Portman' > |Cc: 'siprec@ietf.org' > |Subject: RE: [siprec] start/stop times& the metamodel > | > |After the use-case Paul described, it seem to me that if we keep out of > > |scope it will put a lot of burden on the SRS to support synchronized > |querying/playback which looks an important aspect for media recording. > So, we may want to consider the ways in which the SRC can facilitate it. > | > |Muthu > | > ||-----Original Message----- > ||From: Parthasarathi R (partr) > ||Sent: Wednesday, April 13, 2011 11:20 AM > ||To: Henry Lum; Muthu ArulMozhi Perumal (mperumal); Paul Kyzivat > ||(pkyzivat); Leon Portman > ||Cc: siprec@ietf.org > ||Subject: RE: [siprec] start/stop times& the metamodel > || > ||Henry, > || > ||I attached the follow up mail to below mail thread. Till now, We don't > > ||have strong requirement to solve in SIPREC. Let us identify the > ||requirement before going to the > |solution. > || > ||Thanks > ||Partha > || > ||-----Original Message----- > ||From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > ||Behalf Of Henry Lum > ||Sent: Wednesday, April 13, 2011 2:43 AM > ||To: Muthu ArulMozhi Perumal (mperumal); Paul Kyzivat (pkyzivat); Leon > ||Portman > ||Cc: siprec@ietf.org > ||Subject: Re: [siprec] start/stop times& the metamodel > || > ||I don't think it is guaranteed that participants will send SR reports > ||(or any RTCP), plus we will also have to assume that the NTP > ||timestamps are in sync. We could mandate the SRC to generate SR > ||reports but then we are fixing the RTP model for > |the SRC. > || > ||Regards, > ||Henry > || > ||> -----Original Message----- > ||> From: Muthu ArulMozhi Perumal (mperumal) [mailto:mperumal@cisco.com] > ||> Sent: Monday, April 11, 2011 10:45 PM > ||> To: Henry Lum; Paul Kyzivat (pkyzivat); Leon Portman > ||> Cc: siprec@ietf.org > ||> Subject: RE: [siprec] start/stop times& the metamodel > ||> > ||> While I see it may be useful for the SRS to know when certain things > > ||> happened in CS signaling (participant joining, leaving, going mute > ||etc) > ||> I don't see how useful it would be for it know how those things are > ||> related to when the participant actually sent/received (or stopped > ||> sending/receiving) RTP. > ||> > ||> If we see any use, one way to do it is using the NTP timestamp > ||> carried in RTCP SR reports, provided the SRC, SRS and the > ||> participants have access to the same reference wallclock. > ||> > ||> Muthu > ||> > ||> |-----Original Message----- > ||> |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > ||> Behalf Of Henry Lum > ||> |Sent: Tuesday, April 12, 2011 2:56 AM > ||> |To: Paul Kyzivat (pkyzivat); Leon Portman > ||> |Cc: siprec@ietf.org > ||> |Subject: Re: [siprec] start/stop times& the metamodel > ||> | > ||> |A related question on the RTP model is that if the SRC as an RTP > ||> |translator chooses to relay the RTP timestamps, then how would the > ||SRC > ||> |synchronize the timestamps between the SIP messages the multiple > ||> |RTP streams? > ||> | > ||> |Henry > ||> | > ||> |> -----Original Message----- > ||> |> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > ||> |> Behalf Of Paul Kyzivat > ||> |> Sent: Monday, April 11, 2011 1:06 PM > ||> |> To: Leon Portman > ||> |> Cc: siprec@ietf.org > ||> |> Subject: Re: [siprec] start/stop times& the metamodel > ||> |> > ||> |> > ||> |> > ||> |> On 4/11/2011 9:36 AM, Leon Portman wrote: > ||> |> > Paul Hi > ||> |> > > ||> |> > I agree with proposed method of time stamping metadata elements > ||> with > ||> |> SRC clock (it is like a wall clock from the requirement > document). > ||> |> > About RTP time synchronization to metadata events, we either > ||> should > ||> |> have some low latency event from SRC to SRS with SRC time that > ||> |> will allow SRS to maintain time difference between its clock and > ||> |> SRC > ||> clock > ||> |> and then apply it also to receive time of RTP packet (assuming no > ||> |> buffering) > ||> |> > ||> |> ISTM the issue isn't the latency of the event - it is what it is > ||> |> - > ||> but > ||> |> rather how to correlate a sip message containing metadata with a > ||> |> particular RTP packet. I suspect that needs to be tied into the > ||> |> discussion of the various models for how the SRC might handle > RDP. > ||> |> > ||> |> Thanks, > ||> |> Paul > ||> |> > ||> |> > Leon > ||> |> > > ||> |> > -----Original Message----- > ||> |> > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] > ||> |> > On > ||> |> Behalf Of Paul Kyzivat > ||> |> > Sent: Monday, April 11, 2011 4:03 PM > ||> |> > To: Elwell, John > ||> |> > Cc: siprec@ietf.org > ||> |> > Subject: Re: [siprec] start/stop times& the metamodel > ||> |> > > ||> |> > > ||> |> > > ||> |> > On 4/8/2011 11:53 AM, Elwell, John wrote: > ||> |> >> Paul, > ||> |> >> > ||> |> >> I think much of what you say makes sense. I was concerned that > ||we > ||> |> probably need to record when a participant stops or starts > ||> |> sending > ||> or > ||> |> receiving a stream, which seems to be covered by your statement: > ||> |> "Changes to media streams should similarly be tagged with the > ||> |> time > ||> |they > ||> |> occurred in the CS signaling. Each participant relationship > ||> |> change (send, receive, inactive,) will be there." That doesn't > ||> |> seem to be > ||> in > ||> |> the model at present. > ||> |> > > ||> |> > John, > ||> |> > > ||> |> > I agree the current model doesn't reflect this - it was a > ||> |> > private > ||> |> thought by me, provoked by the work and discussion to date. It is > > ||> |> a > ||> |bit > ||> |> of a change of direction, so I'm interested in what others think > ||> about > ||> |> it. > ||> |> > > ||> |> > Thanks, > ||> |> > Paul > ||> |> > > ||> |> >> John (as individual) > ||> |> >> > ||> |> >> > ||> |> >>> -----Original Message----- > ||> |> >>> From: siprec-bounces@ietf.org > ||> |> >>> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > ||> |> >>> Sent: 06 April 2011 22:28 > ||> |> >>> To: siprec@ietf.org > ||> |> >>> Subject: [siprec] start/stop times& the metamodel > ||> |> >>> > ||> |> >>> In Prague, one of the open issues was around start/stop > times. > ||> The > ||> |> >>> format draft floated the possibility of having explicit > ||> start/stop > ||> |> >>> times signaled for each of the metatdata elements. But then > ||> |> >>> we > ||> |> asked > ||> |> >>> for feedback on which make sense. > ||> |> >>> > ||> |> >>> IMO explicit start/stop times make more sense for some things > ||> than > ||> |> >>> others. > ||> |> >>> > ||> |> >>> One place where we potentially have explicit times to report > ||> with > ||> |> the > ||> |> >>> dialogs that constitute a CS. Each such dialog presumably has > > ||> |> >>> a > ||> |> start > ||> |> >>> and stop time observable by the SRC, which might differ, at > ||> least > ||> |a > ||> |> >>> bit, from the corresponding signaling on the RS. > ||> |> >>> > ||> |> >>> We might want to report those times. Or, since we abstract > ||> |> >>> the > ||> CS > ||> |> >>> away from the dialog, we might want to report the start time > ||> |> >>> of > ||> |the > ||> |> >>> first dialog in the CS as the CS start time, and the stop > ||> |> >>> time > ||> of > ||> |> the > ||> |> >>> last dialog in the CS as the CS stop time. > ||> |> >>> > ||> |> >>> Similarly, we have abstracted media streams away from the > ||> |> >>> media streams in the sip dialogs that make up the CS. We > ||> |> >>> might want > ||to > ||> |> >>> report the start time of a media stream as the time > ||> |> >>> (according > ||> to > ||> |> the > ||> |> >>> CS) of the first participant to a new media stream, and the > ||stop > ||> |> time > ||> |> >>> as the time that the last participant leaves the media > stream. > ||> |> >>> > ||> |> >>> There are several things that complicate this: > ||> |> >>> > ||> |> >>> - Do we consider the case of a stream that starts with > recvonly > ||> |> >>> or inactive participants, and only later gets a sender? > ||> |> >>> If > ||> |so, > ||> |> >>> is the start time of the stream when the first > ||> |> >>> participant > ||> |> arrived, > ||> |> >>> or when the first sender arrived? > ||> |> >>> > ||> |> >>> - How do we get the clock times for the media streams? > ||> |> >>> IIUC the correct ones are in the RTP/RTCP, but the > ||> reporting > ||> |> of > ||> |> >>> these events is driven by the signaling, and we don't > ||> |> >>> have > ||> |> good > ||> |> >>> sync between those. (E.g. media could start flowing > ||> |> >>> before > ||> |the > ||> |> >>> corresponding signaling, and we would like to include > ||> |> >>> that > ||> if > ||> |> we > ||> |> >>> can figure it out.) So, even if the clocks used for > ||> |> >>> media > ||> and > ||> |> >>> signaling are in sync, we might see media packets arrive > ||> with > ||> |> >>> a timestamp prior to the timestamp for the signaling > that > ||> |> >>> indicates the send state of the participant. This could > ||> cause > ||> |> >>> trouble in playback. > ||> |> >>> > ||> |> >>> - There isn't any guarantee that the clock used for signaling > ||> |> >>> messages is synchronized with the clock used in > RTP/RTCP. > ||> |> >>> > ||> |> >>> - There isn't any guarantee that there will be any RTCP at > all, > ||> |> >>> to provide correlation of the RTP to clocktime. > ||> |> >>> > ||> |> >>> The best I can see to deal with all of this is: > ||> |> >>> > ||> |> >>> - All the metadata messages should be timestamped by the SRC > ||> |> >>> using its local clock. This is easily achieved by the > Date > ||> |> >>> header in the sip message. > ||> |> >>> > ||> |> >>> - Changes to a CS, including changes of participants, should > ||> |> >>> be explicitly tagged with the time they occurred in the > ||> |> >>> CS signaling, according to the SRC's clock. (If that is > ||> |> >>> unavailable for some reason, then use the time the SRC > ||> |> >>> became aware of it.) > ||> |> >>> > ||> |> >>> - We could provide a metadata update element to indicate end > ||> |> >>> of a CS, but I suggest this just be shorthand for > ||> indicating > ||> |> >>> removal of all participants from it. (While its possible > ||to > ||> |> >>> mark that the CS is truly ended, that simply introduces > an > ||> |> >>> error case if added metadata about it is subsequently > ||> sent.) > ||> |> >>> The actual start/stop time would be determined by the > SRS > ||> |> >>> based on the timestamps of first and last data about it. > ||> |> >>> > ||> |> >>> - Changes to media streams should similarly be tagged with > ||> |> >>> the time they occurred in the CS signaling. Each > ||> participant > ||> |> >>> relationship change (send, receive, inactive,) will be > ||> there. > ||> |> >>> The actual start/stop time of the media stream again > ||> |> >>> would > ||> be > ||> |> >>> derived by the SRS. > ||> |> >>> > ||> |> >>> - CS-Groups can simply be tagged by the timestamps of the > ||> |> >>> updates that put CSs into them. Explicit start/stop > ||> |> >>> times > ||> |> don't > ||> |> >>> seem useful. If desired, the SRS can derive start/stop > ||> times > ||> |> >>> from the start/stop times of the contained stuff. > ||> |> >>> > ||> |> >>> - I now think that CS-Groups should not be "contained" within > ||> |> >>> a recording. This just seems to introduce unnecessary > ||error > ||> |> >>> conditions, and limitations on future enhancements. The > ||> |> >>> lifetime of CS-Groups will probably be naturally limited > ||by > ||> |> >>> the ability of the SRC to remember the IDs of old ones. > ||> |> >>> For instance, if a CS-G is created during one Recording, > ||> |> >>> and then another CS is added to it from a different > ||> recording > ||> |> >>> session, would we prefer to fail that, or just allow it? > ||> |> >>> (I think allow.) > ||> |> >>> > ||> |> >>> - Rather, I think every update transmitted during a recording > ||> |> >>> session can be tagged with a link to the metadata of the > ||> |> >>> recording session it came from. This need not be > ||> |> >>> explicit > ||- > ||> |> the > ||> |> >>> SRS can do it automatically. The recording session > entity > ||> |> >>> itself will also have a start/stop time which is the > ||start/ > ||> |> >>> stop of the RS dialog as observed by the SRS. > ||> |> >>> > ||> |> >>> (Note the above doesn't solve the problem of getting correct > ||> clock > ||> |> >>> times for RTP media. If anyone has a suggestion for this I'm > ||all > ||> |> >>> ears.) > ||> |> >>> > ||> |> >>> Thanks, > ||> |> >>> Paul > ||> |> >>> _______________________________________________ > ||> |> >>> siprec mailing 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 > ||> | > ||> | > ||> > |||--------------------------------------------------------------------- > |||- > ||> - > ||> ------------------------------- > ||> |------------- > ||> |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. > ||> | > ||> |_______________________________________________ > ||> |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. > || > ||_______________________________________________ > ||siprec mailing list > ||siprec@ietf.org > ||https://www.ietf.org/mailman/listinfo/siprec > From Internet-Drafts@ietf.org Wed Apr 13 06:00:03 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0756FE0752; Wed, 13 Apr 2011 06:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.647 X-Spam-Level: X-Spam-Status: No, score=-102.647 tagged_above=-999 required=5 tests=[AWL=-0.048, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yXZ+EicOrwLk; Wed, 13 Apr 2011 06:00:02 -0700 (PDT) Received: from ietfc.amsl.com (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4CB3BE0757; Wed, 13 Apr 2011 06:00:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.50 Message-ID: <20110413130002.27780.83317.idtracker@ietfc.amsl.com> Date: Wed, 13 Apr 2011 06:00:02 -0700 Cc: siprec@ietf.org Subject: [siprec] I-D Action:draft-ietf-siprec-metadata-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: Wed, 13 Apr 2011 13:00:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP Recording Working Group of the IETF. Title : Session Initiation Protocol (SIP) Recording Metadata Author(s) : R. R, et al. Filename : draft-ietf-siprec-metadata-00.txt Pages : 23 Date : 2011-04-13 Session recording is a critical requirement in many communications environments such as call centers and financial trading. In some of these environments, all calls must be recorded for regulatory, compliance, and consumer protection reasons. Recording of a session is typically performed by sending a copy of a media stream to a recording device. This document describes the metadata model as viewed by Session Recording Server(SRS). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-siprec-metadata-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-siprec-metadata-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-13055718.I-D@ietf.org> --NextPart-- From rmohanr@cisco.com Wed Apr 13 06:09:18 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 199E5E076B for ; Wed, 13 Apr 2011 06:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.509 X-Spam-Level: X-Spam-Status: No, score=-10.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DWtwonYnLiv8 for ; Wed, 13 Apr 2011 06:09:17 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfc.amsl.com (Postfix) with ESMTP id 2337CE06C6 for ; Wed, 13 Apr 2011 06:09:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=2272; q=dns/txt; s=iport; t=1302700157; x=1303909757; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to:cc; bh=rqlSPVu66eo7JCmTQHKZrmSEwXBv/I7SPz2MBSHEBEs=; b=fThehHW9fMMcD3ivnt+R0mw60KNc8+PRezOE0PjD8gtTGSWiMtGUUd73 v/Dyxv1X1w5nPAqBguQqpP9YC/Lwi3VnTr0965/ISSXMaMyzrXFJmB0EG TxlbZsOvIxMKSx2sLdTRvgjkAw2VrjcWkjlEHW2xwvmbpGgLvM9jHsZyp Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AssBAJqfpU2Q/khR/2dsb2JhbACETZNZP4w2e3emQotQkSuBKYNNeASFWIwG X-IronPort-AV: E=Sophos;i="4.64,204,1301875200"; d="scan'208";a="83407770" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 13 Apr 2011 13:09:06 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3DD7cGm001101 for ; Wed, 13 Apr 2011 13:09:05 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); Wed, 13 Apr 2011 18:38:21 +0530 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, 13 Apr 2011 18:38:19 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD060098B4@XMB-BGL-417.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-ietf-siprec-metadata-00 Thread-Index: Acv52lvGIYs03fatSYyPgYBHHDW75wAAKWwA From: "Ram Mohan R (rmohanr)" To: X-OriginalArrivalTime: 13 Apr 2011 13:08:21.0127 (UTC) FILETIME=[DD027170:01CBF9DB] Subject: [siprec] FW: New Version Notification for draft-ietf-siprec-metadata-00 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 13:09:18 -0000 SGkgYWxsLA0KDQpJIGhhdmUgc3VibWl0dGVkIHZlciAwMCBvZiBkcmFmdC1pZXRmLXNpcHJlYy1t ZXRhZGF0YSBhZnRlciBhZGRyZXNzaW5nIHRoZSBjb21tZW50cyBhZ3JlZWQgdXBvbiBpbiBJRVRG IDgwLiBQbGVhc2Ugc2VlIHRoZSBtYWlsIGhlcmUgZnJvbSBKb2huIA0KZm9yIGRldGFpbHMgLSBo dHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc2lwcmVjL2N1cnJlbnQvbXNnMDE3 MTIuaHRtbA0KDQpQb2ludGVyIHRvIHRoZSBkcmFmdCBpcyBodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1pZXRmLXNpcHJlYy1tZXRhZGF0YS8NCg0KUGxlYXNlIGNvbnRpbnVl IHRoZSBkaXNjdXNzaW9ucyBvbiB0aGUgb3BlbiBpdGVtcyBpbiB0aGUgbW9kZWwgaW4gdGhlIG1h aWxlciBsaXN0LiBJIHdpbGwgYWRkcmVzcyB0aGUgY29tbWVudHMgaW4gdGhlIG5leHQgdmVyc2lv bi4NCg0KUmVnYXJkcywNClJhbQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog SUVURiBJLUQgU3VibWlzc2lvbiBUb29sIFttYWlsdG86aWRzdWJtaXNzaW9uQGlldGYub3JnXSAN ClNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMTMsIDIwMTEgNjoyNyBQTQ0KVG86IFJhbSBNb2hhbiBS IChybW9oYW5yKQ0KQ2M6IFBhcnRoYXNhcmF0aGkgUiAocGFydHIpOyBQYXVsIEt5eml2YXQgKHBr eXppdmF0KQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRm LXNpcHJlYy1tZXRhZGF0YS0wMCANCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaWV0 Zi1zaXByZWMtbWV0YWRhdGEtMDAudHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQg YnkgUmFtIFIgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZToJ IGRyYWZ0LWlldGYtc2lwcmVjLW1ldGFkYXRhDQpSZXZpc2lvbjoJIDAwDQpUaXRsZToJCSBTZXNz aW9uIEluaXRpYXRpb24gUHJvdG9jb2wgKFNJUCkgUmVjb3JkaW5nIE1ldGFkYXRhDQpDcmVhdGlv bl9kYXRlOgkgMjAxMS0wNC0xMw0KV0cgSUQ6CQkgc2lwcmVjDQpOdW1iZXJfb2ZfcGFnZXM6IDIz DQoNCkFic3RyYWN0Og0KU2Vzc2lvbiByZWNvcmRpbmcgaXMgYSBjcml0aWNhbCByZXF1aXJlbWVu dCBpbiBtYW55IGNvbW11bmljYXRpb25zDQplbnZpcm9ubWVudHMgc3VjaCBhcyBjYWxsIGNlbnRl cnMgYW5kIGZpbmFuY2lhbCB0cmFkaW5nLiAgSW4gc29tZSBvZg0KdGhlc2UgZW52aXJvbm1lbnRz LCBhbGwgY2FsbHMgbXVzdCBiZSByZWNvcmRlZCBmb3IgcmVndWxhdG9yeSwNCmNvbXBsaWFuY2Us IGFuZCBjb25zdW1lciBwcm90ZWN0aW9uIHJlYXNvbnMuICBSZWNvcmRpbmcgb2YgYSBzZXNzaW9u DQppcyB0eXBpY2FsbHkgcGVyZm9ybWVkIGJ5IHNlbmRpbmcgYSBjb3B5IG9mIGEgbWVkaWEgc3Ry ZWFtIHRvIGENCnJlY29yZGluZyBkZXZpY2UuICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0aGUg bWV0YWRhdGEgbW9kZWwgYXMNCnZpZXdlZCBieSBTZXNzaW9uIFJlY29yZGluZyBTZXJ2ZXIoU1JT KS4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdC4N Cg0KDQo= From Internet-Drafts@ietf.org Wed Apr 13 07:00:02 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B8C82E066B; Wed, 13 Apr 2011 07:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.644 X-Spam-Level: X-Spam-Status: No, score=-102.644 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHm9O1ayEdyE; Wed, 13 Apr 2011 07:00:02 -0700 (PDT) Received: from ietfc.amsl.com (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id ED9CCE0756; Wed, 13 Apr 2011 07:00:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.50 Message-ID: <20110413140001.12509.2089.idtracker@ietfc.amsl.com> Date: Wed, 13 Apr 2011 07:00:01 -0700 Cc: siprec@ietf.org Subject: [siprec] I-D Action:draft-ietf-siprec-architecture-02.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 14:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP Recording Working Group of the IETF. Title : An Architecture for Media Recording using the Session Initiation Protocol Author(s) : A. Hutton, et al. Filename : draft-ietf-siprec-architecture-02.txt Pages : 16 Date : 2011-04-13 Session recording is a critical requirement in many communications environments such as call centers and financial trading. In some of these environments, all calls must be recorded for regulatory, compliance, and consumer protection reasons. Recording of a session is typically performed by sending a copy of a media stream to a recording device. This document describes architectures for deploying session recording solutions in an environment which is based on the Session Initiation Protocol (SIP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-siprec-architecture-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-siprec-architecture-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-13065431.I-D@ietf.org> --NextPart-- From mperumal@cisco.com Wed Apr 13 23:11:33 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4C4B9E07A3 for ; Wed, 13 Apr 2011 23:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.032 X-Spam-Level: X-Spam-Status: No, score=-10.032 tagged_above=-999 required=5 tests=[AWL=0.567, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGrS52fvWdpd for ; Wed, 13 Apr 2011 23:11:28 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfc.amsl.com (Postfix) with ESMTP id 63A87E081C for ; Wed, 13 Apr 2011 23:11:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=19713; q=dns/txt; s=iport; t=1302761487; x=1303971087; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=fjM4tsVeji2nwI16CqcwZ6+8hk4f6FIUVNZcrrujCvs=; b=kE4W52ywdwLga8lMO5PzpUXec02zqBklIQUzUie29xulsAdAYryQGsF2 nUJdX86Wy7o3dRixcdo7bD2biGP2rk3jLbMd7IenfucJE1qpkn4RKZW2D ksbzv9OSPiNe03jTjOtg6NgWQJi37z1L5YmVwtLFW+z3CAgFuLlgepalI 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al8BAJWPpk2Q/khNgWdsb2JhbACYMY1xFAEBFiYlpB+cc4J+gnAEhViMEQ X-IronPort-AV: E=Sophos;i="4.64,209,1301875200"; d="scan'208";a="83507413" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 14 Apr 2011 06:11:26 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3E6BN5D029401; Thu, 14 Apr 2011 06:11:25 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Apr 2011 11:41:24 +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, 14 Apr 2011 11:41:21 +0530 Message-ID: <1D062974A4845E4D8A343C65380492020533BB4A@XMB-BGL-414.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] start/stop times & the metamodel Thread-Index: Acv4ar9mNRoQAPkwSImkiZlfghuuTgAIWrigAApMiDAAJ/uhEAASQRUgAAJ0TuAABJfvgAAB6y+wAAXBHvAAI4siwA== References: <4D9CDADD.1020403@cisco.com><4DA2FC17.1060100@cisco.com><07465C1D981ABC41A344374066AE1A2C38AB6E1DE4@TLVMBX01.nice.com><4DA334F0.9050301@cisco.com><059AF07365DC474393A19A3AF187DF7406E67CB4@NAHALD.us.int.genesyslab.com><1D062974A4845E4D8A343C65380492020533B45B@XMB-BGL-414.cisco.com><059AF07365DC474393A19A3AF187DF7406EF2378@NAHALD.us.int.genesyslab.com><1D062974A4845E4D8A343C65380492020533B880@XMB-BGL-414.cisco.com> <1D062974A4845E4D8A343C65380492020533B93C@XMB-BGL-414.cisco.com> From: "Muthu ArulMozhi Perumal (mperumal)" To: "Elwell, John" , "Parthasarathi R (partr)" , "Henry Lum" , "Paul Kyzivat (pkyzivat)" , "Leon Portman" X-OriginalArrivalTime: 14 Apr 2011 06:11:24.0758 (UTC) FILETIME=[C8813760:01CBFA6A] Cc: siprec@ietf.org Subject: Re: [siprec] start/stop times & the metamodel X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 14 Apr 2011 06:11:33 -0000 John, The requirements drafts discusses synchronization between the recorded media streams and synchronized playback: Some applications require the recording of more than one media stream, possibly of different types. Media are synchronized, either at storage or at playback. However, it doesn't seem REQ-022 and REQ-023 are all that are need and sufficient to achieve this with the needed precision. So, I am thinking we could add another requirement as follows: The mechanism MUST provide means for facilitating synchronization of the recorded media streams and metadata either at storage or at playback. This includes, but not limited to, the information needed as per REQ-022 and REQ-023. Let me respond to the last call. Muthu |-----Original Message----- |From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] |Sent: Wednesday, April 13, 2011 6:23 PM |To: Muthu ArulMozhi Perumal (mperumal); Parthasarathi R (partr); Henry Lum; Paul Kyzivat (pkyzivat); |Leon Portman |Cc: siprec@ietf.org |Subject: RE: [siprec] start/stop times & the metamodel | |Muthu, | |Please note that IETF last call on draft-ietf-siprec-req-09 ends 2011-04-20. If you don't think the |requirements relating to time (e.g., REQ-022 and REQ-023) are sufficient, please respond to the last |call. | |John (as chair) | |> -----Original Message----- |> From: siprec-bounces@ietf.org |> [mailto:siprec-bounces@ietf.org] On Behalf Of Muthu ArulMozhi |> Perumal (mperumal) |> Sent: 13 April 2011 11:37 |> To: Parthasarathi R (partr); Henry Lum; Paul Kyzivat |> (pkyzivat); Leon Portman |> Cc: siprec@ietf.org |> Subject: Re: [siprec] start/stop times & the metamodel |> |> I don't think the requirements need to go to the level of RTP |> timestamp. |> But it may be useful to add a requirement that the SRC needs to |> facilitate synchronized querying/playback of the recorded |> media streams |> and metadata. I couldn't derive that directly from the requirements we |> already have, but would like to hear from others if this is already |> implied. |> |> Muthu |> |> |-----Original Message----- |> |From: Parthasarathi R (partr) |> |Sent: Wednesday, April 13, 2011 2:46 PM |> |To: Muthu ArulMozhi Perumal (mperumal); 'Henry Lum'; Paul Kyzivat |> (pkyzivat); 'Leon Portman' |> |Cc: 'siprec@ietf.org' |> |Subject: RE: [siprec] start/stop times & the metamodel |> | |> |ISTM, SRC has to act only as RTP Endpoint or RTP Mixer (not RTP |> translator) in case these requirement |> |has to be considered within SIPREC. IMO, these requirement has to be |> mentioned in SIPREC requirement |> |document to define the exact role what SRC does with media timestamp |> and what SRS does with media |> |timestamp? |> | |> |Thanks |> |Partha |> | |> |-----Original Message----- |> |From: Muthu ArulMozhi Perumal (mperumal) |> |Sent: Wednesday, April 13, 2011 12:36 PM |> |To: Parthasarathi R (partr); 'Henry Lum'; Paul Kyzivat (pkyzivat); |> 'Leon Portman' |> |Cc: 'siprec@ietf.org' |> |Subject: RE: [siprec] start/stop times & the metamodel |> | |> |After the use-case Paul described, it seem to me that if we |> keep out of |> scope it will put a lot of |> |burden on the SRS to support synchronized querying/playback |> which looks |> an important aspect for media |> |recording. So, we may want to consider the ways in which the SRC can |> facilitate it. |> | |> |Muthu |> | |> ||-----Original Message----- |> ||From: Parthasarathi R (partr) |> ||Sent: Wednesday, April 13, 2011 11:20 AM |> ||To: Henry Lum; Muthu ArulMozhi Perumal (mperumal); Paul Kyzivat |> ||(pkyzivat); Leon Portman |> ||Cc: siprec@ietf.org |> ||Subject: RE: [siprec] start/stop times & the metamodel |> || |> ||Henry, |> || |> ||I attached the follow up mail to below mail thread. Till |> now, We don't |> ||have strong requirement to solve in SIPREC. Let us identify the |> requirement before going to the |> |solution. |> || |> ||Thanks |> ||Partha |> || |> ||-----Original Message----- |> ||From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On |> ||Behalf Of Henry Lum |> ||Sent: Wednesday, April 13, 2011 2:43 AM |> ||To: Muthu ArulMozhi Perumal (mperumal); Paul Kyzivat |> (pkyzivat); Leon |> ||Portman |> ||Cc: siprec@ietf.org |> ||Subject: Re: [siprec] start/stop times & the metamodel |> || |> ||I don't think it is guaranteed that participants will send |> SR reports |> ||(or any RTCP), plus we will also have to assume that the NTP |> timestamps |> ||are in sync. We could mandate the SRC to generate SR |> reports but then |> we are fixing the RTP model for |> |the SRC. |> || |> ||Regards, |> ||Henry |> || |> ||> -----Original Message----- |> ||> From: Muthu ArulMozhi Perumal (mperumal) |> [mailto:mperumal@cisco.com] |> ||> Sent: Monday, April 11, 2011 10:45 PM |> ||> To: Henry Lum; Paul Kyzivat (pkyzivat); Leon Portman |> ||> Cc: siprec@ietf.org |> ||> Subject: RE: [siprec] start/stop times & the metamodel |> ||> |> ||> While I see it may be useful for the SRS to know when |> certain things |> ||> happened in CS signaling (participant joining, leaving, going mute |> ||etc) |> ||> I don't see how useful it would be for it know how those |> things are |> ||> related to when the participant actually sent/received (or stopped |> ||> sending/receiving) RTP. |> ||> |> ||> If we see any use, one way to do it is using the NTP timestamp |> ||> carried in RTCP SR reports, provided the SRC, SRS and the |> ||> participants have access to the same reference wallclock. |> ||> |> ||> Muthu |> ||> |> ||> |-----Original Message----- |> ||> |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On |> ||> Behalf Of Henry Lum |> ||> |Sent: Tuesday, April 12, 2011 2:56 AM |> ||> |To: Paul Kyzivat (pkyzivat); Leon Portman |> ||> |Cc: siprec@ietf.org |> ||> |Subject: Re: [siprec] start/stop times & the metamodel |> ||> | |> ||> |A related question on the RTP model is that if the SRC as an RTP |> ||> |translator chooses to relay the RTP timestamps, then how |> would the |> ||SRC |> ||> |synchronize the timestamps between the SIP messages the multiple |> RTP |> ||> |streams? |> ||> | |> ||> |Henry |> ||> | |> ||> |> -----Original Message----- |> ||> |> From: siprec-bounces@ietf.org |> [mailto:siprec-bounces@ietf.org] On |> ||> |> Behalf Of Paul Kyzivat |> ||> |> Sent: Monday, April 11, 2011 1:06 PM |> ||> |> To: Leon Portman |> ||> |> Cc: siprec@ietf.org |> ||> |> Subject: Re: [siprec] start/stop times & the metamodel |> ||> |> |> ||> |> |> ||> |> |> ||> |> On 4/11/2011 9:36 AM, Leon Portman wrote: |> ||> |> > Paul Hi |> ||> |> > |> ||> |> > I agree with proposed method of time stamping |> metadata elements |> ||> with |> ||> |> SRC clock (it is like a wall clock from the requirement |> document). |> ||> |> > About RTP time synchronization to metadata events, we either |> ||> should |> ||> |> have some low latency event from SRC to SRS with SRC time that |> ||> |> will allow SRS to maintain time difference between its |> clock and |> ||> |> SRC |> ||> clock |> ||> |> and then apply it also to receive time of RTP packet |> (assuming no |> ||> |> buffering) |> ||> |> |> ||> |> ISTM the issue isn't the latency of the event - it is |> what it is |> - |> ||> but |> ||> |> rather how to correlate a sip message containing |> metadata with a |> ||> |> particular RTP packet. I suspect that needs to be tied into the |> ||> |> discussion of the various models for how the SRC might handle |> RDP. |> ||> |> |> ||> |> Thanks, |> ||> |> Paul |> ||> |> |> ||> |> > Leon |> ||> |> > |> ||> |> > -----Original Message----- |> ||> |> > From: siprec-bounces@ietf.org |> [mailto:siprec-bounces@ietf.org] |> ||> |> > On |> ||> |> Behalf Of Paul Kyzivat |> ||> |> > Sent: Monday, April 11, 2011 4:03 PM |> ||> |> > To: Elwell, John |> ||> |> > Cc: siprec@ietf.org |> ||> |> > Subject: Re: [siprec] start/stop times& the metamodel |> ||> |> > |> ||> |> > |> ||> |> > |> ||> |> > On 4/8/2011 11:53 AM, Elwell, John wrote: |> ||> |> >> Paul, |> ||> |> >> |> ||> |> >> I think much of what you say makes sense. I was |> concerned that |> ||we |> ||> |> probably need to record when a participant stops or starts |> sending |> ||> or |> ||> |> receiving a stream, which seems to be covered by your |> statement: |> ||> |> "Changes to media streams should similarly be tagged with the |> time |> ||> |they |> ||> |> occurred in the CS signaling. Each participant relationship |> change |> ||> |> (send, receive, inactive,) will be there." That doesn't seem to |> be |> ||> in |> ||> |> the model at present. |> ||> |> > |> ||> |> > John, |> ||> |> > |> ||> |> > I agree the current model doesn't reflect this - it was a |> ||> |> > private |> ||> |> thought by me, provoked by the work and discussion to |> date. It is |> ||> |> a |> ||> |bit |> ||> |> of a change of direction, so I'm interested in what |> others think |> ||> about |> ||> |> it. |> ||> |> > |> ||> |> > Thanks, |> ||> |> > Paul |> ||> |> > |> ||> |> >> John (as individual) |> ||> |> >> |> ||> |> >> |> ||> |> >>> -----Original Message----- |> ||> |> >>> From: siprec-bounces@ietf.org |> ||> |> >>> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat |> ||> |> >>> Sent: 06 April 2011 22:28 |> ||> |> >>> To: siprec@ietf.org |> ||> |> >>> Subject: [siprec] start/stop times& the metamodel |> ||> |> >>> |> ||> |> >>> In Prague, one of the open issues was around start/stop |> times. |> ||> The |> ||> |> >>> format draft floated the possibility of having explicit |> ||> start/stop |> ||> |> >>> times signaled for each of the metatdata elements. But then |> we |> ||> |> asked |> ||> |> >>> for feedback on which make sense. |> ||> |> >>> |> ||> |> >>> IMO explicit start/stop times make more sense for |> some things |> ||> than |> ||> |> >>> others. |> ||> |> >>> |> ||> |> >>> One place where we potentially have explicit times |> to report |> ||> with |> ||> |> the |> ||> |> >>> dialogs that constitute a CS. Each such dialog |> presumably has |> ||> |> >>> a |> ||> |> start |> ||> |> >>> and stop time observable by the SRC, which might differ, at |> ||> least |> ||> |a |> ||> |> >>> bit, from the corresponding signaling on the RS. |> ||> |> >>> |> ||> |> >>> We might want to report those times. Or, since we abstract |> the |> ||> CS |> ||> |> >>> away from the dialog, we might want to report the |> start time |> ||> |> >>> of |> ||> |the |> ||> |> >>> first dialog in the CS as the CS start time, and the stop |> time |> ||> of |> ||> |> the |> ||> |> >>> last dialog in the CS as the CS stop time. |> ||> |> >>> |> ||> |> >>> Similarly, we have abstracted media streams away from the |> ||> |> >>> media streams in the sip dialogs that make up the CS. We |> might |> ||> |> >>> want |> ||to |> ||> |> >>> report the start time of a media stream as the time |> (according |> ||> to |> ||> |> the |> ||> |> >>> CS) of the first participant to a new media stream, and the |> ||stop |> ||> |> time |> ||> |> >>> as the time that the last participant leaves the media |> stream. |> ||> |> >>> |> ||> |> >>> There are several things that complicate this: |> ||> |> >>> |> ||> |> >>> - Do we consider the case of a stream that starts with |> recvonly |> ||> |> >>> or inactive participants, and only later gets |> a sender? |> ||> |> >>> If |> ||> |so, |> ||> |> >>> is the start time of the stream when the first |> ||> |> >>> participant |> ||> |> arrived, |> ||> |> >>> or when the first sender arrived? |> ||> |> >>> |> ||> |> >>> - How do we get the clock times for the media streams? |> ||> |> >>> IIUC the correct ones are in the RTP/RTCP, but the |> ||> reporting |> ||> |> of |> ||> |> >>> these events is driven by the signaling, and we don't |> ||> |> >>> have |> ||> |> good |> ||> |> >>> sync between those. (E.g. media could start flowing |> ||> |> >>> before |> ||> |the |> ||> |> >>> corresponding signaling, and we would like to include |> ||> |> >>> that |> ||> if |> ||> |> we |> ||> |> >>> can figure it out.) So, even if the clocks used for |> media |> ||> and |> ||> |> >>> signaling are in sync, we might see media |> packets arrive |> ||> with |> ||> |> >>> a timestamp prior to the timestamp for the signaling |> that |> ||> |> >>> indicates the send state of the participant. |> This could |> ||> cause |> ||> |> >>> trouble in playback. |> ||> |> >>> |> ||> |> >>> - There isn't any guarantee that the clock used |> for signaling |> ||> |> >>> messages is synchronized with the clock used in |> RTP/RTCP. |> ||> |> >>> |> ||> |> >>> - There isn't any guarantee that there will be any RTCP at |> all, |> ||> |> >>> to provide correlation of the RTP to clocktime. |> ||> |> >>> |> ||> |> >>> The best I can see to deal with all of this is: |> ||> |> >>> |> ||> |> >>> - All the metadata messages should be timestamped |> by the SRC |> ||> |> >>> using its local clock. This is easily achieved by the |> Date |> ||> |> >>> header in the sip message. |> ||> |> >>> |> ||> |> >>> - Changes to a CS, including changes of |> participants, should |> ||> |> >>> be explicitly tagged with the time they |> occurred in the |> ||> |> >>> CS signaling, according to the SRC's clock. |> (If that is |> ||> |> >>> unavailable for some reason, then use the time the SRC |> ||> |> >>> became aware of it.) |> ||> |> >>> |> ||> |> >>> - We could provide a metadata update element to |> indicate end |> ||> |> >>> of a CS, but I suggest this just be shorthand for |> ||> indicating |> ||> |> >>> removal of all participants from it. (While |> its possible |> ||to |> ||> |> >>> mark that the CS is truly ended, that simply |> introduces |> an |> ||> |> >>> error case if added metadata about it is subsequently |> ||> sent.) |> ||> |> >>> The actual start/stop time would be determined by the |> SRS |> ||> |> >>> based on the timestamps of first and last |> data about it. |> ||> |> >>> |> ||> |> >>> - Changes to media streams should similarly be tagged with |> ||> |> >>> the time they occurred in the CS signaling. Each |> ||> participant |> ||> |> >>> relationship change (send, receive, inactive,) will be |> ||> there. |> ||> |> >>> The actual start/stop time of the media stream again |> ||> |> >>> would |> ||> be |> ||> |> >>> derived by the SRS. |> ||> |> >>> |> ||> |> >>> - CS-Groups can simply be tagged by the timestamps of the |> ||> |> >>> updates that put CSs into them. Explicit start/stop |> times |> ||> |> don't |> ||> |> >>> seem useful. If desired, the SRS can derive start/stop |> ||> times |> ||> |> >>> from the start/stop times of the contained stuff. |> ||> |> >>> |> ||> |> >>> - I now think that CS-Groups should not be |> "contained" within |> ||> |> >>> a recording. This just seems to introduce unnecessary |> ||error |> ||> |> >>> conditions, and limitations on future |> enhancements. The |> ||> |> >>> lifetime of CS-Groups will probably be |> naturally limited |> ||by |> ||> |> >>> the ability of the SRC to remember the IDs of |> old ones. |> ||> |> >>> For instance, if a CS-G is created during one |> Recording, |> ||> |> >>> and then another CS is added to it from a different |> ||> recording |> ||> |> >>> session, would we prefer to fail that, or |> just allow it? |> ||> |> >>> (I think allow.) |> ||> |> >>> |> ||> |> >>> - Rather, I think every update transmitted during |> a recording |> ||> |> >>> session can be tagged with a link to the |> metadata of the |> ||> |> >>> recording session it came from. This need not be |> explicit |> ||- |> ||> |> the |> ||> |> >>> SRS can do it automatically. The recording session |> entity |> ||> |> >>> itself will also have a start/stop time which is the |> ||start/ |> ||> |> >>> stop of the RS dialog as observed by the SRS. |> ||> |> >>> |> ||> |> >>> (Note the above doesn't solve the problem of |> getting correct |> ||> clock |> ||> |> >>> times for RTP media. If anyone has a suggestion |> for this I'm |> ||all |> ||> |> >>> ears.) |> ||> |> >>> |> ||> |> >>> Thanks, |> ||> |> >>> Paul |> ||> |> >>> _______________________________________________ |> ||> |> >>> siprec mailing 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 |> ||> | |> ||> | |> ||> |> |||----------------------------------------------------------- |> ---------- |> - |> ||> - |> ||> ------------------------------- |> ||> |------------- |> ||> |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. |> ||> | |> ||> |_______________________________________________ |> ||> |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. |> || |> ||_______________________________________________ |> ||siprec mailing 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 mperumal@cisco.com Wed Apr 13 23:34:29 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 79DD0E0687; Wed, 13 Apr 2011 23:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.068 X-Spam-Level: X-Spam-Status: No, score=-10.068 tagged_above=-999 required=5 tests=[AWL=0.531, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBD78QsooeIz; Wed, 13 Apr 2011 23:34:28 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfc.amsl.com (Postfix) with ESMTP id 482E4E0670; Wed, 13 Apr 2011 23:34:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=2375; q=dns/txt; s=iport; t=1302762868; x=1303972468; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=nYGt6pXqQhgnqBoSSIhO6ygEYDPvYQJ3kuEAVQ2jlXc=; b=FG68sgfzFHG+Tyr4enz3iel3b+J4CyZ64/bDvPdMTYImre7rwdbEAr5P Ap3Xpb183eUVdWP5TNdACqKT1DVI3mbvXSC/zts0YdJmXERGwnVoRqqH3 EjsQjmeNR+C1+lPsOb6hendZNVVrIHoneLMMBqZdAfq74vgV1HdN2MpZs Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqMCADmVpk2Q/khMgWdsb2JhbACYMj+NMhQBARYmJaQNnHSFbgSFWIwR X-IronPort-AV: E=Sophos;i="4.64,209,1301875200"; d="scan'208";a="25647458" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 14 Apr 2011 06:34:10 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3E6XL4D029502; Thu, 14 Apr 2011 06:34:10 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Apr 2011 12:03:27 +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, 14 Apr 2011 12:03:31 +0530 Message-ID: <1D062974A4845E4D8A343C65380492020533BB70@XMB-BGL-414.cisco.com> In-Reply-To: <20110406125020.17538.70016.idtracker@localhost> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Last Call: (Use Cases andRequirements for SIP-based Media Recording (SIPREC)) toInformational RFC Thread-Index: Acv0WYBeRuGjGNBtTZSHeqn78QP5xwGEv6Yw References: <20110406125020.17538.70016.idtracker@localhost> From: "Muthu ArulMozhi Perumal (mperumal)" To: X-OriginalArrivalTime: 14 Apr 2011 06:33:27.0782 (UTC) FILETIME=[DD16A860:01CBFA6D] Cc: siprec@ietf.org Subject: Re: [siprec] Last Call: (Use Cases andRequirements for SIP-based Media Recording (SIPREC)) toInformational RFC X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 14 Apr 2011 06:34:29 -0000 I've one major comment. It draft discusses synchronization between the recorded media streams and synchronized playback, which seem important for certain applications: Some applications require the recording of more than one media stream, possibly of different types. Media are synchronized, either at storage or at playback. However, in the requirements section it doesn't seem REQ-022 and REQ-023 are all that are need and sufficient to achieve this with needed precision. So, I would suggest adding another requirement as follows: The mechanism MUST provide means for facilitating synchronization of the recorded media streams and metadata either at storage or at playback. This includes, but not limited to, the information needed as per REQ-022 and REQ-023. A nitpick: Use Case 8 In cases where calls inside or between branches must be recorded, a centralized recording system in data centers together with telephony infrastructure (e.g. PBX) me deployed. s/me/may be Muthu |-----Original Message----- |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of The IESG |Sent: Wednesday, April 06, 2011 6:20 PM |To: IETF-Announce |Cc: siprec@ietf.org |Subject: [siprec] Last Call: (Use Cases andRequirements for SIP-based |Media Recording (SIPREC)) toInformational RFC | | |The IESG has received a request from the SIP Recording WG (siprec) to |consider the following document: |- 'Use Cases and Requirements for SIP-based Media Recording (SIPREC)' | as an Informational RFC | |The IESG plans to make a decision in the next few weeks, and solicits |final comments on this action. Please send substantive comments to the |ietf@ietf.org mailing lists by 2011-04-20. Exceptionally, comments may be |sent to iesg@ietf.org instead. In either case, please retain the |beginning of the Subject line to allow automated sorting. | |The file can be obtained via |http://datatracker.ietf.org/doc/draft-ietf-siprec-req/ | |IESG discussion can be tracked via |http://datatracker.ietf.org/doc/draft-ietf-siprec-req/ | | | |No IPR declarations have been submitted directly on this I-D. |_______________________________________________ |siprec mailing list |siprec@ietf.org |https://www.ietf.org/mailman/listinfo/siprec From john.elwell@siemens-enterprise.com Wed Apr 13 23:57:15 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7DCD8E0670 for ; Wed, 13 Apr 2011 23:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.804 X-Spam-Level: X-Spam-Status: No, score=-104.804 tagged_above=-999 required=5 tests=[AWL=1.795, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3j6SpJyZJezK for ; Wed, 13 Apr 2011 23:57:15 -0700 (PDT) Received: from mail174.messagelabs.com (mail174.messagelabs.com [85.158.138.51]) by ietfc.amsl.com (Postfix) with SMTP id A85A3E0687 for ; Wed, 13 Apr 2011 23:57:14 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1302764233!17015260!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 31287 invoked from network); 14 Apr 2011 06:57:13 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-13.tower-174.messagelabs.com with SMTP; 14 Apr 2011 06:57:13 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 93E7523F03DB for ; Thu, 14 Apr 2011 08:57:13 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 14 Apr 2011 08:57:13 +0200 From: "Elwell, John" To: "siprec@ietf.org" Date: Thu, 14 Apr 2011 08:57:11 +0200 Thread-Topic: SIPREC interim virtual meeting 2011-05-09, 14.00-16.00 GMT Thread-Index: Acv6cS2ahAKB1lVdSs+jVXZ1BHJYFQ== 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] SIPREC interim virtual meeting 2011-05-09, 14.00-16.00 GMT X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 14 Apr 2011 06:57:15 -0000 I have now closed the Doodle poll, and it seems the above date/time is the = best fit. (starting 15.00 London, 10.00 Boston, 07.00 San Francisco...). The agenda will be posted later but will doubtless include Architecture, Me= tadata Model and Format, and Protocol. John From yuepeiyu@huawei.com Thu Apr 14 02:27:16 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BFD99E0676 for ; Thu, 14 Apr 2011 02:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.855 X-Spam-Level: X-Spam-Status: No, score=-99.855 tagged_above=-999 required=5 tests=[AWL=1.055, BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_21=0.6, MANGLED_VIDEO=2.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDfciVe4KI65 for ; Thu, 14 Apr 2011 02:27:15 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfc.amsl.com (Postfix) with ESMTP id 2C878E0669 for ; Thu, 14 Apr 2011 02:27:15 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJM00MVJY9DRU@szxga04-in.huawei.com> for siprec@ietf.org; Thu, 14 Apr 2011 17:27:14 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJM005BNY9DA5@szxga04-in.huawei.com> for siprec@ietf.org; Thu, 14 Apr 2011 17:27:13 +0800 (CST) Received: from Y58865A ([10.138.73.89]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LJM005SCY99TW@szxml06-in.huawei.com> for siprec@ietf.org; Thu, 14 Apr 2011 17:27:13 +0800 (CST) Date: Thu, 14 Apr 2011 17:27:09 +0800 From: Roy In-reply-to: <101C6067BEC68246B0C3F6843BCCC1E30B6D639EEE@MCHP058A.global-ad.net> To: "'Hutton, Andrew'" , "'Elwell, John'" , siprec@ietf.org Message-id: <01ca01cbfa86$21050590$630f10b0$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=gb2312 Content-language: zh-cn Content-transfer-encoding: quoted-printable Thread-index: Acv42ubXHfPE7b2ZSIutkk8YPChNPgABXVYQAAUKXIAAIklWQAARANqgAC9Rt+A= References: <007b01cbf8da$e72ff570$b58fe050$@com> <101C6067BEC68246B0C3F6843BCCC1E30B6D5C888D@MCHP058A.global-ad.net> <00d201cbf97f$d2e22570$78a67050$@com> <101C6067BEC68246B0C3F6843BCCC1E30B6D639EEE@MCHP058A.global-ad.net> Subject: Re: [siprec] Question on the scope X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 14 Apr 2011 09:27:16 -0000 Hi Andy, SIP MESSAGE (from UA-A to the B2BUA) is used to convey the request, the request-URI tells this is a NPVR request, while in the SIP body, an XML document tells the program to be recorded, as well as time period, etc SIP INVITE (from B2BUA to recording server) is used to initiate the = media session between media server and recording server. We(I as one of the contributors) defined this due to lake of other standardized way. Similar mechanisms are used in the following specifications: ETSI TS 183063 v3.4.5,=20 3GPP TS 26.237 v10.1.0,=20 OIPF R2 Volume 4 - Protocol After reading the ARCH and REQ document more, I realize that the NPVR = case can be divided into two sub cases: sub case 1: A user is watching a program (initiated by a SIP session), and at meaning time want to record the program for any reason. Then this is in scope of SIPREC. Note: The abovementioned specifications take the watching and recording as two separated procedure. Sub case 2: A user want to record a future program or a program which is not what he is watching.=20 This case is out scope of SIPREC. But if we relax our restrictions a little bit, this case can also be covered easily. What do you think? Best regards, Roy -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: Hutton, Andrew = [mailto:andrew.hutton@siemens-enterprise.com]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA4=D4=C213=C8=D5 18:04 =CA=D5=BC=FE=C8=CB: Roy; Elwell, John; siprec@ietf.org =D6=F7=CC=E2: RE: [siprec] Question on the scope Hi Roy, So what protocol is used to tell the B2BUA what is to be recorded is = this something that is conveyed in a SIP body or something else and is it standardized ? It sounds like this is not within scope of the IETF SIPREC group but I = would like to understand the mechanism used. Regards Andy > -----Original Message----- > From: Roy [mailto:yuepeiyu@huawei.com]=20 > Sent: 13 April 2011 03:09 > To: Hutton, Andrew; Elwell, John; siprec@ietf.org > Subject: Re: [siprec] Question on the scope >=20 > Hi Andy, >=20 > The session between UA-A and the Media Server does not convey=20 > any media. > This SIP session mainly tells the B2BUA what to be recorded. >=20 > As background, to watch a IPTV program, the UA-A initiates a=20 > SIP session to > setup a media session between UA-A and Media Server. The=20 > media session could > be a unicast or multicast session. > While in the NPVR case, the user (with UA-A) may not be able=20 > to watch the > live program, and want to record and watch the program at a=20 > later time.=20 > Therefore, when initiates the recording session, the UA-A=20 > will only tells > what to record, without any media conveying.=20 >=20 > Hope this clarifies! >=20 > Best regards, > Roy >=20 > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: Hutton, Andrew = [mailto:andrew.hutton@siemens-enterprise.com]=20 > =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA4=D4=C212=C8=D5 17:37 > =CA=D5=BC=FE=C8=CB: Elwell, John; Roy; siprec@ietf.org > =D6=F7=CC=E2: RE: [siprec] Question on the scope >=20 > Hi Roy, >=20 > Your diagram shows a SIP session from UA-A to the B2BUA and=20 > between the > B2BUA and the Media Server. I assume this is logically a=20 > session between the > UA-A and the Media Server with the B2BUA in the middle.=20 >=20 > Does this session convey any media between UA-A and the Media=20 > Server and if > so what is the relationship between this and the media sent=20 > to the recording > server? >=20 > What is the SIP Session used for at UA-A? >=20 > Regards > Andy >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org=20 > > [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > > Sent: 12 April 2011 08:14 > > To: Roy; siprec@ietf.org > > Subject: Re: [siprec] Question on the scope > >=20 > > Roy, > >=20 > > I am not sure I understand your use case correctly, but it=20 > > seems some content from inside a media server is being=20 > > recorded, as opposed to recording content that is transported=20 > > between two or more users as part of a communication session.=20 > > I believe that is outside the scope of the working group. See=20 > > the charter and draft-ietf-siprec-req (requirements). Our=20 > > work is concerned with recording a session, so content that=20 > > is held internally to a media server, as opposed to being=20 > > transported as part of a session is out of scope. > >=20 > > John > >=20 > > > -----Original Message----- > > > From: siprec-bounces@ietf.org=20 > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Roy > > > Sent: 12 April 2011 07:29 > > > To: siprec@ietf.org > > > Subject: [siprec] Question on the scope > > >=20 > > > Hello > > >=20 > > > =20 > > >=20 > > > I find this work group during Prague meeting. The work here=20 > > > is quite interesting although I have some questions as below: > > >=20 > > > =20 > > >=20 > > > All through the architecture and requirement document, we are=20 > > > talking about recording a media session between two UA.=20 > > >=20 > > > However, there is also use cases that a UA1 requests a=20 > > > recording server (SRS) to record a media content in media=20 > > > server (UA2) while there is not any direct media session=20 > > > between UA1 and media server. Following is a general architecture. > > >=20 > > > +-----------+ > > >=20 > > > (Recording Session) | | > > >=20 > > > ; +----- ding | > > >=20 > > > | | Server | > > >=20 > > > | +---MetaData---->| | > > >=20 > > > &n | +-----------+ > > >=20 > > > | | ^ > > >=20 > > > | | | > > >=20 > > > &n sp; | | RTP > > >=20 > > > V V unicast or multicast > > >=20 > > > +------------------+ | > > >=20 > > > nbsp; | B2BUA | | > > >=20 > > > +--------+ | Service Control | +---------+ > > >=20 > > > | |<- SIP ->| Function |<- SIP ->| | > > >=20 > > > | UA-A | +--------- -------- ; | Media | > > >=20 > > > | | | Server | > > >=20 > > > +--------+ +---------+ > > >=20 > > > =20 > > >=20 > > > This case is very common in IPTV industry, known as Network=20 > > > Personal Vide o Record ery similar with the work here. > > >=20 > > > Does current document cover this use case already or did you=20 > > > discussed similar case ever? > > >=20 > > > =20 > > >=20 > > > Many thanks and best regards, > > >=20 > > > Roy > > >=20 > > >=20 > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > >=20 >=20 >=20 >=20 From john.elwell@siemens-enterprise.com Thu Apr 14 02:57:54 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DC8FEE06A9 for ; Thu, 14 Apr 2011 02:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.122 X-Spam-Level: X-Spam-Status: No, score=-101.122 tagged_above=-999 required=5 tests=[AWL=-1.965, BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_21=0.6, MANGLED_VIDEO=2.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yUwGODUfsuqF for ; Thu, 14 Apr 2011 02:57:53 -0700 (PDT) Received: from mail174.messagelabs.com (mail174.messagelabs.com [85.158.138.51]) by ietfc.amsl.com (Postfix) with SMTP id 42E88E06A0 for ; Thu, 14 Apr 2011 02:57:53 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-4.tower-174.messagelabs.com!1302775072!17042321!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 21350 invoked from network); 14 Apr 2011 09:57:52 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-4.tower-174.messagelabs.com with SMTP; 14 Apr 2011 09:57:52 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 110611EB83ED; Thu, 14 Apr 2011 11:57:52 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 14 Apr 2011 11:57:52 +0200 From: "Elwell, John" To: Roy , "Hutton, Andrew" , "siprec@ietf.org" Date: Thu, 14 Apr 2011 11:57:50 +0200 Thread-Topic: [siprec] Question on the scope Thread-Index: Acv42ubXHfPE7b2ZSIutkk8YPChNPgABXVYQAAUKXIAAIklWQAARANqgAC9Rt+AAAk6BQA== Message-ID: References: <007b01cbf8da$e72ff570$b58fe050$@com> <101C6067BEC68246B0C3F6843BCCC1E30B6D5C888D@MCHP058A.global-ad.net> <00d201cbf97f$d2e22570$78a67050$@com> <101C6067BEC68246B0C3F6843BCCC1E30B6D639EEE@MCHP058A.global-ad.net> <01ca01cbfa86$21050590$630f10b0$@com> In-Reply-To: <01ca01cbfa86$21050590$630f10b0$@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="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [siprec] Question on the scope X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 14 Apr 2011 09:57:55 -0000 Um95LA0KDQpUaGUgc2NvcGUgb2YgU0lQUkVDIGlzIHRvIHJlY29yZCBhIGNvbW11bmljYXRpb24g c2Vzc2lvbiBiZXR3ZWVuIGEgbnVtYmVyIG9mIHBhcnRpZXMuIFRoZSBzaW1wbGVzdCBjYXNlIGlz IGJldHdlZW4gdHdvIHBhcnRpZXMsIEEgYW5kIEIsIGFuZCBtZWRpYSB0aGF0IGZsb3dzIGJldHdl ZW4gQSBhbmQgQiBpcyBjYXB0dXJlZCBieSB0aGUgU1JDIGFuZCBwYXNzZWQgdG8gdGhlIFNSUy4N Cg0KWW91IGlkZW50aWZ5IHR3byBzdWItY2FzZXM6IChhKSB3YXRjaGluZyAoYW5kIHNpbXVsdGFu ZW91c2x5IHJlY29yZGluZykgYW5kIChiKSByZWNvcmRpbmcgb25seSAoZm9yIGZ1dHVyZSBwbGF5 YmFjaykuDQoNCkZvciBjYXNlIChhKSwgSSBhc3N1bWUgdGhlIG1lZGlhIChUViBhdWRpbyBhbmQg dmlkZW8pIGZsb3cgZnJvbSBCICh0aGUgbWVkaWEgc2VydmVyKSB0byBBLCBzbyBhbnkgZW50aXR5 IHRoYXQgaGFzIGFjY2VzcyB0byB0aGF0IG1lZGlhIChlLmcuLCB0aGUgQjJCVUEpIGNhbiBhY3Qg YXMgYW4gU1JDIGFuZCBzZW5kIHRoZSBtZWRpYSBzaW11bHRhbmVvdXNseSB0byB0aGUgU1JTLiBU aGlzIGlzIG5vcm1hbCBTSVBSRUMuIE1lZGlhIHNlbnQgdG8gdGhlIFNSUyBpcyBhIGNvcHkgb2Yg bWVkaWEgZXhjaGFuZ2VkIGJldHdlZW4gQiBhbmQgQS4NCg0KRm9yIGNhc2UgKGIpLCBpdCBzZWVt cyBtZWRpYSBpcyBzZW50IG9ubHkgZnJvbSBCIHRvIHRoZSByZWNvcmRpbmcgc2VydmVyLCBhbmQg bm90IHNpbXVsdGFuZW91c2x5IHRvIEEgLSBjb3JyZWN0PyBTbyBpdCBzZWVtcyB0aGF0IHRoZSBy ZWNvcmRpbmcgZGV2aWNlIGlzIGEgbWVkaWEgZGV2aWNlIGFjdGluZyBvbiBiZWhhbGYgb2YgQSBm b3IgdGhhdCBjb21tdW5pY2F0aW9uIHNlc3Npb24uIFRoZXJlIGFyZSB2YXJpb3VzIGFwcHJvYWNo ZXMgcG9zc2libGUgZm9yIGVzdGFibGlzaGluZyB0aGF0IGNvbW11bmljYXRpb24gc2Vzc2lvbiwg ZS5nLiwgQSdzIFNEUCBmb3IgdGhlIHZpZGVvIG1lZGl1bSBjb3VsZCBjb250YWluIHRoZSBJUCBh ZGRyZXNzL3BvcnQgb2YgdGhlIHJlY29yZGluZyBkZXZpY2UuIFRoaXMgaXMgYWxsIGEgbWF0dGVy IG9mIGhvdyB0aGUgY29tbXVuaWNhdGlvbiBzZXNzaW9uIGlzIGVzdGFibGlzaGVkLCBhbmQgdGhh dCBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiBTSVBSRUMuIFNpbmNlIHdlIGFyZSBub3QgY29weWlu ZyBtZWRpYSBleGNoYW5nZWQgZHVyaW5nIGEgY29tbXVuaWNhdGlvbiBzZXNzaW9uIHRvIGFuIFNS UywgaXQgcmVhbGx5IGRvZXMgc2VlbSB0byBiZSBvdXRzaWRlIHRoZSBzY29wZSBvZiBTSVBSRUMu DQoNCk9mIGNvdXJzZSwgSSBtYXkgaGF2ZSBtaXN1bmRlcnN0b29kIHlvdXIgcmVxdWlyZW1lbnQu DQoNCkpvaG4NCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFJveSBb bWFpbHRvOnl1ZXBlaXl1QGh1YXdlaS5jb21dIA0KPiBTZW50OiAxNCBBcHJpbCAyMDExIDEwOjI3 DQo+IFRvOiBIdXR0b24sIEFuZHJldzsgRWx3ZWxsLCBKb2huOyBzaXByZWNAaWV0Zi5vcmcNCj4g U3ViamVjdDogUmU6IFtzaXByZWNdIFF1ZXN0aW9uIG9uIHRoZSBzY29wZQ0KPiANCj4gSGkgQW5k eSwNCj4gDQo+IFNJUCBNRVNTQUdFIChmcm9tIFVBLUEgdG8gdGhlIEIyQlVBKSBpcyB1c2VkIHRv IGNvbnZleSB0aGUgDQo+IHJlcXVlc3QsIHRoZQ0KPiByZXF1ZXN0LVVSSSB0ZWxscyB0aGlzIGlz IGEgTlBWUiByZXF1ZXN0LCB3aGlsZSBpbiB0aGUgU0lQIA0KPiBib2R5LCBhbiBYTUwNCj4gZG9j dW1lbnQgdGVsbHMgdGhlIHByb2dyYW0gdG8gYmUgcmVjb3JkZWQsIGFzIHdlbGwgYXMgdGltZSBw ZXJpb2QsIGV0Yw0KPiBTSVAgSU5WSVRFIChmcm9tIEIyQlVBIHRvIHJlY29yZGluZyBzZXJ2ZXIp IGlzIHVzZWQgdG8gDQo+IGluaXRpYXRlIHRoZSBtZWRpYQ0KPiBzZXNzaW9uIGJldHdlZW4gbWVk aWEgc2VydmVyIGFuZCByZWNvcmRpbmcgc2VydmVyLg0KPiBXZShJIGFzIG9uZSBvZiB0aGUgY29u dHJpYnV0b3JzKSBkZWZpbmVkIHRoaXMgZHVlIHRvIGxha2Ugb2Ygb3RoZXINCj4gc3RhbmRhcmRp emVkIHdheS4NCj4gU2ltaWxhciBtZWNoYW5pc21zIGFyZSB1c2VkIGluIHRoZSBmb2xsb3dpbmcg c3BlY2lmaWNhdGlvbnM6DQo+IAlFVFNJIFRTIDE4MzA2MyB2My40LjUsIA0KPiAJM0dQUCBUUyAy Ni4yMzcgdjEwLjEuMCwgDQo+IAlPSVBGIFIyIFZvbHVtZSA0IC0gUHJvdG9jb2wNCj4gDQo+IEFm dGVyIHJlYWRpbmcgdGhlIEFSQ0ggYW5kIFJFUSBkb2N1bWVudCBtb3JlLCBJIHJlYWxpemUgdGhh dCANCj4gdGhlIE5QVlIgY2FzZQ0KPiBjYW4gYmUgZGl2aWRlZCBpbnRvIHR3byBzdWIgY2FzZXM6 DQo+IHN1YiBjYXNlIDE6DQo+IAlBIHVzZXIgaXMgd2F0Y2hpbmcgYSBwcm9ncmFtIChpbml0aWF0 ZWQgYnkgYSBTSVAgDQo+IHNlc3Npb24pLCBhbmQgYXQNCj4gbWVhbmluZyB0aW1lIHdhbnQgdG8g cmVjb3JkIHRoZSBwcm9ncmFtIGZvciBhbnkgcmVhc29uLiBUaGVuIA0KPiB0aGlzIGlzIGluDQo+ IHNjb3BlIG9mIFNJUFJFQy4NCj4gCU5vdGU6IFRoZSBhYm92ZW1lbnRpb25lZCBzcGVjaWZpY2F0 aW9ucyB0YWtlIHRoZSB3YXRjaGluZyBhbmQNCj4gcmVjb3JkaW5nIGFzIHR3byBzZXBhcmF0ZWQg cHJvY2VkdXJlLg0KPiBTdWIgY2FzZSAyOg0KPiAJQSB1c2VyIHdhbnQgdG8gcmVjb3JkIGEgZnV0 dXJlIHByb2dyYW0gb3IgYSBwcm9ncmFtIHdoaWNoIGlzIG5vdA0KPiB3aGF0IGhlIGlzIHdhdGNo aW5nLiANCj4gCVRoaXMgY2FzZSBpcyBvdXQgc2NvcGUgb2YgU0lQUkVDLiBCdXQgaWYgd2UgcmVs YXggb3VyIA0KPiByZXN0cmljdGlvbnMgYQ0KPiBsaXR0bGUgYml0LCB0aGlzIGNhc2UgY2FuIGFs c28gYmUgY292ZXJlZCBlYXNpbHkuDQo+IA0KPiBXaGF0IGRvIHlvdSB0aGluaz8NCj4gDQo+IEJl c3QgcmVnYXJkcywgUm95DQo+IA0KPiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4gt6K8/sjLOiBIdXR0 b24sIEFuZHJldyBbbWFpbHRvOmFuZHJldy5odXR0b25Ac2llbWVucy1lbnRlcnByaXNlLmNvbV0g DQo+ILeiy83KsbzkOiAyMDExxOo01MIxM8jVIDE4OjA0DQo+IMrVvP7IyzogUm95OyBFbHdlbGws IEpvaG47IHNpcHJlY0BpZXRmLm9yZw0KPiDW98ziOiBSRTogW3NpcHJlY10gUXVlc3Rpb24gb24g dGhlIHNjb3BlDQo+IA0KPiBIaSBSb3ksDQo+IA0KPiBTbyB3aGF0IHByb3RvY29sIGlzIHVzZWQg dG8gdGVsbCB0aGUgQjJCVUEgd2hhdCBpcyB0byBiZSANCj4gcmVjb3JkZWQgaXMgdGhpcw0KPiBz b21ldGhpbmcgdGhhdCBpcyBjb252ZXllZCBpbiBhIFNJUCBib2R5IG9yIHNvbWV0aGluZyBlbHNl IGFuZCBpcyBpdA0KPiBzdGFuZGFyZGl6ZWQgPw0KPiANCj4gSXQgc291bmRzIGxpa2UgdGhpcyBp cyBub3Qgd2l0aGluIHNjb3BlIG9mIHRoZSBJRVRGIFNJUFJFQyANCj4gZ3JvdXAgYnV0IEkgd291 bGQNCj4gbGlrZSB0byB1bmRlcnN0YW5kIHRoZSBtZWNoYW5pc20gdXNlZC4NCj4gDQo+IFJlZ2Fy ZHMNCj4gQW5keQ0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206 IFJveSBbbWFpbHRvOnl1ZXBlaXl1QGh1YXdlaS5jb21dIA0KPiA+IFNlbnQ6IDEzIEFwcmlsIDIw MTEgMDM6MDkNCj4gPiBUbzogSHV0dG9uLCBBbmRyZXc7IEVsd2VsbCwgSm9objsgc2lwcmVjQGll dGYub3JnDQo+ID4gU3ViamVjdDogUmU6IFtzaXByZWNdIFF1ZXN0aW9uIG9uIHRoZSBzY29wZQ0K PiA+IA0KPiA+IEhpIEFuZHksDQo+ID4gDQo+ID4gVGhlIHNlc3Npb24gYmV0d2VlbiBVQS1BIGFu ZCB0aGUgTWVkaWEgU2VydmVyIGRvZXMgbm90IGNvbnZleSANCj4gPiBhbnkgbWVkaWEuDQo+ID4g VGhpcyBTSVAgc2Vzc2lvbiBtYWlubHkgdGVsbHMgdGhlIEIyQlVBIHdoYXQgdG8gYmUgcmVjb3Jk ZWQuDQo+ID4gDQo+ID4gQXMgYmFja2dyb3VuZCwgdG8gd2F0Y2ggYSBJUFRWIHByb2dyYW0sIHRo ZSBVQS1BIGluaXRpYXRlcyBhIA0KPiA+IFNJUCBzZXNzaW9uIHRvDQo+ID4gc2V0dXAgYSBtZWRp YSBzZXNzaW9uIGJldHdlZW4gVUEtQSBhbmQgTWVkaWEgU2VydmVyLiBUaGUgDQo+ID4gbWVkaWEg c2Vzc2lvbiBjb3VsZA0KPiA+IGJlIGEgdW5pY2FzdCBvciBtdWx0aWNhc3Qgc2Vzc2lvbi4NCj4g PiBXaGlsZSBpbiB0aGUgTlBWUiBjYXNlLCB0aGUgdXNlciAod2l0aCBVQS1BKSBtYXkgbm90IGJl IGFibGUgDQo+ID4gdG8gd2F0Y2ggdGhlDQo+ID4gbGl2ZSBwcm9ncmFtLCBhbmQgd2FudCB0byBy ZWNvcmQgYW5kIHdhdGNoIHRoZSBwcm9ncmFtIGF0IGEgDQo+ID4gbGF0ZXIgdGltZS4gDQo+ID4g VGhlcmVmb3JlLCB3aGVuIGluaXRpYXRlcyB0aGUgcmVjb3JkaW5nIHNlc3Npb24sIHRoZSBVQS1B IA0KPiA+IHdpbGwgb25seSB0ZWxscw0KPiA+IHdoYXQgdG8gcmVjb3JkLCB3aXRob3V0IGFueSBt ZWRpYSBjb252ZXlpbmcuIA0KPiA+IA0KPiA+IEhvcGUgdGhpcyBjbGFyaWZpZXMhDQo+ID4gDQo+ ID4gQmVzdCByZWdhcmRzLA0KPiA+IFJveQ0KPiA+IA0KPiA+IC0tLS0t08q8/tStvP4tLS0tLQ0K PiA+ILeivP7IyzogSHV0dG9uLCBBbmRyZXcgW21haWx0bzphbmRyZXcuaHV0dG9uQHNpZW1lbnMt ZW50ZXJwcmlzZS5jb21dIA0KPiA+ILeiy83KsbzkOiAyMDExxOo01MIxMsjVIDE3OjM3DQo+ID4g ytW8/sjLOiBFbHdlbGwsIEpvaG47IFJveTsgc2lwcmVjQGlldGYub3JnDQo+ID4g1vfM4jogUkU6 IFtzaXByZWNdIFF1ZXN0aW9uIG9uIHRoZSBzY29wZQ0KPiA+IA0KPiA+IEhpIFJveSwNCj4gPiAN Cj4gPiBZb3VyIGRpYWdyYW0gc2hvd3MgYSBTSVAgc2Vzc2lvbiBmcm9tIFVBLUEgdG8gdGhlIEIy QlVBIGFuZCANCj4gPiBiZXR3ZWVuIHRoZQ0KPiA+IEIyQlVBIGFuZCB0aGUgTWVkaWEgU2VydmVy LiBJIGFzc3VtZSB0aGlzIGlzIGxvZ2ljYWxseSBhIA0KPiA+IHNlc3Npb24gYmV0d2VlbiB0aGUN Cj4gPiBVQS1BIGFuZCB0aGUgTWVkaWEgU2VydmVyIHdpdGggdGhlIEIyQlVBIGluIHRoZSBtaWRk bGUuIA0KPiA+IA0KPiA+IERvZXMgdGhpcyBzZXNzaW9uIGNvbnZleSBhbnkgbWVkaWEgYmV0d2Vl biBVQS1BIGFuZCB0aGUgTWVkaWEgDQo+ID4gU2VydmVyIGFuZCBpZg0KPiA+IHNvIHdoYXQgaXMg dGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoaXMgYW5kIHRoZSBtZWRpYSBzZW50IA0KPiA+IHRv IHRoZSByZWNvcmRpbmcNCj4gPiBzZXJ2ZXI/DQo+ID4gDQo+ID4gV2hhdCBpcyB0aGUgU0lQIFNl c3Npb24gdXNlZCBmb3IgYXQgVUEtQT8NCj4gPiANCj4gPiBSZWdhcmRzDQo+ID4gQW5keQ0KPiA+ IA0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g PiA+IEZyb206IHNpcHJlYy1ib3VuY2VzQGlldGYub3JnIA0KPiA+ID4gW21haWx0bzpzaXByZWMt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEVsd2VsbCwgSm9obg0KPiA+ID4gU2VudDog MTIgQXByaWwgMjAxMSAwODoxNA0KPiA+ID4gVG86IFJveTsgc2lwcmVjQGlldGYub3JnDQo+ID4g PiBTdWJqZWN0OiBSZTogW3NpcHJlY10gUXVlc3Rpb24gb24gdGhlIHNjb3BlDQo+ID4gPiANCj4g PiA+IFJveSwNCj4gPiA+IA0KPiA+ID4gSSBhbSBub3Qgc3VyZSBJIHVuZGVyc3RhbmQgeW91ciB1 c2UgY2FzZSBjb3JyZWN0bHksIGJ1dCBpdCANCj4gPiA+IHNlZW1zIHNvbWUgY29udGVudCBmcm9t IGluc2lkZSBhIG1lZGlhIHNlcnZlciBpcyBiZWluZyANCj4gPiA+IHJlY29yZGVkLCBhcyBvcHBv c2VkIHRvIHJlY29yZGluZyBjb250ZW50IHRoYXQgaXMgdHJhbnNwb3J0ZWQgDQo+ID4gPiBiZXR3 ZWVuIHR3byBvciBtb3JlIHVzZXJzIGFzIHBhcnQgb2YgYSBjb21tdW5pY2F0aW9uIHNlc3Npb24u IA0KPiA+ID4gSSBiZWxpZXZlIHRoYXQgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhlIHdvcmtp bmcgZ3JvdXAuIFNlZSANCj4gPiA+IHRoZSBjaGFydGVyIGFuZCBkcmFmdC1pZXRmLXNpcHJlYy1y ZXEgKHJlcXVpcmVtZW50cykuIE91ciANCj4gPiA+IHdvcmsgaXMgY29uY2VybmVkIHdpdGggcmVj b3JkaW5nIGEgc2Vzc2lvbiwgc28gY29udGVudCB0aGF0IA0KPiA+ID4gaXMgaGVsZCBpbnRlcm5h bGx5IHRvIGEgbWVkaWEgc2VydmVyLCBhcyBvcHBvc2VkIHRvIGJlaW5nIA0KPiA+ID4gdHJhbnNw b3J0ZWQgYXMgcGFydCBvZiBhIHNlc3Npb24gaXMgb3V0IG9mIHNjb3BlLg0KPiA+ID4gDQo+ID4g PiBKb2huDQo+ID4gPiANCj4gPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ ID4gRnJvbTogc2lwcmVjLWJvdW5jZXNAaWV0Zi5vcmcgDQo+ID4gPiA+IFttYWlsdG86c2lwcmVj LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSb3kNCj4gPiA+ID4gU2VudDogMTIgQXBy aWwgMjAxMSAwNzoyOQ0KPiA+ID4gPiBUbzogc2lwcmVjQGlldGYub3JnDQo+ID4gPiA+IFN1Ympl Y3Q6IFtzaXByZWNdIFF1ZXN0aW9uIG9uIHRoZSBzY29wZQ0KPiA+ID4gPiANCj4gPiA+ID4gSGVs bG8NCj4gPiA+ID4gDQo+ID4gPiA+ICANCj4gPiA+ID4gDQo+ID4gPiA+IEkgZmluZCB0aGlzIHdv cmsgZ3JvdXAgZHVyaW5nIFByYWd1ZSBtZWV0aW5nLiBUaGUgd29yayBoZXJlIA0KPiA+ID4gPiBp cyBxdWl0ZSBpbnRlcmVzdGluZyBhbHRob3VnaCBJIGhhdmUgc29tZSBxdWVzdGlvbnMgYXMgYmVs b3c6DQo+ID4gPiA+IA0KPiA+ID4gPiAgDQo+ID4gPiA+IA0KPiA+ID4gPiBBbGwgdGhyb3VnaCB0 aGUgYXJjaGl0ZWN0dXJlIGFuZCByZXF1aXJlbWVudCBkb2N1bWVudCwgd2UgYXJlIA0KPiA+ID4g PiB0YWxraW5nIGFib3V0IHJlY29yZGluZyBhIG1lZGlhIHNlc3Npb24gYmV0d2VlbiB0d28gVUEu IA0KPiA+ID4gPiANCj4gPiA+ID4gSG93ZXZlciwgdGhlcmUgaXMgYWxzbyB1c2UgY2FzZXMgdGhh dCBhIFVBMSByZXF1ZXN0cyBhIA0KPiA+ID4gPiByZWNvcmRpbmcgc2VydmVyIChTUlMpIHRvIHJl Y29yZCBhIG1lZGlhIGNvbnRlbnQgaW4gbWVkaWEgDQo+ID4gPiA+IHNlcnZlciAoVUEyKSB3aGls ZSB0aGVyZSBpcyBub3QgYW55IGRpcmVjdCBtZWRpYSBzZXNzaW9uIA0KPiA+ID4gPiBiZXR3ZWVu IFVBMSBhbmQgbWVkaWEgc2VydmVyLiBGb2xsb3dpbmcgaXMgYSBnZW5lcmFsIA0KPiBhcmNoaXRl Y3R1cmUuDQo+ID4gPiA+IA0KPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLSsNCj4gPiA+ID4gDQo+ID4gPiA+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgKFJlY29yZGluZyBTZXNzaW9uKSAgICAgfCAgICAgICAgICAg fA0KPiA+ID4gPiANCj4gPiA+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICA7ICstLS0t LSBkaW5nIHwNCj4gPiA+ID4gDQo+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fCAgICAgICAgICAgICAgICAgICAgfCAgU2VydmVyICAgfA0KPiA+ID4gPiANCj4gPiA+ID4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgKy0tLU1ldGFEYXRhLS0tLT58ICAgICAgICAg ICB8DQo+ID4gPiA+IA0KPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAmbiB8ICAg ICAgICAgICAgICAgICstLS0tLS0tLS0tLSsNCj4gPiA+ID4gDQo+ID4gPiA+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfCAgIHwgICAgICAgICAgICAgICAgICAgICBeDQo+ID4gPiA+IA0K PiA+ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICB8ICAgICAgICAgICAgICAg ICAgICAgfA0KPiA+ID4gPiANCj4gPiA+ID4gICAgICAmbiBzcDsgICAgICAgICAgICAgICAgICAg IHwgICB8ICAgICAgICAgICAgICAgICAgICBSVFANCj4gPiA+ID4gDQo+ID4gPiA+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgViAgIFYgICAgICAgICAgICB1bmljYXN0IA0KPiBvciBtdWx0 aWNhc3QNCj4gPiA+ID4gDQo+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0t LS0tLS0tLS0tLS0rICAgICAgICAgICB8DQo+ID4gPiA+IA0KPiA+ID4gPiBuYnNwOyAgICAgICAg ICAgICAgICAgICB8ICAgICAgQjJCVUEgICAgICAgfCAgICAgICAgICAgfA0KPiA+ID4gPiANCj4g PiA+ID4gICAgICArLS0tLS0tLS0rICAgICAgICAgfCBTZXJ2aWNlIENvbnRyb2wgIHwgICAgICAg ICArLS0tLS0tLS0tKw0KPiA+ID4gPiANCj4gPiA+ID4gICAgICB8ICAgICAgICB8PC0gU0lQIC0+ fCAgIEZ1bmN0aW9uICAgICAgIHw8LSBTSVAgLT58ICAgICAgICAgfA0KPiA+ID4gPiANCj4gPiA+ ID4gICAgICB8ICBVQS1BICB8ICAgICAgICAgKy0tLS0tLS0tLSAtLS0tLS0tLSA7ICAgICB8ICBN ZWRpYSAgfA0KPiA+ID4gPiANCj4gPiA+ID4gICAgICB8ICAgICAgICB8ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8ICBTZXJ2ZXIgfA0KPiA+ID4gPiANCj4gPiA+ID4gICAg ICArLS0tLS0tLS0rICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0t LS0tKw0KPiA+ID4gPiANCj4gPiA+ID4gIA0KPiA+ID4gPiANCj4gPiA+ID4gVGhpcyBjYXNlIGlz IHZlcnkgY29tbW9uIGluIElQVFYgaW5kdXN0cnksIGtub3duIGFzIE5ldHdvcmsgDQo+ID4gPiA+ IFBlcnNvbmFsIFZpZGUgbyBSZWNvcmQgZXJ5IHNpbWlsYXIgd2l0aCB0aGUgd29yayBoZXJlLg0K PiA+ID4gPiANCj4gPiA+ID4gRG9lcyBjdXJyZW50IGRvY3VtZW50IGNvdmVyIHRoaXMgdXNlIGNh c2UgYWxyZWFkeSBvciBkaWQgeW91IA0KPiA+ID4gPiBkaXNjdXNzZWQgc2ltaWxhciBjYXNlIGV2 ZXI/DQo+ID4gPiA+IA0KPiA+ID4gPiAgDQo+ID4gPiA+IA0KPiA+ID4gPiBNYW55IHRoYW5rcyBh bmQgYmVzdCByZWdhcmRzLA0KPiA+ID4gPiANCj4gPiA+ID4gUm95DQo+ID4gPiA+IA0KPiA+ID4g PiANCj4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+ID4gPiBzaXByZWMgbWFpbGluZyBsaXN0DQo+ID4gPiBzaXByZWNAaWV0Zi5vcmcNCj4gPiA+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwcmVjDQo+ID4gPiANCj4g PiANCj4gPiANCj4gPiANCj4gDQo+IA0KPiA= From john.elwell@siemens-enterprise.com Thu Apr 14 03:54:26 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7B1D4E0684; Thu, 14 Apr 2011 03:54:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.81 X-Spam-Level: X-Spam-Status: No, score=-104.81 tagged_above=-999 required=5 tests=[AWL=1.789, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFFAPrG7pm4j; Thu, 14 Apr 2011 03:54:25 -0700 (PDT) Received: from mail174.messagelabs.com (mail174.messagelabs.com [85.158.138.51]) by ietfc.amsl.com (Postfix) with SMTP id 506D0E066A; Thu, 14 Apr 2011 03:54:25 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1302778464!10667763!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 25602 invoked from network); 14 Apr 2011 10:54:24 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-15.tower-174.messagelabs.com with SMTP; 14 Apr 2011 10:54:24 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 71FEC1EB83E3; Thu, 14 Apr 2011 12:54:24 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 14 Apr 2011 12:54:24 +0200 From: "Elwell, John" To: "Muthu ArulMozhi Perumal (mperumal)" , "ietf@ietf.org" Date: Thu, 14 Apr 2011 12:54:23 +0200 Thread-Topic: [siprec] Last Call: (Use Cases andRequirements for SIP-based Media Recording (SIPREC)) toInformational RFC Thread-Index: Acv0WYBeRuGjGNBtTZSHeqn78QP5xwGEv6YwAAlHtwA= Message-ID: References: <20110406125020.17538.70016.idtracker@localhost> <1D062974A4845E4D8A343C65380492020533BB70@XMB-BGL-414.cisco.com> In-Reply-To: <1D062974A4845E4D8A343C65380492020533BB70@XMB-BGL-414.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 Cc: "siprec@ietf.org" Subject: Re: [siprec] Last Call: (Use Cases andRequirements for SIP-based Media Recording (SIPREC)) toInformational RFC X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 14 Apr 2011 10:54:26 -0000 =20 > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Muthu ArulMozhi=20 > Perumal (mperumal) > Sent: 14 April 2011 07:34 > To: ietf@ietf.org > Cc: siprec@ietf.org > Subject: Re: [siprec] Last Call:=20 > (Use Cases andRequirements for=20 > SIP-based Media Recording (SIPREC)) toInformational RFC >=20 > I've one major comment. It draft discusses synchronization between the > recorded media streams and synchronized playback, which seem important > for certain applications: >=20 > > Some applications require the recording of more than one media stream, > possibly of different types. Media are synchronized, either at storage > or at playback. > >=20 > However, in the requirements section it doesn't seem REQ-022=20 > and REQ-023 > are all that are need and sufficient to achieve this with needed > precision. So, I would suggest adding another requirement as follows: > The mechanism MUST provide means for facilitating=20 > synchronization of the > recorded media streams and metadata either at storage or at playback. > This includes, but not limited to, the information needed as=20 > per REQ-022 > and REQ-023. [JRE] This seems a reasonable addition. I wonder if the new requirement (fi= rst sentence only) is sufficient as a **replacement** for REQ-022 and REQ-0= 23. On reading REQ-022 and REQ-023 again, it is not so clear what their pur= pose was, and they seem to be more like a solution than a requirement. One = purpose would certainly be that covered by Muthu's new requirement. Was the= re any other purpose? John >=20 > A nitpick: > Use Case 8 > In cases where calls inside or between branches must be recorded, a > centralized recording system in data centers together with telephony > infrastructure (e.g. PBX) me deployed. >=20 > s/me/may be >=20 > Muthu >=20 > |-----Original Message----- > |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of The IESG > |Sent: Wednesday, April 06, 2011 6:20 PM > |To: IETF-Announce > |Cc: siprec@ietf.org > |Subject: [siprec] Last Call: =20 > (Use Cases > andRequirements for SIP-based > |Media Recording (SIPREC)) toInformational RFC > | > | > |The IESG has received a request from the SIP Recording WG (siprec) to > |consider the following document: > |- 'Use Cases and Requirements for SIP-based Media Recording (SIPREC)' > | as an Informational RFC > | > |The IESG plans to make a decision in the next few weeks, and solicits > |final comments on this action. Please send substantive=20 > comments to the > |ietf@ietf.org mailing lists by 2011-04-20. Exceptionally,=20 > comments may > be > |sent to iesg@ietf.org instead. In either case, please retain the > |beginning of the Subject line to allow automated sorting. > | > |The file can be obtained via > |http://datatracker.ietf.org/doc/draft-ietf-siprec-req/ > | > |IESG discussion can be tracked via > |http://datatracker.ietf.org/doc/draft-ietf-siprec-req/ > | > | > | > |No IPR declarations have been submitted directly on this I-D. > |_______________________________________________ > |siprec mailing 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 Apr 14 04:12:21 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CBF0EE06DA for ; Thu, 14 Apr 2011 04:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.84 X-Spam-Level: X-Spam-Status: No, score=-104.84 tagged_above=-999 required=5 tests=[AWL=1.759, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZiRQAzQkVFc for ; Thu, 14 Apr 2011 04:12:19 -0700 (PDT) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfc.amsl.com (Postfix) with SMTP id D3C8AE0670 for ; Thu, 14 Apr 2011 04:12:18 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1302779534!30977447!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 1174 invoked from network); 14 Apr 2011 11:12:14 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-7.tower-27.messagelabs.com with SMTP; 14 Apr 2011 11:12:14 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 71CE123F03E2; Thu, 14 Apr 2011 13:12:17 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 14 Apr 2011 13:12:17 +0200 From: "Elwell, John" To: Paul Kyzivat , "Parthasarathi R (partr)" Date: Thu, 14 Apr 2011 13:12:15 +0200 Thread-Topic: [siprec] start/stop times & the metamodel Thread-Index: Acv52n/qagzulBJoTT6O3oRm0wVyQwAuCnTQ Message-ID: References: <4D9CDADD.1020403@cisco.com> <4DA2FC17.1060100@cisco.com><07465C1D981ABC41A344374066AE1A2C38AB6E1DE4@TLVMBX01.nice.com><4DA334F0.9050301@cisco.com><059AF07365DC474393A19A3AF187DF7406E67CB4@NAHALD.us.int.genesyslab.com><1D062974A4845E4D8A343C65380492020533B45B@XMB-BGL-414.cisco.com> <059AF07365DC474393A19A3AF187DF7406EF2378@NAHALD.us.int.genesyslab.com> <1D062974A4845E4D8A343C65380492020533B880@XMB-BGL-414.cisco.com> <1D062974A4845E4D8A343C65380492020533B93C@XMB-BGL-414.cisco.com> <4DA59DF3.7020500@cisco.com> In-Reply-To: <4DA59DF3.7020500@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 Cc: "siprec@ietf.org" Subject: Re: [siprec] start/stop times & the metamodel X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 14 Apr 2011 11:12:22 -0000 I guess it depends what we are trying to capture here. Consider a 2-party c= all between A and B. First consider the case where the SRC is collocated with UA A. Do we wish t= o record the time A sends media and the time A receives media. Note that th= e time B receives media will be later than the time A sends it, and the tim= e B sends media will be earlier than the time A receives it. When reconstru= cting audio during playback, do we want to reconstruct the audio with synch= ronization between the two directions in accordance with what took place at= A or with what took place at B? Second, consider the case where the SRC is at a B2BUA. Here the times that = media pass through equate neither to the time that A sends and receives nor= the time that B sends and receives. So do we want to reconstruct the audio= as observed by the B2BUA, or what took place at A, or what took place at B= ? Another point is that for calls partly over TDM (PSTN), timings for what ha= ppens beyond the gateway will not be available. So it will not be possible = to reconstruct a conversation from the perspective of a user participating = via PSTN. It would be possible to simplify things and say that we record in a way tha= t what gets reconstructed on playback is what is observed at the point wher= e the SRC is located. Sure, this is a simplification, but trying to do anyt= hing else would be harder and still would not reflect what is observed by s= ome or all of the participants. If we assume this simplification, the only other point is trying to compens= ate for delays, or in particular differing delays, on the RS path. John (as individual) > -----Original Message----- > From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 13 April 2011 13:58 > To: Parthasarathi R (partr) > Cc: siprec@ietf.org > Subject: Re: [siprec] start/stop times & the metamodel > > > > On 4/13/2011 7:50 AM, Parthasarathi R (partr) wrote: > > Muthu, > > > > Even now, Media stream block attributes like start-time, end-time in > > metadata from SRC facilitates SRS to have synchronized > playback media in > > case SRS maps metadata from SRC with the received raw > media. Proposed > > requirement is going one level deeper wherein the timestamp > from SRC has > > to be based on RTP layer timestamp or SRC SIP signaling? > > > > IMO, SIP signaling serves the purpose and there is no need > of explicitly > > mention how SRC find start timestamp. In case you have > strong usecase > > for RTP timestamp based requirement, it requires changes in SIPREC > > requirement because it is specific mechanism insisted on SRC. > > Let me start out by saying that I don't know what the > answer(s) are here > - I have a very limited knowledge of RTP. > > The timestamps in the metadata (or in the sip messages that carry the > metadata) are a *piece* of the solution. How *sufficient* they are > remains to be seen - perhaps by demonstrating some procedures > for using > them to achieve a useful playback result in various scenarios. > > The problem seems to be that even if a timestamp from the CS > signaling > is passed in the metadata, its not clear how that can be synchronized > with RTP data arriving at the SRS. *Perhaps* its enough if you assume > that RTP packets will begin to arrive at the SRS concurrently > with the > signaling that describes the corresponding stream. I'm > certain that is > *not* true, but I don't know how *far* from true it is, or > how much that > will vary based on scenario. > > It does seem to me that it is a mistake to standardize a > mechanism that > *depends* on such a shaky mechanism. (But a mechanism that > uses this as > a fallback mechanism might make sense.) > > Thanks, > Paul > > > Thanks > > Partha > > > > -----Original Message----- > > From: Muthu ArulMozhi Perumal (mperumal) > > Sent: Wednesday, April 13, 2011 4:07 PM > > To: Parthasarathi R (partr); 'Henry Lum'; Paul Kyzivat > (pkyzivat); 'Leon > > Portman' > > Cc: 'siprec@ietf.org' > > Subject: RE: [siprec] start/stop times& the metamodel > > > > I don't think the requirements need to go to the level of > RTP timestamp. > > But it may be useful to add a requirement that the SRC needs to > > facilitate synchronized querying/playback of the recorded > media streams > > and metadata. I couldn't derive that directly from the > requirements we > > already have, but would like to hear from others if this is already > > implied. > > > > Muthu > > > > |-----Original Message----- > > |From: Parthasarathi R (partr) > > |Sent: Wednesday, April 13, 2011 2:46 PM > > |To: Muthu ArulMozhi Perumal (mperumal); 'Henry Lum'; Paul Kyzivat > > (pkyzivat); 'Leon Portman' > > |Cc: 'siprec@ietf.org' > > |Subject: RE: [siprec] start/stop times& the metamodel > > | > > |ISTM, SRC has to act only as RTP Endpoint or RTP Mixer (not RTP > > |translator) in case these requirement has to be considered within > > |SIPREC. IMO, these requirement has to be mentioned in SIPREC > > |requirement document to define the exact role what SRC > does with media > > timestamp and what SRS does with media timestamp? > > | > > |Thanks > > |Partha > > | > > |-----Original Message----- > > |From: Muthu ArulMozhi Perumal (mperumal) > > |Sent: Wednesday, April 13, 2011 12:36 PM > > |To: Parthasarathi R (partr); 'Henry Lum'; Paul Kyzivat (pkyzivat); > > 'Leon Portman' > > |Cc: 'siprec@ietf.org' > > |Subject: RE: [siprec] start/stop times& the metamodel > > | > > |After the use-case Paul described, it seem to me that if > we keep out of > > > > |scope it will put a lot of burden on the SRS to support > synchronized > > |querying/playback which looks an important aspect for > media recording. > > So, we may want to consider the ways in which the SRC can > facilitate it. > > | > > |Muthu > > | > > ||-----Original Message----- > > ||From: Parthasarathi R (partr) > > ||Sent: Wednesday, April 13, 2011 11:20 AM > > ||To: Henry Lum; Muthu ArulMozhi Perumal (mperumal); Paul Kyzivat > > ||(pkyzivat); Leon Portman > > ||Cc: siprec@ietf.org > > ||Subject: RE: [siprec] start/stop times& the metamodel > > || > > ||Henry, > > || > > ||I attached the follow up mail to below mail thread. Till > now, We don't > > > > ||have strong requirement to solve in SIPREC. Let us identify the > > ||requirement before going to the > > |solution. > > || > > ||Thanks > > ||Partha > > || > > ||-----Original Message----- > > ||From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > ||Behalf Of Henry Lum > > ||Sent: Wednesday, April 13, 2011 2:43 AM > > ||To: Muthu ArulMozhi Perumal (mperumal); Paul Kyzivat > (pkyzivat); Leon > > ||Portman > > ||Cc: siprec@ietf.org > > ||Subject: Re: [siprec] start/stop times& the metamodel > > || > > ||I don't think it is guaranteed that participants will > send SR reports > > ||(or any RTCP), plus we will also have to assume that the NTP > > ||timestamps are in sync. We could mandate the SRC to generate SR > > ||reports but then we are fixing the RTP model for > > |the SRC. > > || > > ||Regards, > > ||Henry > > || > > ||> -----Original Message----- > > ||> From: Muthu ArulMozhi Perumal (mperumal) > [mailto:mperumal@cisco.com] > > ||> Sent: Monday, April 11, 2011 10:45 PM > > ||> To: Henry Lum; Paul Kyzivat (pkyzivat); Leon Portman > > ||> Cc: siprec@ietf.org > > ||> Subject: RE: [siprec] start/stop times& the metamodel > > ||> > > ||> While I see it may be useful for the SRS to know when > certain things > > > > ||> happened in CS signaling (participant joining, > leaving, going mute > > ||etc) > > ||> I don't see how useful it would be for it know how > those things are > > ||> related to when the participant actually sent/received > (or stopped > > ||> sending/receiving) RTP. > > ||> > > ||> If we see any use, one way to do it is using the NTP timestamp > > ||> carried in RTCP SR reports, provided the SRC, SRS and the > > ||> participants have access to the same reference wallclock. > > ||> > > ||> Muthu > > ||> > > ||> |-----Original Message----- > > ||> |From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On > > ||> Behalf Of Henry Lum > > ||> |Sent: Tuesday, April 12, 2011 2:56 AM > > ||> |To: Paul Kyzivat (pkyzivat); Leon Portman > > ||> |Cc: siprec@ietf.org > > ||> |Subject: Re: [siprec] start/stop times& the metamodel > > ||> | > > ||> |A related question on the RTP model is that if the > SRC as an RTP > > ||> |translator chooses to relay the RTP timestamps, then > how would the > > ||SRC > > ||> |synchronize the timestamps between the SIP messages > the multiple > > ||> |RTP streams? > > ||> | > > ||> |Henry > > ||> | > > ||> |> -----Original Message----- > > ||> |> From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On > > > > ||> |> Behalf Of Paul Kyzivat > > ||> |> Sent: Monday, April 11, 2011 1:06 PM > > ||> |> To: Leon Portman > > ||> |> Cc: siprec@ietf.org > > ||> |> Subject: Re: [siprec] start/stop times& the metamodel > > ||> |> > > ||> |> > > ||> |> > > ||> |> On 4/11/2011 9:36 AM, Leon Portman wrote: > > ||> |> > Paul Hi > > ||> |> > > > ||> |> > I agree with proposed method of time stamping > metadata elements > > ||> with > > ||> |> SRC clock (it is like a wall clock from the requirement > > document). > > ||> |> > About RTP time synchronization to metadata > events, we either > > ||> should > > ||> |> have some low latency event from SRC to SRS with > SRC time that > > ||> |> will allow SRS to maintain time difference between > its clock and > > ||> |> SRC > > ||> clock > > ||> |> and then apply it also to receive time of RTP > packet (assuming no > > ||> |> buffering) > > ||> |> > > ||> |> ISTM the issue isn't the latency of the event - it > is what it is > > ||> |> - > > ||> but > > ||> |> rather how to correlate a sip message containing > metadata with a > > ||> |> particular RTP packet. I suspect that needs to be > tied into the > > ||> |> discussion of the various models for how the SRC > might handle > > RDP. > > ||> |> > > ||> |> Thanks, > > ||> |> Paul > > ||> |> > > ||> |> > Leon > > ||> |> > > > ||> |> > -----Original Message----- > > ||> |> > From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] > > ||> |> > On > > ||> |> Behalf Of Paul Kyzivat > > ||> |> > Sent: Monday, April 11, 2011 4:03 PM > > ||> |> > To: Elwell, John > > ||> |> > Cc: siprec@ietf.org > > ||> |> > Subject: Re: [siprec] start/stop times& the metamodel > > ||> |> > > > ||> |> > > > ||> |> > > > ||> |> > On 4/8/2011 11:53 AM, Elwell, John wrote: > > ||> |> >> Paul, > > ||> |> >> > > ||> |> >> I think much of what you say makes sense. I > was concerned that > > ||we > > ||> |> probably need to record when a participant stops or starts > > ||> |> sending > > ||> or > > ||> |> receiving a stream, which seems to be covered by > your statement: > > ||> |> "Changes to media streams should similarly be > tagged with the > > ||> |> time > > ||> |they > > ||> |> occurred in the CS signaling. Each participant relationship > > ||> |> change (send, receive, inactive,) will be there." > That doesn't > > ||> |> seem to be > > ||> in > > ||> |> the model at present. > > ||> |> > > > ||> |> > John, > > ||> |> > > > ||> |> > I agree the current model doesn't reflect this > - it was a > > ||> |> > private > > ||> |> thought by me, provoked by the work and discussion > to date. It is > > > > ||> |> a > > ||> |bit > > ||> |> of a change of direction, so I'm interested in > what others think > > ||> about > > ||> |> it. > > ||> |> > > > ||> |> > Thanks, > > ||> |> > Paul > > ||> |> > > > ||> |> >> John (as individual) > > ||> |> >> > > ||> |> >> > > ||> |> >>> -----Original Message----- > > ||> |> >>> From: siprec-bounces@ietf.org > > ||> |> >>> [mailto:siprec-bounces@ietf.org] On Behalf Of > Paul Kyzivat > > ||> |> >>> Sent: 06 April 2011 22:28 > > ||> |> >>> To: siprec@ietf.org > > ||> |> >>> Subject: [siprec] start/stop times& the metamodel > > ||> |> >>> > > ||> |> >>> In Prague, one of the open issues was around > start/stop > > times. > > ||> The > > ||> |> >>> format draft floated the possibility of > having explicit > > ||> start/stop > > ||> |> >>> times signaled for each of the metatdata > elements. But then > > ||> |> >>> we > > ||> |> asked > > ||> |> >>> for feedback on which make sense. > > ||> |> >>> > > ||> |> >>> IMO explicit start/stop times make more sense > for some things > > ||> than > > ||> |> >>> others. > > ||> |> >>> > > ||> |> >>> One place where we potentially have explicit > times to report > > ||> with > > ||> |> the > > ||> |> >>> dialogs that constitute a CS. Each such > dialog presumably has > > > > ||> |> >>> a > > ||> |> start > > ||> |> >>> and stop time observable by the SRC, which > might differ, at > > ||> least > > ||> |a > > ||> |> >>> bit, from the corresponding signaling on the RS. > > ||> |> >>> > > ||> |> >>> We might want to report those times. Or, > since we abstract > > ||> |> >>> the > > ||> CS > > ||> |> >>> away from the dialog, we might want to report > the start time > > ||> |> >>> of > > ||> |the > > ||> |> >>> first dialog in the CS as the CS start time, > and the stop > > ||> |> >>> time > > ||> of > > ||> |> the > > ||> |> >>> last dialog in the CS as the CS stop time. > > ||> |> >>> > > ||> |> >>> Similarly, we have abstracted media streams > away from the > > ||> |> >>> media streams in the sip dialogs that make up > the CS. We > > ||> |> >>> might want > > ||to > > ||> |> >>> report the start time of a media stream as the time > > ||> |> >>> (according > > ||> to > > ||> |> the > > ||> |> >>> CS) of the first participant to a new media > stream, and the > > ||stop > > ||> |> time > > ||> |> >>> as the time that the last participant leaves the media > > stream. > > ||> |> >>> > > ||> |> >>> There are several things that complicate this: > > ||> |> >>> > > ||> |> >>> - Do we consider the case of a stream that starts with > > recvonly > > ||> |> >>> or inactive participants, and only later > gets a sender? > > ||> |> >>> If > > ||> |so, > > ||> |> >>> is the start time of the stream when the first > > ||> |> >>> participant > > ||> |> arrived, > > ||> |> >>> or when the first sender arrived? > > ||> |> >>> > > ||> |> >>> - How do we get the clock times for the media streams? > > ||> |> >>> IIUC the correct ones are in the > RTP/RTCP, but the > > ||> reporting > > ||> |> of > > ||> |> >>> these events is driven by the signaling, > and we don't > > ||> |> >>> have > > ||> |> good > > ||> |> >>> sync between those. (E.g. media could > start flowing > > ||> |> >>> before > > ||> |the > > ||> |> >>> corresponding signaling, and we would > like to include > > ||> |> >>> that > > ||> if > > ||> |> we > > ||> |> >>> can figure it out.) So, even if the > clocks used for > > ||> |> >>> media > > ||> and > > ||> |> >>> signaling are in sync, we might see > media packets arrive > > ||> with > > ||> |> >>> a timestamp prior to the timestamp for > the signaling > > that > > ||> |> >>> indicates the send state of the > participant. This could > > ||> cause > > ||> |> >>> trouble in playback. > > ||> |> >>> > > ||> |> >>> - There isn't any guarantee that the clock > used for signaling > > ||> |> >>> messages is synchronized with the clock used in > > RTP/RTCP. > > ||> |> >>> > > ||> |> >>> - There isn't any guarantee that there will > be any RTCP at > > all, > > ||> |> >>> to provide correlation of the RTP to clocktime. > > ||> |> >>> > > ||> |> >>> The best I can see to deal with all of this is: > > ||> |> >>> > > ||> |> >>> - All the metadata messages should be > timestamped by the SRC > > ||> |> >>> using its local clock. This is easily > achieved by the > > Date > > ||> |> >>> header in the sip message. > > ||> |> >>> > > ||> |> >>> - Changes to a CS, including changes of > participants, should > > ||> |> >>> be explicitly tagged with the time they > occurred in the > > ||> |> >>> CS signaling, according to the SRC's > clock. (If that is > > ||> |> >>> unavailable for some reason, then use > the time the SRC > > ||> |> >>> became aware of it.) > > ||> |> >>> > > ||> |> >>> - We could provide a metadata update element > to indicate end > > ||> |> >>> of a CS, but I suggest this just be shorthand for > > ||> indicating > > ||> |> >>> removal of all participants from it. > (While its possible > > ||to > > ||> |> >>> mark that the CS is truly ended, that > simply introduces > > an > > ||> |> >>> error case if added metadata about it is > subsequently > > ||> sent.) > > ||> |> >>> The actual start/stop time would be > determined by the > > SRS > > ||> |> >>> based on the timestamps of first and > last data about it. > > ||> |> >>> > > ||> |> >>> - Changes to media streams should similarly > be tagged with > > ||> |> >>> the time they occurred in the CS signaling. Each > > ||> participant > > ||> |> >>> relationship change (send, receive, > inactive,) will be > > ||> there. > > ||> |> >>> The actual start/stop time of the media > stream again > > ||> |> >>> would > > ||> be > > ||> |> >>> derived by the SRS. > > ||> |> >>> > > ||> |> >>> - CS-Groups can simply be tagged by the > timestamps of the > > ||> |> >>> updates that put CSs into them. Explicit > start/stop > > ||> |> >>> times > > ||> |> don't > > ||> |> >>> seem useful. If desired, the SRS can > derive start/stop > > ||> times > > ||> |> >>> from the start/stop times of the contained stuff. > > ||> |> >>> > > ||> |> >>> - I now think that CS-Groups should not be > "contained" within > > ||> |> >>> a recording. This just seems to > introduce unnecessary > > ||error > > ||> |> >>> conditions, and limitations on future > enhancements. The > > ||> |> >>> lifetime of CS-Groups will probably be > naturally limited > > ||by > > ||> |> >>> the ability of the SRC to remember the > IDs of old ones. > > ||> |> >>> For instance, if a CS-G is created > during one Recording, > > ||> |> >>> and then another CS is added to it from > a different > > ||> recording > > ||> |> >>> session, would we prefer to fail that, > or just allow it? > > ||> |> >>> (I think allow.) > > ||> |> >>> > > ||> |> >>> - Rather, I think every update transmitted > during a recording > > ||> |> >>> session can be tagged with a link to the > metadata of the > > ||> |> >>> recording session it came from. This need not be > > ||> |> >>> explicit > > ||- > > ||> |> the > > ||> |> >>> SRS can do it automatically. The > recording session > > entity > > ||> |> >>> itself will also have a start/stop time > which is the > > ||start/ > > ||> |> >>> stop of the RS dialog as observed by the SRS. > > ||> |> >>> > > ||> |> >>> (Note the above doesn't solve the problem of > getting correct > > ||> clock > > ||> |> >>> times for RTP media. If anyone has a > suggestion for this I'm > > ||all > > ||> |> >>> ears.) > > ||> |> >>> > > ||> |> >>> Thanks, > > ||> |> >>> Paul > > ||> |> >>> _______________________________________________ > > ||> |> >>> siprec mailing 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 > > ||> | > > ||> | > > ||> > > > |||----------------------------------------------------------- > ---------- > > |||- > > ||> - > > ||> ------------------------------- > > ||> |------------- > > ||> |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. > > ||> | > > ||> |_______________________________________________ > > ||> |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. > > || > > ||_______________________________________________ > > ||siprec mailing 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 partr@cisco.com Thu Apr 14 05:11:29 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D7E70E08A9 for ; Thu, 14 Apr 2011 05:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.081 X-Spam-Level: X-Spam-Status: No, score=-10.081 tagged_above=-999 required=5 tests=[AWL=0.518, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kobFbMgqad74 for ; Thu, 14 Apr 2011 05:11:27 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfc.amsl.com (Postfix) with ESMTP id 6686EE08A6 for ; Thu, 14 Apr 2011 05:11:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=24267; q=dns/txt; s=iport; t=1302783086; x=1303992686; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=qVgLo+kzzCeruWWsWq392N+8RfsxtaQ3EwxOsw7iN4Y=; b=evYhLrnwpPV6EAB2fbPkEDMEZQ0XqgAzDE92K2amWkITVEqz7nHvLaXB 8oS7uTw6RtTFlK8eGStPeFZii7rIwum3/2ueKJq7OcnJ8C261fToJY4v/ HelI/wQJRtmc5Z5xs/XbT3TI1cNL+nWjaLVV+7cRszyTIXWhjimD8ajp/ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuQAALDjpk2Q/khNgWdsb2JhbACXeY18FAEBFiYliG+bYZx3gn6CcASFWIwR X-IronPort-AV: E=Sophos;i="4.64,211,1301875200"; d="scan'208";a="25703253" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 14 Apr 2011 12:11:13 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3ECB7Ls001857; Thu, 14 Apr 2011 12:11:08 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Apr 2011 17:41:07 +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, 14 Apr 2011 17:41:06 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] start/stop times & the metamodel Thread-Index: Acv52n/qagzulBJoTT6O3oRm0wVyQwAuCnTQAAIbUlA= References: <4D9CDADD.1020403@cisco.com><4DA2FC17.1060100@cisco.com><07465C1D981ABC41A344374066AE1A2C38AB6E1DE4@TLVMBX01.nice.com><4DA334F0.9050301@cisco.com><059AF07365DC474393A19A3AF187DF7406E67CB4@NAHALD.us.int.genesyslab.com><1D062974A4845E4D8A343C65380492020533B45B@XMB-BGL-414.cisco.com><059AF07365DC474393A19A3AF187DF7406EF2378@NAHALD.us.int.genesyslab.com><1D062974A4845E4D8A343C65380492020533B880@XMB-BGL-414.cisco.com><1D062974A4845E4D8A343C65380492020533B93C@XMB-BGL-414.cisco.com> <4DA59DF3.7020500@cisco.com> From: "Parthasarathi R (partr)" To: "Elwell, John" , "Paul Kyzivat (pkyzivat)" X-OriginalArrivalTime: 14 Apr 2011 12:11:07.0410 (UTC) FILETIME=[08C48F20:01CBFA9D] Cc: siprec@ietf.org Subject: Re: [siprec] start/stop times & the metamodel X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 14 Apr 2011 12:11:30 -0000 John, Good summary on how reconstructed recorded media will look like. I'm of the same opinion that storing or playback in SRS will exactly look like SRC way of looking the media during the session. Media packet loss/delay in Recording session (RS) is unavoidable in the loss environment and in case media packet loss/delay is not desired during recording than Quos mechanism has to be used between RS which I guess it is outside the scope of SPIRE.=20 Thanks Partha -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 Sent: Thursday, April 14, 2011 4:42 PM To: Paul Kyzivat (pkyzivat); Parthasarathi R (partr) Cc: siprec@ietf.org Subject: RE: [siprec] start/stop times & the metamodel I guess it depends what we are trying to capture here. Consider a 2-party call between A and B. First consider the case where the SRC is collocated with UA A. Do we wish to record the time A sends media and the time A receives media. Note that the time B receives media will be later than the time A sends it, and the time B sends media will be earlier than the time A receives it. When reconstructing audio during playback, do we want to reconstruct the audio with synchronization between the two directions in accordance with what took place at A or with what took place at B? Second, consider the case where the SRC is at a B2BUA. Here the times that media pass through equate neither to the time that A sends and receives nor the time that B sends and receives. So do we want to reconstruct the audio as observed by the B2BUA, or what took place at A, or what took place at B? Another point is that for calls partly over TDM (PSTN), timings for what happens beyond the gateway will not be available. So it will not be possible to reconstruct a conversation from the perspective of a user participating via PSTN. It would be possible to simplify things and say that we record in a way that what gets reconstructed on playback is what is observed at the point where the SRC is located. Sure, this is a simplification, but trying to do anything else would be harder and still would not reflect what is observed by some or all of the participants. If we assume this simplification, the only other point is trying to compensate for delays, or in particular differing delays, on the RS path. John (as individual) > -----Original Message----- > From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 13 April 2011 13:58 > To: Parthasarathi R (partr) > Cc: siprec@ietf.org > Subject: Re: [siprec] start/stop times & the metamodel > > > > On 4/13/2011 7:50 AM, Parthasarathi R (partr) wrote: > > Muthu, > > > > Even now, Media stream block attributes like start-time, end-time in > > metadata from SRC facilitates SRS to have synchronized > playback media in > > case SRS maps metadata from SRC with the received raw > media. Proposed > > requirement is going one level deeper wherein the timestamp > from SRC has > > to be based on RTP layer timestamp or SRC SIP signaling? > > > > IMO, SIP signaling serves the purpose and there is no need > of explicitly > > mention how SRC find start timestamp. In case you have > strong usecase > > for RTP timestamp based requirement, it requires changes in SIPREC=20 > > requirement because it is specific mechanism insisted on SRC. > > Let me start out by saying that I don't know what the > answer(s) are here > - I have a very limited knowledge of RTP. > > The timestamps in the metadata (or in the sip messages that carry the > metadata) are a *piece* of the solution. How *sufficient* they are=20 > remains to be seen - perhaps by demonstrating some procedures for=20 > using them to achieve a useful playback result in various scenarios. > > The problem seems to be that even if a timestamp from the CS signaling > is passed in the metadata, its not clear how that can be synchronized=20 > with RTP data arriving at the SRS. *Perhaps* its enough if you assume=20 > that RTP packets will begin to arrive at the SRS concurrently with the > signaling that describes the corresponding stream. I'm certain that is > *not* true, but I don't know how *far* from true it is, or how much=20 > that will vary based on scenario. > > It does seem to me that it is a mistake to standardize a mechanism=20 > that > *depends* on such a shaky mechanism. (But a mechanism that uses this=20 > as a fallback mechanism might make sense.) > > Thanks, > Paul > > > Thanks > > Partha > > > > -----Original Message----- > > From: Muthu ArulMozhi Perumal (mperumal) > > Sent: Wednesday, April 13, 2011 4:07 PM > > To: Parthasarathi R (partr); 'Henry Lum'; Paul Kyzivat > (pkyzivat); 'Leon > > Portman' > > Cc: 'siprec@ietf.org' > > Subject: RE: [siprec] start/stop times& the metamodel > > > > I don't think the requirements need to go to the level of > RTP timestamp. > > But it may be useful to add a requirement that the SRC needs to=20 > > facilitate synchronized querying/playback of the recorded > media streams > > and metadata. I couldn't derive that directly from the > requirements we > > already have, but would like to hear from others if this is already=20 > > implied. > > > > Muthu > > > > |-----Original Message----- > > |From: Parthasarathi R (partr) > > |Sent: Wednesday, April 13, 2011 2:46 PM > > |To: Muthu ArulMozhi Perumal (mperumal); 'Henry Lum'; Paul Kyzivat > > (pkyzivat); 'Leon Portman' > > |Cc: 'siprec@ietf.org' > > |Subject: RE: [siprec] start/stop times& the metamodel > > | > > |ISTM, SRC has to act only as RTP Endpoint or RTP Mixer (not RTP > > |translator) in case these requirement has to be considered within=20 > > |SIPREC. IMO, these requirement has to be mentioned in SIPREC=20 > > |requirement document to define the exact role what SRC > does with media > > timestamp and what SRS does with media timestamp? > > | > > |Thanks > > |Partha > > | > > |-----Original Message----- > > |From: Muthu ArulMozhi Perumal (mperumal) > > |Sent: Wednesday, April 13, 2011 12:36 PM > > |To: Parthasarathi R (partr); 'Henry Lum'; Paul Kyzivat (pkyzivat); > > 'Leon Portman' > > |Cc: 'siprec@ietf.org' > > |Subject: RE: [siprec] start/stop times& the metamodel > > | > > |After the use-case Paul described, it seem to me that if > we keep out of > > > > |scope it will put a lot of burden on the SRS to support > synchronized > > |querying/playback which looks an important aspect for > media recording. > > So, we may want to consider the ways in which the SRC can > facilitate it. > > | > > |Muthu > > | > > ||-----Original Message----- > > ||From: Parthasarathi R (partr) > > ||Sent: Wednesday, April 13, 2011 11:20 AM > > ||To: Henry Lum; Muthu ArulMozhi Perumal (mperumal); Paul Kyzivat=20 > > ||(pkyzivat); Leon Portman > > ||Cc: siprec@ietf.org > > ||Subject: RE: [siprec] start/stop times& the metamodel > > || > > ||Henry, > > || > > ||I attached the follow up mail to below mail thread. Till > now, We don't > > > > ||have strong requirement to solve in SIPREC. Let us identify the=20 > > ||requirement before going to the > > |solution. > > || > > ||Thanks > > ||Partha > > || > > ||-----Original Message----- > > ||From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > > ||Behalf Of Henry Lum > > ||Sent: Wednesday, April 13, 2011 2:43 AM > > ||To: Muthu ArulMozhi Perumal (mperumal); Paul Kyzivat > (pkyzivat); Leon > > ||Portman > > ||Cc: siprec@ietf.org > > ||Subject: Re: [siprec] start/stop times& the metamodel > > || > > ||I don't think it is guaranteed that participants will > send SR reports > > ||(or any RTCP), plus we will also have to assume that the NTP=20 > > ||timestamps are in sync. We could mandate the SRC to generate SR=20 > > ||reports but then we are fixing the RTP model for > > |the SRC. > > || > > ||Regards, > > ||Henry > > || > > ||> -----Original Message----- > > ||> From: Muthu ArulMozhi Perumal (mperumal) > [mailto:mperumal@cisco.com] > > ||> Sent: Monday, April 11, 2011 10:45 PM > > ||> To: Henry Lum; Paul Kyzivat (pkyzivat); Leon Portman > > ||> Cc: siprec@ietf.org > > ||> Subject: RE: [siprec] start/stop times& the metamodel > > ||> > > ||> While I see it may be useful for the SRS to know when > certain things > > > > ||> happened in CS signaling (participant joining, > leaving, going mute > > ||etc) > > ||> I don't see how useful it would be for it know how > those things are > > ||> related to when the participant actually sent/received > (or stopped > > ||> sending/receiving) RTP. > > ||> > > ||> If we see any use, one way to do it is using the NTP timestamp > > ||> carried in RTCP SR reports, provided the SRC, SRS and the =20 > > ||> participants have access to the same reference wallclock. > > ||> > > ||> Muthu > > ||> > > ||> |-----Original Message----- > > ||> |From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On > > ||> Behalf Of Henry Lum > > ||> |Sent: Tuesday, April 12, 2011 2:56 AM > > ||> |To: Paul Kyzivat (pkyzivat); Leon Portman > > ||> |Cc: siprec@ietf.org > > ||> |Subject: Re: [siprec] start/stop times& the metamodel | |A=20 > > ||> related question on the RTP model is that if the > SRC as an RTP > > ||> |translator chooses to relay the RTP timestamps, then > how would the > > ||SRC > > ||> |synchronize the timestamps between the SIP messages > the multiple > > ||> |RTP streams? > > ||> | > > ||> |Henry > > ||> | > > ||> |> -----Original Message----- > > ||> |> From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On > > > > ||> |> Behalf Of Paul Kyzivat > > ||> |> Sent: Monday, April 11, 2011 1:06 PM |> To: Leon Portman > > ||> |> Cc: siprec@ietf.org |> Subject: Re: [siprec] start/stop=20 > > ||> times& the metamodel |> |> |> |> On 4/11/2011 9:36 AM,=20 > > ||> Leon Portman wrote: > > ||> |> > Paul Hi > > ||> |> > > > ||> |> > I agree with proposed method of time stamping > metadata elements > > ||> with > > ||> |> SRC clock (it is like a wall clock from the requirement > > document). > > ||> |> > About RTP time synchronization to metadata > events, we either > > ||> should > > ||> |> have some low latency event from SRC to SRS with > SRC time that > > ||> |> will allow SRS to maintain time difference between > its clock and > > ||> |> SRC > > ||> clock > > ||> |> and then apply it also to receive time of RTP > packet (assuming no > > ||> |> buffering) > > ||> |> > > ||> |> ISTM the issue isn't the latency of the event - it > is what it is > > ||> |> - > > ||> but > > ||> |> rather how to correlate a sip message containing > metadata with a > > ||> |> particular RTP packet. I suspect that needs to be > tied into the > > ||> |> discussion of the various models for how the SRC > might handle > > RDP. > > ||> |> > > ||> |> Thanks, > > ||> |> Paul > > ||> |> > > ||> |> > Leon > > ||> |> > > > ||> |> > -----Original Message----- |> > From:=20 > > ||> siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] > > ||> |> > On > > ||> |> Behalf Of Paul Kyzivat > > ||> |> > Sent: Monday, April 11, 2011 4:03 PM |> > To: Elwell, > > ||> John |> > Cc: siprec@ietf.org > > ||> |> > Subject: Re: [siprec] start/stop times& the metamodel > > ||> |> > > > ||> |> > > > ||> |> > > > ||> |> > On 4/8/2011 11:53 AM, Elwell, John wrote: > > ||> |> >> Paul, > > ||> |> >> > > ||> |> >> I think much of what you say makes sense. I > was concerned that > > ||we > > ||> |> probably need to record when a participant stops or starts > > ||> |> sending or |> receiving a stream, which seems to be=20 > > ||> covered by > your statement: > > ||> |> "Changes to media streams should similarly be > tagged with the > > ||> |> time > > ||> |they > > ||> |> occurred in the CS signaling. Each participant relationship > > ||> |> change (send, receive, inactive,) will be there." > That doesn't > > ||> |> seem to be > > ||> in > > ||> |> the model at present. > > ||> |> > > > ||> |> > John, > > ||> |> > > > ||> |> > I agree the current model doesn't reflect this > - it was a > > ||> |> > private > > ||> |> thought by me, provoked by the work and discussion > to date. It is > > > > ||> |> a > > ||> |bit > > ||> |> of a change of direction, so I'm interested in > what others think > > ||> about > > ||> |> it. > > ||> |> > > > ||> |> > Thanks, > > ||> |> > Paul > > ||> |> > > > ||> |> >> John (as individual) > > ||> |> >> > > ||> |> >> > > ||> |> >>> -----Original Message----- |> >>> From:=20 > > ||> siprec-bounces@ietf.org |> >>> =20 > > ||> [mailto:siprec-bounces@ietf.org] On Behalf Of > Paul Kyzivat > > ||> |> >>> Sent: 06 April 2011 22:28 |> >>> To:=20 > > ||> siprec@ietf.org > > ||> |> >>> Subject: [siprec] start/stop times& the metamodel > > ||> |> >>> > > ||> |> >>> In Prague, one of the open issues was around > start/stop > > times. > > ||> The > > ||> |> >>> format draft floated the possibility of > having explicit > > ||> start/stop > > ||> |> >>> times signaled for each of the metatdata > elements. But then > > ||> |> >>> we > > ||> |> asked > > ||> |> >>> for feedback on which make sense. > > ||> |> >>> > > ||> |> >>> IMO explicit start/stop times make more sense > for some things > > ||> than > > ||> |> >>> others. > > ||> |> >>> > > ||> |> >>> One place where we potentially have explicit > times to report > > ||> with > > ||> |> the > > ||> |> >>> dialogs that constitute a CS. Each such > dialog presumably has > > > > ||> |> >>> a > > ||> |> start > > ||> |> >>> and stop time observable by the SRC, which > might differ, at > > ||> least > > ||> |a > > ||> |> >>> bit, from the corresponding signaling on the RS. > > ||> |> >>> > > ||> |> >>> We might want to report those times. Or, > since we abstract > > ||> |> >>> the > > ||> CS > > ||> |> >>> away from the dialog, we might want to report > the start time > > ||> |> >>> of > > ||> |the > > ||> |> >>> first dialog in the CS as the CS start time, > and the stop > > ||> |> >>> time > > ||> of > > ||> |> the > > ||> |> >>> last dialog in the CS as the CS stop time. > > ||> |> >>> > > ||> |> >>> Similarly, we have abstracted media streams > away from the > > ||> |> >>> media streams in the sip dialogs that make up > the CS. We > > ||> |> >>> might want > > ||to > > ||> |> >>> report the start time of a media stream as the time =20 > > ||> |> >>> (according to |> the |> >>> CS) of the first=20 > > ||> participant to a new media > stream, and the > > ||stop > > ||> |> time > > ||> |> >>> as the time that the last participant leaves the media > > stream. > > ||> |> >>> > > ||> |> >>> There are several things that complicate this: > > ||> |> >>> > > ||> |> >>> - Do we consider the case of a stream that starts with > > recvonly > > ||> |> >>> or inactive participants, and only later > gets a sender? > > ||> |> >>> If > > ||> |so, > > ||> |> >>> is the start time of the stream when the first > > ||> |> >>> participant > > ||> |> arrived, > > ||> |> >>> or when the first sender arrived? > > ||> |> >>> > > ||> |> >>> - How do we get the clock times for the media streams? > > ||> |> >>> IIUC the correct ones are in the > RTP/RTCP, but the > > ||> reporting > > ||> |> of > > ||> |> >>> these events is driven by the signaling, > and we don't > > ||> |> >>> have > > ||> |> good > > ||> |> >>> sync between those. (E.g. media could > start flowing > > ||> |> >>> before > > ||> |the > > ||> |> >>> corresponding signaling, and we would > like to include > > ||> |> >>> that > > ||> if > > ||> |> we > > ||> |> >>> can figure it out.) So, even if the > clocks used for > > ||> |> >>> media > > ||> and > > ||> |> >>> signaling are in sync, we might see > media packets arrive > > ||> with > > ||> |> >>> a timestamp prior to the timestamp for > the signaling > > that > > ||> |> >>> indicates the send state of the > participant. This could > > ||> cause > > ||> |> >>> trouble in playback. > > ||> |> >>> > > ||> |> >>> - There isn't any guarantee that the clock > used for signaling > > ||> |> >>> messages is synchronized with the clock used in > > RTP/RTCP. > > ||> |> >>> > > ||> |> >>> - There isn't any guarantee that there will > be any RTCP at > > all, > > ||> |> >>> to provide correlation of the RTP to clocktime. > > ||> |> >>> > > ||> |> >>> The best I can see to deal with all of this is: > > ||> |> >>> > > ||> |> >>> - All the metadata messages should be > timestamped by the SRC > > ||> |> >>> using its local clock. This is easily > achieved by the > > Date > > ||> |> >>> header in the sip message. > > ||> |> >>> > > ||> |> >>> - Changes to a CS, including changes of > participants, should > > ||> |> >>> be explicitly tagged with the time they > occurred in the > > ||> |> >>> CS signaling, according to the SRC's > clock. (If that is > > ||> |> >>> unavailable for some reason, then use > the time the SRC > > ||> |> >>> became aware of it.) > > ||> |> >>> > > ||> |> >>> - We could provide a metadata update element > to indicate end > > ||> |> >>> of a CS, but I suggest this just be shorthand for > > ||> indicating > > ||> |> >>> removal of all participants from it. > (While its possible > > ||to > > ||> |> >>> mark that the CS is truly ended, that > simply introduces > > an > > ||> |> >>> error case if added metadata about it is > subsequently > > ||> sent.) > > ||> |> >>> The actual start/stop time would be > determined by the > > SRS > > ||> |> >>> based on the timestamps of first and > last data about it. > > ||> |> >>> > > ||> |> >>> - Changes to media streams should similarly > be tagged with > > ||> |> >>> the time they occurred in the CS signaling. Each > > ||> participant > > ||> |> >>> relationship change (send, receive, > inactive,) will be > > ||> there. > > ||> |> >>> The actual start/stop time of the media > stream again > > ||> |> >>> would > > ||> be > > ||> |> >>> derived by the SRS. > > ||> |> >>> > > ||> |> >>> - CS-Groups can simply be tagged by the > timestamps of the > > ||> |> >>> updates that put CSs into them. Explicit > start/stop > > ||> |> >>> times > > ||> |> don't > > ||> |> >>> seem useful. If desired, the SRS can > derive start/stop > > ||> times > > ||> |> >>> from the start/stop times of the contained stuff. > > ||> |> >>> > > ||> |> >>> - I now think that CS-Groups should not be > "contained" within > > ||> |> >>> a recording. This just seems to > introduce unnecessary > > ||error > > ||> |> >>> conditions, and limitations on future > enhancements. The > > ||> |> >>> lifetime of CS-Groups will probably be > naturally limited > > ||by > > ||> |> >>> the ability of the SRC to remember the > IDs of old ones. > > ||> |> >>> For instance, if a CS-G is created > during one Recording, > > ||> |> >>> and then another CS is added to it from > a different > > ||> recording > > ||> |> >>> session, would we prefer to fail that, > or just allow it? > > ||> |> >>> (I think allow.) > > ||> |> >>> > > ||> |> >>> - Rather, I think every update transmitted > during a recording > > ||> |> >>> session can be tagged with a link to the > metadata of the > > ||> |> >>> recording session it came from. This need not be > > ||> |> >>> explicit > > ||- > > ||> |> the > > ||> |> >>> SRS can do it automatically. The > recording session > > entity > > ||> |> >>> itself will also have a start/stop time > which is the > > ||start/ > > ||> |> >>> stop of the RS dialog as observed by the SRS. > > ||> |> >>> > > ||> |> >>> (Note the above doesn't solve the problem of > getting correct > > ||> clock > > ||> |> >>> times for RTP media. If anyone has a > suggestion for this I'm > > ||all > > ||> |> >>> ears.) > > ||> |> >>> > > ||> |> >>> Thanks, > > ||> |> >>> Paul > > ||> |> >>> _______________________________________________ > > ||> |> >>> siprec mailing 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 > > ||> | > > ||> | > > ||> > > > |||----------------------------------------------------------- > ---------- > > |||- > > ||> - > > ||> ------------------------------- > > ||> |------------- > > ||> |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=20 > > ||> hereby excluded. If you > are not the > > ||> intended recipient, please notify the |sender immediately,=20 > > ||> destroy the original transmission and its attachments and do=20 > > ||> not disclose the |contents to any other person, use it for any=20 > > ||> 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. > > ||> | > > ||> |_______________________________________________ > > ||> |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=20 > > ||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=20 > > |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. > > || > > ||_______________________________________________ > > ||siprec mailing 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 Thu Apr 14 05:18:41 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A3225E0735; Thu, 14 Apr 2011 05:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cjQgQ1fMi75e; Thu, 14 Apr 2011 05:18:40 -0700 (PDT) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfc.amsl.com (Postfix) with ESMTP id E6534E06E5; Thu, 14 Apr 2011 05:18:38 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Thu, 14 Apr 2011 15:18:37 +0300 From: Leon Portman To: "Elwell, John" , "Muthu ArulMozhi Perumal (mperumal)" , "ietf@ietf.org" Date: Thu, 14 Apr 2011 15:18:36 +0300 Thread-Topic: [siprec] Last Call: (Use Cases andRequirements for SIP-based Media Recording (SIPREC)) toInformational RFC Thread-Index: Acv0WYBeRuGjGNBtTZSHeqn78QP5xwGEv6YwAAlHtwAAAvtH0A== Message-ID: <07465C1D981ABC41A344374066AE1A2C38AB73D00B@TLVMBX01.nice.com> References: <20110406125020.17538.70016.idtracker@localhost> <1D062974A4845E4D8A343C65380492020533BB70@XMB-BGL-414.cisco.com> In-Reply-To: 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] Last Call: (Use Cases andRequirements for SIP-based Media Recording (SIPREC)) toInformational RFC X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 14 Apr 2011 12:18:41 -0000 Actually REQ-022 and REQ-023 describing not only requirement to synchronize= between different media streams but more importantly ability to relate the= m to real world (wall) clock. It is not only important to playback them cor= rectly but also to know when it was said. One example is continue trading after closing hour (even for one second is = not allowed) And if these media are synchronized to wall clock then they are also synchr= onized between them thus I am not sure if we need this additional requireme= nt. Thanks Leon -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Elwell, John Sent: Thursday, April 14, 2011 1:54 PM To: Muthu ArulMozhi Perumal (mperumal); ietf@ietf.org Cc: siprec@ietf.org Subject: Re: [siprec] Last Call: (Use Cases = andRequirements for SIP-based Media Recording (SIPREC)) toInformational RFC =20 > -----Original Message----- > From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On Behalf Of Muthu ArulMozhi Perumal=20 > (mperumal) > Sent: 14 April 2011 07:34 > To: ietf@ietf.org > Cc: siprec@ietf.org > Subject: Re: [siprec] Last Call:=20 > (Use Cases andRequirements for=20 > SIP-based Media Recording (SIPREC)) toInformational RFC >=20 > I've one major comment. It draft discusses synchronization between the=20 > recorded media streams and synchronized playback, which seem important=20 > for certain applications: >=20 > > Some applications require the recording of more than one media stream,=20 > possibly of different types. Media are synchronized, either at storage=20 > or at playback. > >=20 > However, in the requirements section it doesn't seem REQ-022 and=20 > REQ-023 are all that are need and sufficient to achieve this with=20 > needed precision. So, I would suggest adding another requirement as=20 > follows: > The mechanism MUST provide means for facilitating synchronization of=20 > the recorded media streams and metadata either at storage or at=20 > playback. > This includes, but not limited to, the information needed as per=20 > REQ-022 and REQ-023. [JRE] This seems a reasonable addition. I wonder if the new requirement (fi= rst sentence only) is sufficient as a **replacement** for REQ-022 and REQ-0= 23. On reading REQ-022 and REQ-023 again, it is not so clear what their pur= pose was, and they seem to be more like a solution than a requirement. One = purpose would certainly be that covered by Muthu's new requirement. Was the= re any other purpose? John >=20 > A nitpick: > Use Case 8 > In cases where calls inside or between branches must be recorded, a=20 > centralized recording system in data centers together with telephony=20 > infrastructure (e.g. PBX) me deployed. >=20 > s/me/may be >=20 > Muthu >=20 > |-----Original Message----- > |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of The IESG > |Sent: Wednesday, April 06, 2011 6:20 PM > |To: IETF-Announce > |Cc: siprec@ietf.org > |Subject: [siprec] Last Call: > (Use Cases > andRequirements for SIP-based > |Media Recording (SIPREC)) toInformational RFC > | > | > |The IESG has received a request from the SIP Recording WG (siprec) to=20 > |consider the following document: > |- 'Use Cases and Requirements for SIP-based Media Recording (SIPREC)' > | as an Informational RFC > | > |The IESG plans to make a decision in the next few weeks, and solicits=20 > |final comments on this action. Please send substantive > comments to the > |ietf@ietf.org mailing lists by 2011-04-20. Exceptionally, > comments may > be > |sent to iesg@ietf.org instead. In either case, please retain the=20 > |beginning of the Subject line to allow automated sorting. > | > |The file can be obtained via > |http://datatracker.ietf.org/doc/draft-ietf-siprec-req/ > | > |IESG discussion can be tracked via > |http://datatracker.ietf.org/doc/draft-ietf-siprec-req/ > | > | > | > |No IPR declarations have been submitted directly on this I-D. > |_______________________________________________ > |siprec mailing list > |siprec@ietf.org > |https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec >=20 _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From Leon.Portman@nice.com Thu Apr 14 05:22:50 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 49E97E06E5 for ; Thu, 14 Apr 2011 05:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HakcFa8b-YaY for ; Thu, 14 Apr 2011 05:22:47 -0700 (PDT) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfc.amsl.com (Postfix) with ESMTP id 2EC63E068E for ; Thu, 14 Apr 2011 05:22:47 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Thu, 14 Apr 2011 15:22:46 +0300 From: Leon Portman To: "Parthasarathi R (partr)" , "Elwell, John" , "Paul Kyzivat (pkyzivat)" Date: Thu, 14 Apr 2011 15:22:45 +0300 Thread-Topic: [siprec] start/stop times & the metamodel Thread-Index: Acv52n/qagzulBJoTT6O3oRm0wVyQwAuCnTQAAIbUlAAAON/wA== Message-ID: <07465C1D981ABC41A344374066AE1A2C38AB73D011@TLVMBX01.nice.com> References: <4D9CDADD.1020403@cisco.com><4DA2FC17.1060100@cisco.com><07465C1D981ABC41A344374066AE1A2C38AB6E1DE4@TLVMBX01.nice.com><4DA334F0.9050301@cisco.com><059AF07365DC474393A19A3AF187DF7406E67CB4@NAHALD.us.int.genesyslab.com><1D062974A4845E4D8A343C65380492020533B45B@XMB-BGL-414.cisco.com><059AF07365DC474393A19A3AF187DF7406EF2378@NAHALD.us.int.genesyslab.com><1D062974A4845E4D8A343C65380492020533B880@XMB-BGL-414.cisco.com><1D062974A4845E4D8A343C65380492020533B93C@XMB-BGL-414.cisco.com> <4DA59DF3.7020500@cisco.com> In-Reply-To: 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] start/stop times & the metamodel X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 14 Apr 2011 12:22:50 -0000 +1 Leon -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Parthasarathi R (partr) Sent: Thursday, April 14, 2011 3:11 PM To: Elwell, John; Paul Kyzivat (pkyzivat) Cc: siprec@ietf.org Subject: Re: [siprec] start/stop times & the metamodel John, Good summary on how reconstructed recorded media will look like. I'm of the= same opinion that storing or playback in SRS will exactly look like SRC wa= y of looking the media during the session. Media packet loss/delay in Recor= ding session (RS) is unavoidable in the loss environment and in case media = packet loss/delay is not desired during recording than Quos mechanism has t= o be used between RS which I guess it is outside the scope of SPIRE. Thanks Partha -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] Sent: Thursday, April 14, 2011 4:42 PM To: Paul Kyzivat (pkyzivat); Parthasarathi R (partr) Cc: siprec@ietf.org Subject: RE: [siprec] start/stop times & the metamodel I guess it depends what we are trying to capture here. Consider a 2-party c= all between A and B. First consider the case where the SRC is collocated with UA A. Do we wish t= o record the time A sends media and the time A receives media. Note that the time B receives media will be later than the time A sends it,= and the time B sends media will be earlier than the time A receives it. Wh= en reconstructing audio during playback, do we want to reconstruct the audi= o with synchronization between the two directions in accordance with what t= ook place at A or with what took place at B? Second, consider the case where the SRC is at a B2BUA. Here the times that = media pass through equate neither to the time that A sends and receives nor= the time that B sends and receives. So do we want to reconstruct the audio= as observed by the B2BUA, or what took place at A, or what took place at B= ? Another point is that for calls partly over TDM (PSTN), timings for what ha= ppens beyond the gateway will not be available. So it will not be possible = to reconstruct a conversation from the perspective of a user participating = via PSTN. It would be possible to simplify things and say that we record in a way tha= t what gets reconstructed on playback is what is observed at the point wher= e the SRC is located. Sure, this is a simplification, but trying to do anyt= hing else would be harder and still would not reflect what is observed by s= ome or all of the participants. If we assume this simplification, the only other point is trying to compens= ate for delays, or in particular differing delays, on the RS path. John (as individual) > -----Original Message----- > From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 13 April 2011 13:58 > To: Parthasarathi R (partr) > Cc: siprec@ietf.org > Subject: Re: [siprec] start/stop times & the metamodel > > > > On 4/13/2011 7:50 AM, Parthasarathi R (partr) wrote: > > Muthu, > > > > Even now, Media stream block attributes like start-time, end-time in > > metadata from SRC facilitates SRS to have synchronized > playback media in > > case SRS maps metadata from SRC with the received raw > media. Proposed > > requirement is going one level deeper wherein the timestamp > from SRC has > > to be based on RTP layer timestamp or SRC SIP signaling? > > > > IMO, SIP signaling serves the purpose and there is no need > of explicitly > > mention how SRC find start timestamp. In case you have > strong usecase > > for RTP timestamp based requirement, it requires changes in SIPREC > > requirement because it is specific mechanism insisted on SRC. > > Let me start out by saying that I don't know what the > answer(s) are here > - I have a very limited knowledge of RTP. > > The timestamps in the metadata (or in the sip messages that carry the > metadata) are a *piece* of the solution. How *sufficient* they are > remains to be seen - perhaps by demonstrating some procedures for > using them to achieve a useful playback result in various scenarios. > > The problem seems to be that even if a timestamp from the CS signaling > is passed in the metadata, its not clear how that can be synchronized > with RTP data arriving at the SRS. *Perhaps* its enough if you assume > that RTP packets will begin to arrive at the SRS concurrently with the > signaling that describes the corresponding stream. I'm certain that is > *not* true, but I don't know how *far* from true it is, or how much > that will vary based on scenario. > > It does seem to me that it is a mistake to standardize a mechanism > that > *depends* on such a shaky mechanism. (But a mechanism that uses this > as a fallback mechanism might make sense.) > > Thanks, > Paul > > > Thanks > > Partha > > > > -----Original Message----- > > From: Muthu ArulMozhi Perumal (mperumal) > > Sent: Wednesday, April 13, 2011 4:07 PM > > To: Parthasarathi R (partr); 'Henry Lum'; Paul Kyzivat > (pkyzivat); 'Leon > > Portman' > > Cc: 'siprec@ietf.org' > > Subject: RE: [siprec] start/stop times& the metamodel > > > > I don't think the requirements need to go to the level of > RTP timestamp. > > But it may be useful to add a requirement that the SRC needs to > > facilitate synchronized querying/playback of the recorded > media streams > > and metadata. I couldn't derive that directly from the > requirements we > > already have, but would like to hear from others if this is already > > implied. > > > > Muthu > > > > |-----Original Message----- > > |From: Parthasarathi R (partr) > > |Sent: Wednesday, April 13, 2011 2:46 PM > > |To: Muthu ArulMozhi Perumal (mperumal); 'Henry Lum'; Paul Kyzivat > > (pkyzivat); 'Leon Portman' > > |Cc: 'siprec@ietf.org' > > |Subject: RE: [siprec] start/stop times& the metamodel > > | > > |ISTM, SRC has to act only as RTP Endpoint or RTP Mixer (not RTP > > |translator) in case these requirement has to be considered within > > |SIPREC. IMO, these requirement has to be mentioned in SIPREC > > |requirement document to define the exact role what SRC > does with media > > timestamp and what SRS does with media timestamp? > > | > > |Thanks > > |Partha > > | > > |-----Original Message----- > > |From: Muthu ArulMozhi Perumal (mperumal) > > |Sent: Wednesday, April 13, 2011 12:36 PM > > |To: Parthasarathi R (partr); 'Henry Lum'; Paul Kyzivat (pkyzivat); > > 'Leon Portman' > > |Cc: 'siprec@ietf.org' > > |Subject: RE: [siprec] start/stop times& the metamodel > > | > > |After the use-case Paul described, it seem to me that if > we keep out of > > > > |scope it will put a lot of burden on the SRS to support > synchronized > > |querying/playback which looks an important aspect for > media recording. > > So, we may want to consider the ways in which the SRC can > facilitate it. > > | > > |Muthu > > | > > ||-----Original Message----- > > ||From: Parthasarathi R (partr) > > ||Sent: Wednesday, April 13, 2011 11:20 AM > > ||To: Henry Lum; Muthu ArulMozhi Perumal (mperumal); Paul Kyzivat > > ||(pkyzivat); Leon Portman > > ||Cc: siprec@ietf.org > > ||Subject: RE: [siprec] start/stop times& the metamodel > > || > > ||Henry, > > || > > ||I attached the follow up mail to below mail thread. Till > now, We don't > > > > ||have strong requirement to solve in SIPREC. Let us identify the > > ||requirement before going to the > > |solution. > > || > > ||Thanks > > ||Partha > > || > > ||-----Original Message----- > > ||From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > ||Behalf Of Henry Lum > > ||Sent: Wednesday, April 13, 2011 2:43 AM > > ||To: Muthu ArulMozhi Perumal (mperumal); Paul Kyzivat > (pkyzivat); Leon > > ||Portman > > ||Cc: siprec@ietf.org > > ||Subject: Re: [siprec] start/stop times& the metamodel > > || > > ||I don't think it is guaranteed that participants will > send SR reports > > ||(or any RTCP), plus we will also have to assume that the NTP > > ||timestamps are in sync. We could mandate the SRC to generate SR > > ||reports but then we are fixing the RTP model for > > |the SRC. > > || > > ||Regards, > > ||Henry > > || > > ||> -----Original Message----- > > ||> From: Muthu ArulMozhi Perumal (mperumal) > [mailto:mperumal@cisco.com] > > ||> Sent: Monday, April 11, 2011 10:45 PM > > ||> To: Henry Lum; Paul Kyzivat (pkyzivat); Leon Portman > > ||> Cc: siprec@ietf.org > > ||> Subject: RE: [siprec] start/stop times& the metamodel > > ||> > > ||> While I see it may be useful for the SRS to know when > certain things > > > > ||> happened in CS signaling (participant joining, > leaving, going mute > > ||etc) > > ||> I don't see how useful it would be for it know how > those things are > > ||> related to when the participant actually sent/received > (or stopped > > ||> sending/receiving) RTP. > > ||> > > ||> If we see any use, one way to do it is using the NTP timestamp > > ||> carried in RTCP SR reports, provided the SRC, SRS and the > > ||> participants have access to the same reference wallclock. > > ||> > > ||> Muthu > > ||> > > ||> |-----Original Message----- > > ||> |From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On > > ||> Behalf Of Henry Lum > > ||> |Sent: Tuesday, April 12, 2011 2:56 AM > > ||> |To: Paul Kyzivat (pkyzivat); Leon Portman > > ||> |Cc: siprec@ietf.org > > ||> |Subject: Re: [siprec] start/stop times& the metamodel | |A > > ||> related question on the RTP model is that if the > SRC as an RTP > > ||> |translator chooses to relay the RTP timestamps, then > how would the > > ||SRC > > ||> |synchronize the timestamps between the SIP messages > the multiple > > ||> |RTP streams? > > ||> | > > ||> |Henry > > ||> | > > ||> |> -----Original Message----- > > ||> |> From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On > > > > ||> |> Behalf Of Paul Kyzivat > > ||> |> Sent: Monday, April 11, 2011 1:06 PM |> To: Leon Portman > > ||> |> Cc: siprec@ietf.org |> Subject: Re: [siprec] start/stop > > ||> times& the metamodel |> |> |> |> On 4/11/2011 9:36 AM, > > ||> Leon Portman wrote: > > ||> |> > Paul Hi > > ||> |> > > > ||> |> > I agree with proposed method of time stamping > metadata elements > > ||> with > > ||> |> SRC clock (it is like a wall clock from the requirement > > document). > > ||> |> > About RTP time synchronization to metadata > events, we either > > ||> should > > ||> |> have some low latency event from SRC to SRS with > SRC time that > > ||> |> will allow SRS to maintain time difference between > its clock and > > ||> |> SRC > > ||> clock > > ||> |> and then apply it also to receive time of RTP > packet (assuming no > > ||> |> buffering) > > ||> |> > > ||> |> ISTM the issue isn't the latency of the event - it > is what it is > > ||> |> - > > ||> but > > ||> |> rather how to correlate a sip message containing > metadata with a > > ||> |> particular RTP packet. I suspect that needs to be > tied into the > > ||> |> discussion of the various models for how the SRC > might handle > > RDP. > > ||> |> > > ||> |> Thanks, > > ||> |> Paul > > ||> |> > > ||> |> > Leon > > ||> |> > > > ||> |> > -----Original Message----- |> > From: > > ||> siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] > > ||> |> > On > > ||> |> Behalf Of Paul Kyzivat > > ||> |> > Sent: Monday, April 11, 2011 4:03 PM |> > To: Elwell, > > ||> John |> > Cc: siprec@ietf.org > > ||> |> > Subject: Re: [siprec] start/stop times& the metamodel > > ||> |> > > > ||> |> > > > ||> |> > > > ||> |> > On 4/8/2011 11:53 AM, Elwell, John wrote: > > ||> |> >> Paul, > > ||> |> >> > > ||> |> >> I think much of what you say makes sense. I > was concerned that > > ||we > > ||> |> probably need to record when a participant stops or starts > > ||> |> sending or |> receiving a stream, which seems to be > > ||> covered by > your statement: > > ||> |> "Changes to media streams should similarly be > tagged with the > > ||> |> time > > ||> |they > > ||> |> occurred in the CS signaling. Each participant relationship > > ||> |> change (send, receive, inactive,) will be there." > That doesn't > > ||> |> seem to be > > ||> in > > ||> |> the model at present. > > ||> |> > > > ||> |> > John, > > ||> |> > > > ||> |> > I agree the current model doesn't reflect this > - it was a > > ||> |> > private > > ||> |> thought by me, provoked by the work and discussion > to date. It is > > > > ||> |> a > > ||> |bit > > ||> |> of a change of direction, so I'm interested in > what others think > > ||> about > > ||> |> it. > > ||> |> > > > ||> |> > Thanks, > > ||> |> > Paul > > ||> |> > > > ||> |> >> John (as individual) > > ||> |> >> > > ||> |> >> > > ||> |> >>> -----Original Message----- |> >>> From: > > ||> siprec-bounces@ietf.org |> >>> > > ||> [mailto:siprec-bounces@ietf.org] On Behalf Of > Paul Kyzivat > > ||> |> >>> Sent: 06 April 2011 22:28 |> >>> To: > > ||> siprec@ietf.org > > ||> |> >>> Subject: [siprec] start/stop times& the metamodel > > ||> |> >>> > > ||> |> >>> In Prague, one of the open issues was around > start/stop > > times. > > ||> The > > ||> |> >>> format draft floated the possibility of > having explicit > > ||> start/stop > > ||> |> >>> times signaled for each of the metatdata > elements. But then > > ||> |> >>> we > > ||> |> asked > > ||> |> >>> for feedback on which make sense. > > ||> |> >>> > > ||> |> >>> IMO explicit start/stop times make more sense > for some things > > ||> than > > ||> |> >>> others. > > ||> |> >>> > > ||> |> >>> One place where we potentially have explicit > times to report > > ||> with > > ||> |> the > > ||> |> >>> dialogs that constitute a CS. Each such > dialog presumably has > > > > ||> |> >>> a > > ||> |> start > > ||> |> >>> and stop time observable by the SRC, which > might differ, at > > ||> least > > ||> |a > > ||> |> >>> bit, from the corresponding signaling on the RS. > > ||> |> >>> > > ||> |> >>> We might want to report those times. Or, > since we abstract > > ||> |> >>> the > > ||> CS > > ||> |> >>> away from the dialog, we might want to report > the start time > > ||> |> >>> of > > ||> |the > > ||> |> >>> first dialog in the CS as the CS start time, > and the stop > > ||> |> >>> time > > ||> of > > ||> |> the > > ||> |> >>> last dialog in the CS as the CS stop time. > > ||> |> >>> > > ||> |> >>> Similarly, we have abstracted media streams > away from the > > ||> |> >>> media streams in the sip dialogs that make up > the CS. We > > ||> |> >>> might want > > ||to > > ||> |> >>> report the start time of a media stream as the time > > ||> |> >>> (according to |> the |> >>> CS) of the first > > ||> participant to a new media > stream, and the > > ||stop > > ||> |> time > > ||> |> >>> as the time that the last participant leaves the media > > stream. > > ||> |> >>> > > ||> |> >>> There are several things that complicate this: > > ||> |> >>> > > ||> |> >>> - Do we consider the case of a stream that starts with > > recvonly > > ||> |> >>> or inactive participants, and only later > gets a sender? > > ||> |> >>> If > > ||> |so, > > ||> |> >>> is the start time of the stream when the first > > ||> |> >>> participant > > ||> |> arrived, > > ||> |> >>> or when the first sender arrived? > > ||> |> >>> > > ||> |> >>> - How do we get the clock times for the media streams? > > ||> |> >>> IIUC the correct ones are in the > RTP/RTCP, but the > > ||> reporting > > ||> |> of > > ||> |> >>> these events is driven by the signaling, > and we don't > > ||> |> >>> have > > ||> |> good > > ||> |> >>> sync between those. (E.g. media could > start flowing > > ||> |> >>> before > > ||> |the > > ||> |> >>> corresponding signaling, and we would > like to include > > ||> |> >>> that > > ||> if > > ||> |> we > > ||> |> >>> can figure it out.) So, even if the > clocks used for > > ||> |> >>> media > > ||> and > > ||> |> >>> signaling are in sync, we might see > media packets arrive > > ||> with > > ||> |> >>> a timestamp prior to the timestamp for > the signaling > > that > > ||> |> >>> indicates the send state of the > participant. This could > > ||> cause > > ||> |> >>> trouble in playback. > > ||> |> >>> > > ||> |> >>> - There isn't any guarantee that the clock > used for signaling > > ||> |> >>> messages is synchronized with the clock used in > > RTP/RTCP. > > ||> |> >>> > > ||> |> >>> - There isn't any guarantee that there will > be any RTCP at > > all, > > ||> |> >>> to provide correlation of the RTP to clocktime. > > ||> |> >>> > > ||> |> >>> The best I can see to deal with all of this is: > > ||> |> >>> > > ||> |> >>> - All the metadata messages should be > timestamped by the SRC > > ||> |> >>> using its local clock. This is easily > achieved by the > > Date > > ||> |> >>> header in the sip message. > > ||> |> >>> > > ||> |> >>> - Changes to a CS, including changes of > participants, should > > ||> |> >>> be explicitly tagged with the time they > occurred in the > > ||> |> >>> CS signaling, according to the SRC's > clock. (If that is > > ||> |> >>> unavailable for some reason, then use > the time the SRC > > ||> |> >>> became aware of it.) > > ||> |> >>> > > ||> |> >>> - We could provide a metadata update element > to indicate end > > ||> |> >>> of a CS, but I suggest this just be shorthand for > > ||> indicating > > ||> |> >>> removal of all participants from it. > (While its possible > > ||to > > ||> |> >>> mark that the CS is truly ended, that > simply introduces > > an > > ||> |> >>> error case if added metadata about it is > subsequently > > ||> sent.) > > ||> |> >>> The actual start/stop time would be > determined by the > > SRS > > ||> |> >>> based on the timestamps of first and > last data about it. > > ||> |> >>> > > ||> |> >>> - Changes to media streams should similarly > be tagged with > > ||> |> >>> the time they occurred in the CS signaling. Each > > ||> participant > > ||> |> >>> relationship change (send, receive, > inactive,) will be > > ||> there. > > ||> |> >>> The actual start/stop time of the media > stream again > > ||> |> >>> would > > ||> be > > ||> |> >>> derived by the SRS. > > ||> |> >>> > > ||> |> >>> - CS-Groups can simply be tagged by the > timestamps of the > > ||> |> >>> updates that put CSs into them. Explicit > start/stop > > ||> |> >>> times > > ||> |> don't > > ||> |> >>> seem useful. If desired, the SRS can > derive start/stop > > ||> times > > ||> |> >>> from the start/stop times of the contained stuff. > > ||> |> >>> > > ||> |> >>> - I now think that CS-Groups should not be > "contained" within > > ||> |> >>> a recording. This just seems to > introduce unnecessary > > ||error > > ||> |> >>> conditions, and limitations on future > enhancements. The > > ||> |> >>> lifetime of CS-Groups will probably be > naturally limited > > ||by > > ||> |> >>> the ability of the SRC to remember the > IDs of old ones. > > ||> |> >>> For instance, if a CS-G is created > during one Recording, > > ||> |> >>> and then another CS is added to it from > a different > > ||> recording > > ||> |> >>> session, would we prefer to fail that, > or just allow it? > > ||> |> >>> (I think allow.) > > ||> |> >>> > > ||> |> >>> - Rather, I think every update transmitted > during a recording > > ||> |> >>> session can be tagged with a link to the > metadata of the > > ||> |> >>> recording session it came from. This need not be > > ||> |> >>> explicit > > ||- > > ||> |> the > > ||> |> >>> SRS can do it automatically. The > recording session > > entity > > ||> |> >>> itself will also have a start/stop time > which is the > > ||start/ > > ||> |> >>> stop of the RS dialog as observed by the SRS. > > ||> |> >>> > > ||> |> >>> (Note the above doesn't solve the problem of > getting correct > > ||> clock > > ||> |> >>> times for RTP media. If anyone has a > suggestion for this I'm > > ||all > > ||> |> >>> ears.) > > ||> |> >>> > > ||> |> >>> Thanks, > > ||> |> >>> Paul > > ||> |> >>> _______________________________________________ > > ||> |> >>> siprec mailing 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 > > ||> | > > ||> | > > ||> > > > |||----------------------------------------------------------- > ---------- > > |||- > > ||> - > > ||> ------------------------------- > > ||> |------------- > > ||> |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. > > ||> | > > ||> |_______________________________________________ > > ||> |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. > > || > > ||_______________________________________________ > > ||siprec mailing 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 Thu Apr 14 05:57:34 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D6657E068E; Thu, 14 Apr 2011 05:57:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.869 X-Spam-Level: X-Spam-Status: No, score=-104.869 tagged_above=-999 required=5 tests=[AWL=1.730, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fkkQG99ZXX7J; Thu, 14 Apr 2011 05:57:33 -0700 (PDT) Received: from mail174.messagelabs.com (mail174.messagelabs.com [85.158.138.51]) by ietfc.amsl.com (Postfix) with SMTP id 57451E065F; Thu, 14 Apr 2011 05:57:33 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1302785852!17056843!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 423 invoked from network); 14 Apr 2011 12:57:32 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-12.tower-174.messagelabs.com with SMTP; 14 Apr 2011 12:57:32 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 4D7B023F03DB; Thu, 14 Apr 2011 14:57:32 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 14 Apr 2011 14:57:32 +0200 From: "Elwell, John" To: Leon Portman , "Muthu ArulMozhi Perumal (mperumal)" , "ietf@ietf.org" Date: Thu, 14 Apr 2011 14:57:30 +0200 Thread-Topic: [siprec] Last Call: (Use Cases andRequirements for SIP-based Media Recording (SIPREC)) toInformational RFC Thread-Index: Acv0WYBeRuGjGNBtTZSHeqn78QP5xwGEv6YwAAlHtwAAAvtH0AABcMXA Message-ID: References: <20110406125020.17538.70016.idtracker@localhost> <1D062974A4845E4D8A343C65380492020533BB70@XMB-BGL-414.cisco.com> <07465C1D981ABC41A344374066AE1A2C38AB73D00B@TLVMBX01.nice.com> In-Reply-To: <07465C1D981ABC41A344374066AE1A2C38AB73D00B@TLVMBX01.nice.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] Last Call: (Use Cases andRequirements for SIP-based Media Recording (SIPREC)) toInformational RFC X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 14 Apr 2011 12:57:35 -0000 Understood, but if we have wall clock time for the start of a CS, wouldn't = that be sufficient? The new requirement would cover synchronization of all = media start/stops relative to that time. John (as individual) =20 > -----Original Message----- > From: Leon Portman [mailto:Leon.Portman@nice.com]=20 > Sent: 14 April 2011 13:19 > To: Elwell, John; Muthu ArulMozhi Perumal (mperumal); ietf@ietf.org > Cc: siprec@ietf.org > Subject: RE: [siprec] Last Call:=20 > (Use Cases andRequirements for=20 > SIP-based Media Recording (SIPREC)) toInformational RFC >=20 > Actually REQ-022 and REQ-023 describing not only requirement=20 > to synchronize between different media streams but more=20 > importantly ability to relate them to real world (wall)=20 > clock. It is not only important to playback them correctly=20 > but also to know when it was said. > One example is continue trading after closing hour (even for=20 > one second is not allowed) >=20 > And if these media are synchronized to wall clock then they=20 > are also synchronized between them thus I am not sure if we=20 > need this additional requirement. >=20 > Thanks >=20 > Leon >=20 > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > Sent: Thursday, April 14, 2011 1:54 PM > To: Muthu ArulMozhi Perumal (mperumal); ietf@ietf.org > Cc: siprec@ietf.org > Subject: Re: [siprec] Last Call:=20 > (Use Cases andRequirements for=20 > SIP-based Media Recording (SIPREC)) toInformational RFC >=20 >=20 > =20 >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf Of Muthu=20 > ArulMozhi Perumal=20 > > (mperumal) > > Sent: 14 April 2011 07:34 > > To: ietf@ietf.org > > Cc: siprec@ietf.org > > Subject: Re: [siprec] Last Call:=20 > > (Use Cases andRequirements for=20 > > SIP-based Media Recording (SIPREC)) toInformational RFC > >=20 > > I've one major comment. It draft discusses synchronization=20 > between the=20 > > recorded media streams and synchronized playback, which=20 > seem important=20 > > for certain applications: > >=20 > > > > Some applications require the recording of more than one=20 > media stream,=20 > > possibly of different types. Media are synchronized, either=20 > at storage=20 > > or at playback. > > > >=20 > > However, in the requirements section it doesn't seem REQ-022 and=20 > > REQ-023 are all that are need and sufficient to achieve this with=20 > > needed precision. So, I would suggest adding another requirement as=20 > > follows: > > The mechanism MUST provide means for facilitating=20 > synchronization of=20 > > the recorded media streams and metadata either at storage or at=20 > > playback. > > This includes, but not limited to, the information needed as per=20 > > REQ-022 and REQ-023. > [JRE] This seems a reasonable addition. I wonder if the new=20 > requirement (first sentence only) is sufficient as a=20 > **replacement** for REQ-022 and REQ-023. On reading REQ-022=20 > and REQ-023 again, it is not so clear what their purpose was,=20 > and they seem to be more like a solution than a requirement.=20 > One purpose would certainly be that covered by Muthu's new=20 > requirement. Was there any other purpose? >=20 > John >=20 > >=20 > > A nitpick: > > Use Case 8 > > In cases where calls inside or between branches must be recorded, a=20 > > centralized recording system in data centers together with=20 > telephony=20 > > infrastructure (e.g. PBX) me deployed. > >=20 > > s/me/may be > >=20 > > Muthu > >=20 > > |-----Original Message----- > > |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of The IESG > > |Sent: Wednesday, April 06, 2011 6:20 PM > > |To: IETF-Announce > > |Cc: siprec@ietf.org > > |Subject: [siprec] Last Call: > > (Use Cases > > andRequirements for SIP-based > > |Media Recording (SIPREC)) toInformational RFC > > | > > | > > |The IESG has received a request from the SIP Recording WG=20 > (siprec) to=20 > > |consider the following document: > > |- 'Use Cases and Requirements for SIP-based Media=20 > Recording (SIPREC)' > > | as an Informational RFC > > | > > |The IESG plans to make a decision in the next few weeks,=20 > and solicits=20 > > |final comments on this action. Please send substantive > > comments to the > > |ietf@ietf.org mailing lists by 2011-04-20. Exceptionally, > > comments may > > be > > |sent to iesg@ietf.org instead. In either case, please retain the=20 > > |beginning of the Subject line to allow automated sorting. > > | > > |The file can be obtained via > > |http://datatracker.ietf.org/doc/draft-ietf-siprec-req/ > > | > > |IESG discussion can be tracked via > > |http://datatracker.ietf.org/doc/draft-ietf-siprec-req/ > > | > > | > > | > > |No IPR declarations have been submitted directly on this I-D. > > |_______________________________________________ > > |siprec mailing list > > |siprec@ietf.org > > |https://www.ietf.org/mailman/listinfo/siprec > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > = From pkyzivat@cisco.com Thu Apr 14 06:26:53 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A43E1E089F for ; Thu, 14 Apr 2011 06:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.485 X-Spam-Level: X-Spam-Status: No, score=-110.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJYxtjwUHUUM for ; Thu, 14 Apr 2011 06:26:51 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfc.amsl.com (Postfix) with ESMTP id A6D4BE0896 for ; Thu, 14 Apr 2011 06:26:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=25437; q=dns/txt; s=iport; t=1302787610; x=1303997210; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=z3KIQBKRwDb2rU9yQH5lb2veyviD+0yov+5/KIoY2JM=; b=BQpVAPnmcbthErQej3TYWEb3kT0BTew8SJZmI/k0XkhbWX3h6p1FtOi/ IR78DfZgiWVt6edgFgS5qHY5RaXlRD2SIrdAk3MEYCrQd8SlhZYn3Fa5s SCaQyhsbQogy35m4P0Iz4F2ouEd1a2izt/M4A5S/MqUAFmhhAqCpTEj3o Y=; X-IronPort-AV: E=Sophos;i="4.64,211,1301875200"; d="scan'208";a="337221494" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by sj-iport-2.cisco.com with ESMTP; 14 Apr 2011 13:26:49 +0000 Received: from [161.44.174.125] (dhcp-161-44-174-125.cisco.com [161.44.174.125]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3EDQmae008868; Thu, 14 Apr 2011 13:26:49 GMT Message-ID: <4DA6F618.7080005@cisco.com> Date: Thu, 14 Apr 2011 09:26:48 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Elwell, John" References: <4D9CDADD.1020403@cisco.com> <4DA2FC17.1060100@cisco.com><07465C1D981ABC41A344374066AE1A2C38AB6E1DE4@TLVMBX01.nice.com><4DA334F0.9050301@cisco.com><059AF07365DC474393A19A3AF187DF7406E67CB4@NAHALD.us.int.genesyslab.com><1D062974A4845E4D8A343C65380492020533B45B@XMB-BGL-414.cisco.com> <059AF07365DC474393A19A3AF187DF7406EF2378@NAHALD.us.int.genesyslab.com> <1D062974A4845E4D8A343C65380492020533B880@XMB-BGL-414.cisco.com> <1D062974A4845E4D8A343C65380492020533B93C@XMB-BGL-414.cisco.com> <4DA59DF3.7020500@cisco.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] start/stop times & the metamodel X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 14 Apr 2011 13:26:53 -0000 On 4/14/2011 7:12 AM, Elwell, John wrote: > I guess it depends what we are trying to capture here. Consider a 2-party call between A and B. > > First consider the case where the SRC is collocated with UA A. Do we wish to record the time A sends media and the time A receives media. Note that the time B receives media will be later than the time A sends it, and the time B sends media will be earlier than the time A receives it. When reconstructing audio during playback, do we want to reconstruct the audio with synchronization between the two directions in accordance with what took place at A or with what took place at B? > > Second, consider the case where the SRC is at a B2BUA. Here the times that media pass through equate neither to the time that A sends and receives nor the time that B sends and receives. So do we want to reconstruct the audio as observed by the B2BUA, or what took place at A, or what took place at B? > > Another point is that for calls partly over TDM (PSTN), timings for what happens beyond the gateway will not be available. So it will not be possible to reconstruct a conversation from the perspective of a user participating via PSTN. > > It would be possible to simplify things and say that we record in a way that what gets reconstructed on playback is what is observed at the point where the SRC is located. Sure, this is a simplification, but trying to do anything else would be harder and still would not reflect what is observed by some or all of the participants. > > If we assume this simplification, the only other point is trying to compensate for delays, or in particular differing delays, on the RS path. I don't think we can legislate this. But maybe we can at least identify for the SRS what it is that it has. This depends a lot on the RTP model that is used for directing media to the SRS. For instance, in your first case: If A mixes the audio it receives from B with that it sends to B, in accord with the order it receives it from its mic and sends to its speaker, and clocks it all consistently, then the SRS will be able to play back a rendition as A heard it. If A simply clones the media stream it gets from B and the one it sends to A, and forwards the clones to the SRS, either as separate streams or as one stream with two SSRCs, then the SRS will have difficulty reconstructing things as heard by A, or by B. Its not so clear *what* it should do to play the two back in a reasonable way. If A, instead of cloning the stream from B itself, instead asks B to clone the stream and send a copy to the SRS, then things are again different. Similar situations apply in the second case. Thanks, Paul > John (as individual) > > >> -----Original Message----- >> From: siprec-bounces@ietf.org >> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: 13 April 2011 13:58 >> To: Parthasarathi R (partr) >> Cc: siprec@ietf.org >> Subject: Re: [siprec] start/stop times& the metamodel >> >> >> >> On 4/13/2011 7:50 AM, Parthasarathi R (partr) wrote: >>> Muthu, >>> >>> Even now, Media stream block attributes like start-time, end-time in >>> metadata from SRC facilitates SRS to have synchronized >> playback media in >>> case SRS maps metadata from SRC with the received raw >> media. Proposed >>> requirement is going one level deeper wherein the timestamp >> from SRC has >>> to be based on RTP layer timestamp or SRC SIP signaling? >>> >>> IMO, SIP signaling serves the purpose and there is no need >> of explicitly >>> mention how SRC find start timestamp. In case you have >> strong usecase >>> for RTP timestamp based requirement, it requires changes in SIPREC >>> requirement because it is specific mechanism insisted on SRC. >> >> Let me start out by saying that I don't know what the >> answer(s) are here >> - I have a very limited knowledge of RTP. >> >> The timestamps in the metadata (or in the sip messages that carry the >> metadata) are a *piece* of the solution. How *sufficient* they are >> remains to be seen - perhaps by demonstrating some procedures >> for using >> them to achieve a useful playback result in various scenarios. >> >> The problem seems to be that even if a timestamp from the CS >> signaling >> is passed in the metadata, its not clear how that can be synchronized >> with RTP data arriving at the SRS. *Perhaps* its enough if you assume >> that RTP packets will begin to arrive at the SRS concurrently >> with the >> signaling that describes the corresponding stream. I'm >> certain that is >> *not* true, but I don't know how *far* from true it is, or >> how much that >> will vary based on scenario. >> >> It does seem to me that it is a mistake to standardize a >> mechanism that >> *depends* on such a shaky mechanism. (But a mechanism that >> uses this as >> a fallback mechanism might make sense.) >> >> Thanks, >> Paul >> >>> Thanks >>> Partha >>> >>> -----Original Message----- >>> From: Muthu ArulMozhi Perumal (mperumal) >>> Sent: Wednesday, April 13, 2011 4:07 PM >>> To: Parthasarathi R (partr); 'Henry Lum'; Paul Kyzivat >> (pkyzivat); 'Leon >>> Portman' >>> Cc: 'siprec@ietf.org' >>> Subject: RE: [siprec] start/stop times& the metamodel >>> >>> I don't think the requirements need to go to the level of >> RTP timestamp. >>> But it may be useful to add a requirement that the SRC needs to >>> facilitate synchronized querying/playback of the recorded >> media streams >>> and metadata. I couldn't derive that directly from the >> requirements we >>> already have, but would like to hear from others if this is already >>> implied. >>> >>> Muthu >>> >>> |-----Original Message----- >>> |From: Parthasarathi R (partr) >>> |Sent: Wednesday, April 13, 2011 2:46 PM >>> |To: Muthu ArulMozhi Perumal (mperumal); 'Henry Lum'; Paul Kyzivat >>> (pkyzivat); 'Leon Portman' >>> |Cc: 'siprec@ietf.org' >>> |Subject: RE: [siprec] start/stop times& the metamodel >>> | >>> |ISTM, SRC has to act only as RTP Endpoint or RTP Mixer (not RTP >>> |translator) in case these requirement has to be considered within >>> |SIPREC. IMO, these requirement has to be mentioned in SIPREC >>> |requirement document to define the exact role what SRC >> does with media >>> timestamp and what SRS does with media timestamp? >>> | >>> |Thanks >>> |Partha >>> | >>> |-----Original Message----- >>> |From: Muthu ArulMozhi Perumal (mperumal) >>> |Sent: Wednesday, April 13, 2011 12:36 PM >>> |To: Parthasarathi R (partr); 'Henry Lum'; Paul Kyzivat (pkyzivat); >>> 'Leon Portman' >>> |Cc: 'siprec@ietf.org' >>> |Subject: RE: [siprec] start/stop times& the metamodel >>> | >>> |After the use-case Paul described, it seem to me that if >> we keep out of >>> >>> |scope it will put a lot of burden on the SRS to support >> synchronized >>> |querying/playback which looks an important aspect for >> media recording. >>> So, we may want to consider the ways in which the SRC can >> facilitate it. >>> | >>> |Muthu >>> | >>> ||-----Original Message----- >>> ||From: Parthasarathi R (partr) >>> ||Sent: Wednesday, April 13, 2011 11:20 AM >>> ||To: Henry Lum; Muthu ArulMozhi Perumal (mperumal); Paul Kyzivat >>> ||(pkyzivat); Leon Portman >>> ||Cc: siprec@ietf.org >>> ||Subject: RE: [siprec] start/stop times& the metamodel >>> || >>> ||Henry, >>> || >>> ||I attached the follow up mail to below mail thread. Till >> now, We don't >>> >>> ||have strong requirement to solve in SIPREC. Let us identify the >>> ||requirement before going to the >>> |solution. >>> || >>> ||Thanks >>> ||Partha >>> || >>> ||-----Original Message----- >>> ||From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>> ||Behalf Of Henry Lum >>> ||Sent: Wednesday, April 13, 2011 2:43 AM >>> ||To: Muthu ArulMozhi Perumal (mperumal); Paul Kyzivat >> (pkyzivat); Leon >>> ||Portman >>> ||Cc: siprec@ietf.org >>> ||Subject: Re: [siprec] start/stop times& the metamodel >>> || >>> ||I don't think it is guaranteed that participants will >> send SR reports >>> ||(or any RTCP), plus we will also have to assume that the NTP >>> ||timestamps are in sync. We could mandate the SRC to generate SR >>> ||reports but then we are fixing the RTP model for >>> |the SRC. >>> || >>> ||Regards, >>> ||Henry >>> || >>> ||> -----Original Message----- >>> ||> From: Muthu ArulMozhi Perumal (mperumal) >> [mailto:mperumal@cisco.com] >>> ||> Sent: Monday, April 11, 2011 10:45 PM >>> ||> To: Henry Lum; Paul Kyzivat (pkyzivat); Leon Portman >>> ||> Cc: siprec@ietf.org >>> ||> Subject: RE: [siprec] start/stop times& the metamodel >>> ||> >>> ||> While I see it may be useful for the SRS to know when >> certain things >>> >>> ||> happened in CS signaling (participant joining, >> leaving, going mute >>> ||etc) >>> ||> I don't see how useful it would be for it know how >> those things are >>> ||> related to when the participant actually sent/received >> (or stopped >>> ||> sending/receiving) RTP. >>> ||> >>> ||> If we see any use, one way to do it is using the NTP timestamp >>> ||> carried in RTCP SR reports, provided the SRC, SRS and the >>> ||> participants have access to the same reference wallclock. >>> ||> >>> ||> Muthu >>> ||> >>> ||> |-----Original Message----- >>> ||> |From: siprec-bounces@ietf.org >> [mailto:siprec-bounces@ietf.org] On >>> ||> Behalf Of Henry Lum >>> ||> |Sent: Tuesday, April 12, 2011 2:56 AM >>> ||> |To: Paul Kyzivat (pkyzivat); Leon Portman >>> ||> |Cc: siprec@ietf.org >>> ||> |Subject: Re: [siprec] start/stop times& the metamodel >>> ||> | >>> ||> |A related question on the RTP model is that if the >> SRC as an RTP >>> ||> |translator chooses to relay the RTP timestamps, then >> how would the >>> ||SRC >>> ||> |synchronize the timestamps between the SIP messages >> the multiple >>> ||> |RTP streams? >>> ||> | >>> ||> |Henry >>> ||> | >>> ||> |> -----Original Message----- >>> ||> |> From: siprec-bounces@ietf.org >> [mailto:siprec-bounces@ietf.org] On >>> >>> ||> |> Behalf Of Paul Kyzivat >>> ||> |> Sent: Monday, April 11, 2011 1:06 PM >>> ||> |> To: Leon Portman >>> ||> |> Cc: siprec@ietf.org >>> ||> |> Subject: Re: [siprec] start/stop times& the metamodel >>> ||> |> >>> ||> |> >>> ||> |> >>> ||> |> On 4/11/2011 9:36 AM, Leon Portman wrote: >>> ||> |> > Paul Hi >>> ||> |> > >>> ||> |> > I agree with proposed method of time stamping >> metadata elements >>> ||> with >>> ||> |> SRC clock (it is like a wall clock from the requirement >>> document). >>> ||> |> > About RTP time synchronization to metadata >> events, we either >>> ||> should >>> ||> |> have some low latency event from SRC to SRS with >> SRC time that >>> ||> |> will allow SRS to maintain time difference between >> its clock and >>> ||> |> SRC >>> ||> clock >>> ||> |> and then apply it also to receive time of RTP >> packet (assuming no >>> ||> |> buffering) >>> ||> |> >>> ||> |> ISTM the issue isn't the latency of the event - it >> is what it is >>> ||> |> - >>> ||> but >>> ||> |> rather how to correlate a sip message containing >> metadata with a >>> ||> |> particular RTP packet. I suspect that needs to be >> tied into the >>> ||> |> discussion of the various models for how the SRC >> might handle >>> RDP. >>> ||> |> >>> ||> |> Thanks, >>> ||> |> Paul >>> ||> |> >>> ||> |> > Leon >>> ||> |> > >>> ||> |> > -----Original Message----- >>> ||> |> > From: siprec-bounces@ietf.org >> [mailto:siprec-bounces@ietf.org] >>> ||> |> > On >>> ||> |> Behalf Of Paul Kyzivat >>> ||> |> > Sent: Monday, April 11, 2011 4:03 PM >>> ||> |> > To: Elwell, John >>> ||> |> > Cc: siprec@ietf.org >>> ||> |> > Subject: Re: [siprec] start/stop times& the metamodel >>> ||> |> > >>> ||> |> > >>> ||> |> > >>> ||> |> > On 4/8/2011 11:53 AM, Elwell, John wrote: >>> ||> |> >> Paul, >>> ||> |> >> >>> ||> |> >> I think much of what you say makes sense. I >> was concerned that >>> ||we >>> ||> |> probably need to record when a participant stops or starts >>> ||> |> sending >>> ||> or >>> ||> |> receiving a stream, which seems to be covered by >> your statement: >>> ||> |> "Changes to media streams should similarly be >> tagged with the >>> ||> |> time >>> ||> |they >>> ||> |> occurred in the CS signaling. Each participant relationship >>> ||> |> change (send, receive, inactive,) will be there." >> That doesn't >>> ||> |> seem to be >>> ||> in >>> ||> |> the model at present. >>> ||> |> > >>> ||> |> > John, >>> ||> |> > >>> ||> |> > I agree the current model doesn't reflect this >> - it was a >>> ||> |> > private >>> ||> |> thought by me, provoked by the work and discussion >> to date. It is >>> >>> ||> |> a >>> ||> |bit >>> ||> |> of a change of direction, so I'm interested in >> what others think >>> ||> about >>> ||> |> it. >>> ||> |> > >>> ||> |> > Thanks, >>> ||> |> > Paul >>> ||> |> > >>> ||> |> >> John (as individual) >>> ||> |> >> >>> ||> |> >> >>> ||> |> >>> -----Original Message----- >>> ||> |> >>> From: siprec-bounces@ietf.org >>> ||> |> >>> [mailto:siprec-bounces@ietf.org] On Behalf Of >> Paul Kyzivat >>> ||> |> >>> Sent: 06 April 2011 22:28 >>> ||> |> >>> To: siprec@ietf.org >>> ||> |> >>> Subject: [siprec] start/stop times& the metamodel >>> ||> |> >>> >>> ||> |> >>> In Prague, one of the open issues was around >> start/stop >>> times. >>> ||> The >>> ||> |> >>> format draft floated the possibility of >> having explicit >>> ||> start/stop >>> ||> |> >>> times signaled for each of the metatdata >> elements. But then >>> ||> |> >>> we >>> ||> |> asked >>> ||> |> >>> for feedback on which make sense. >>> ||> |> >>> >>> ||> |> >>> IMO explicit start/stop times make more sense >> for some things >>> ||> than >>> ||> |> >>> others. >>> ||> |> >>> >>> ||> |> >>> One place where we potentially have explicit >> times to report >>> ||> with >>> ||> |> the >>> ||> |> >>> dialogs that constitute a CS. Each such >> dialog presumably has >>> >>> ||> |> >>> a >>> ||> |> start >>> ||> |> >>> and stop time observable by the SRC, which >> might differ, at >>> ||> least >>> ||> |a >>> ||> |> >>> bit, from the corresponding signaling on the RS. >>> ||> |> >>> >>> ||> |> >>> We might want to report those times. Or, >> since we abstract >>> ||> |> >>> the >>> ||> CS >>> ||> |> >>> away from the dialog, we might want to report >> the start time >>> ||> |> >>> of >>> ||> |the >>> ||> |> >>> first dialog in the CS as the CS start time, >> and the stop >>> ||> |> >>> time >>> ||> of >>> ||> |> the >>> ||> |> >>> last dialog in the CS as the CS stop time. >>> ||> |> >>> >>> ||> |> >>> Similarly, we have abstracted media streams >> away from the >>> ||> |> >>> media streams in the sip dialogs that make up >> the CS. We >>> ||> |> >>> might want >>> ||to >>> ||> |> >>> report the start time of a media stream as the time >>> ||> |> >>> (according >>> ||> to >>> ||> |> the >>> ||> |> >>> CS) of the first participant to a new media >> stream, and the >>> ||stop >>> ||> |> time >>> ||> |> >>> as the time that the last participant leaves the media >>> stream. >>> ||> |> >>> >>> ||> |> >>> There are several things that complicate this: >>> ||> |> >>> >>> ||> |> >>> - Do we consider the case of a stream that starts with >>> recvonly >>> ||> |> >>> or inactive participants, and only later >> gets a sender? >>> ||> |> >>> If >>> ||> |so, >>> ||> |> >>> is the start time of the stream when the first >>> ||> |> >>> participant >>> ||> |> arrived, >>> ||> |> >>> or when the first sender arrived? >>> ||> |> >>> >>> ||> |> >>> - How do we get the clock times for the media streams? >>> ||> |> >>> IIUC the correct ones are in the >> RTP/RTCP, but the >>> ||> reporting >>> ||> |> of >>> ||> |> >>> these events is driven by the signaling, >> and we don't >>> ||> |> >>> have >>> ||> |> good >>> ||> |> >>> sync between those. (E.g. media could >> start flowing >>> ||> |> >>> before >>> ||> |the >>> ||> |> >>> corresponding signaling, and we would >> like to include >>> ||> |> >>> that >>> ||> if >>> ||> |> we >>> ||> |> >>> can figure it out.) So, even if the >> clocks used for >>> ||> |> >>> media >>> ||> and >>> ||> |> >>> signaling are in sync, we might see >> media packets arrive >>> ||> with >>> ||> |> >>> a timestamp prior to the timestamp for >> the signaling >>> that >>> ||> |> >>> indicates the send state of the >> participant. This could >>> ||> cause >>> ||> |> >>> trouble in playback. >>> ||> |> >>> >>> ||> |> >>> - There isn't any guarantee that the clock >> used for signaling >>> ||> |> >>> messages is synchronized with the clock used in >>> RTP/RTCP. >>> ||> |> >>> >>> ||> |> >>> - There isn't any guarantee that there will >> be any RTCP at >>> all, >>> ||> |> >>> to provide correlation of the RTP to clocktime. >>> ||> |> >>> >>> ||> |> >>> The best I can see to deal with all of this is: >>> ||> |> >>> >>> ||> |> >>> - All the metadata messages should be >> timestamped by the SRC >>> ||> |> >>> using its local clock. This is easily >> achieved by the >>> Date >>> ||> |> >>> header in the sip message. >>> ||> |> >>> >>> ||> |> >>> - Changes to a CS, including changes of >> participants, should >>> ||> |> >>> be explicitly tagged with the time they >> occurred in the >>> ||> |> >>> CS signaling, according to the SRC's >> clock. (If that is >>> ||> |> >>> unavailable for some reason, then use >> the time the SRC >>> ||> |> >>> became aware of it.) >>> ||> |> >>> >>> ||> |> >>> - We could provide a metadata update element >> to indicate end >>> ||> |> >>> of a CS, but I suggest this just be shorthand for >>> ||> indicating >>> ||> |> >>> removal of all participants from it. >> (While its possible >>> ||to >>> ||> |> >>> mark that the CS is truly ended, that >> simply introduces >>> an >>> ||> |> >>> error case if added metadata about it is >> subsequently >>> ||> sent.) >>> ||> |> >>> The actual start/stop time would be >> determined by the >>> SRS >>> ||> |> >>> based on the timestamps of first and >> last data about it. >>> ||> |> >>> >>> ||> |> >>> - Changes to media streams should similarly >> be tagged with >>> ||> |> >>> the time they occurred in the CS signaling. Each >>> ||> participant >>> ||> |> >>> relationship change (send, receive, >> inactive,) will be >>> ||> there. >>> ||> |> >>> The actual start/stop time of the media >> stream again >>> ||> |> >>> would >>> ||> be >>> ||> |> >>> derived by the SRS. >>> ||> |> >>> >>> ||> |> >>> - CS-Groups can simply be tagged by the >> timestamps of the >>> ||> |> >>> updates that put CSs into them. Explicit >> start/stop >>> ||> |> >>> times >>> ||> |> don't >>> ||> |> >>> seem useful. If desired, the SRS can >> derive start/stop >>> ||> times >>> ||> |> >>> from the start/stop times of the contained stuff. >>> ||> |> >>> >>> ||> |> >>> - I now think that CS-Groups should not be >> "contained" within >>> ||> |> >>> a recording. This just seems to >> introduce unnecessary >>> ||error >>> ||> |> >>> conditions, and limitations on future >> enhancements. The >>> ||> |> >>> lifetime of CS-Groups will probably be >> naturally limited >>> ||by >>> ||> |> >>> the ability of the SRC to remember the >> IDs of old ones. >>> ||> |> >>> For instance, if a CS-G is created >> during one Recording, >>> ||> |> >>> and then another CS is added to it from >> a different >>> ||> recording >>> ||> |> >>> session, would we prefer to fail that, >> or just allow it? >>> ||> |> >>> (I think allow.) >>> ||> |> >>> >>> ||> |> >>> - Rather, I think every update transmitted >> during a recording >>> ||> |> >>> session can be tagged with a link to the >> metadata of the >>> ||> |> >>> recording session it came from. This need not be >>> ||> |> >>> explicit >>> ||- >>> ||> |> the >>> ||> |> >>> SRS can do it automatically. The >> recording session >>> entity >>> ||> |> >>> itself will also have a start/stop time >> which is the >>> ||start/ >>> ||> |> >>> stop of the RS dialog as observed by the SRS. >>> ||> |> >>> >>> ||> |> >>> (Note the above doesn't solve the problem of >> getting correct >>> ||> clock >>> ||> |> >>> times for RTP media. If anyone has a >> suggestion for this I'm >>> ||all >>> ||> |> >>> ears.) >>> ||> |> >>> >>> ||> |> >>> Thanks, >>> ||> |> >>> Paul >>> ||> |> >>> _______________________________________________ >>> ||> |> >>> siprec mailing 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 >>> ||> | >>> ||> | >>> ||> >>> >> |||----------------------------------------------------------- >> ---------- >>> |||- >>> ||> - >>> ||> ------------------------------- >>> ||> |------------- >>> ||> |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. >>> ||> | >>> ||> |_______________________________________________ >>> ||> |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. >>> || >>> ||_______________________________________________ >>> ||siprec mailing 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 Apr 14 08:54:52 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id EAEECE0743 for ; Thu, 14 Apr 2011 08:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.897 X-Spam-Level: X-Spam-Status: No, score=-104.897 tagged_above=-999 required=5 tests=[AWL=1.702, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oY136WPalUeq for ; Thu, 14 Apr 2011 08:54:52 -0700 (PDT) Received: from mail182.messagelabs.com (mail182.messagelabs.com [85.158.139.83]) by ietfc.amsl.com (Postfix) with SMTP id DB689E06CD for ; Thu, 14 Apr 2011 08:54:51 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1302796490!5073470!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 14431 invoked from network); 14 Apr 2011 15:54:50 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-5.tower-182.messagelabs.com with SMTP; 14 Apr 2011 15:54:50 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id D05E61EB83E3; Thu, 14 Apr 2011 17:54:50 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 14 Apr 2011 17:54:50 +0200 From: "Elwell, John" To: "Ram Mohan R (rmohanr)" , "siprec@ietf.org" Date: Thu, 14 Apr 2011 17:54:50 +0200 Thread-Topic: [siprec] FW: New Version Notification for draft-ietf-siprec-metadata-00 Thread-Index: Acv52lvGIYs03fatSYyPgYBHHDW75wAAKWwAADhG+AA= Message-ID: References: <35BCE99A477D6A4986FB2216D8CF2CFD060098B4@XMB-BGL-417.cisco.com> Keywords: SIPREC In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD060098B4@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] FW: New Version Notification for draft-ietf-siprec-metadata-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, 14 Apr 2011 15:54:53 -0000 Thanks, Ram. It is now marked in the database as replacing draft-ram-siprec= -metadata, so it is easy to see the diff: https://datatracker.ietf.org/doc/draft-ietf-siprec-metadata/history/ John=20 > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Ram Mohan R (rmohanr) > Sent: 13 April 2011 14:08 > To: siprec@ietf.org > Subject: [siprec] FW: New Version Notification for=20 > draft-ietf-siprec-metadata-00 >=20 > Hi all, >=20 > I have submitted ver 00 of draft-ietf-siprec-metadata after=20 > addressing the comments agreed upon in IETF 80. Please see=20 > the mail here from John=20 > for details -=20 > http://www.ietf.org/mail-archive/web/siprec/current/msg01712.html >=20 > Pointer to the draft is=20 > https://datatracker.ietf.org/doc/draft-ietf-siprec-metadata/ >=20 > Please continue the discussions on the open items in the=20 > model in the mailer list. I will address the comments in the=20 > next version. >=20 > Regards, > Ram >=20 > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]=20 > Sent: Wednesday, April 13, 2011 6:27 PM > To: Ram Mohan R (rmohanr) > Cc: Parthasarathi R (partr); Paul Kyzivat (pkyzivat) > Subject: New Version Notification for draft-ietf-siprec-metadata-00=20 >=20 >=20 > A new version of I-D, draft-ietf-siprec-metadata-00.txt has=20 > been successfully submitted by Ram R and posted to the IETF=20 > repository. >=20 > Filename: draft-ietf-siprec-metadata > Revision: 00 > Title: Session Initiation Protocol (SIP)=20 > Recording Metadata > Creation_date: 2011-04-13 > WG ID: siprec > Number_of_pages: 23 >=20 > Abstract: > Session recording is a critical requirement in many communications > environments such as call centers and financial trading. In some of > these environments, all calls must be recorded for regulatory, > compliance, and consumer protection reasons. Recording of a session > is typically performed by sending a copy of a media stream to a > recording device. This document describes the metadata model as > viewed by Session Recording Server(SRS). > =20 > =20 >=20 >=20 > The IETF Secretariat. >=20 >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > = From Leon.Portman@nice.com Thu Apr 14 09:27:17 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 3FA32E08C9; Thu, 14 Apr 2011 09:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PNGVeY7KDeVj; Thu, 14 Apr 2011 09:27:16 -0700 (PDT) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfc.amsl.com (Postfix) with ESMTP id A1E46E08DA; Thu, 14 Apr 2011 09:27:12 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Thu, 14 Apr 2011 19:27:11 +0300 From: Leon Portman To: "Elwell, John" , "Muthu ArulMozhi Perumal (mperumal)" , "ietf@ietf.org" Date: Thu, 14 Apr 2011 19:27:10 +0300 Thread-Topic: [siprec] Last Call: (Use Cases andRequirements for SIP-based Media Recording (SIPREC)) toInformational RFC Thread-Index: Acv0WYBeRuGjGNBtTZSHeqn78QP5xwGEv6YwAAlHtwAAAvtH0AABcMXAAAdJn6A= Message-ID: <07465C1D981ABC41A344374066AE1A2C38AB73D110@TLVMBX01.nice.com> References: <20110406125020.17538.70016.idtracker@localhost> <1D062974A4845E4D8A343C65380492020533BB70@XMB-BGL-414.cisco.com> <07465C1D981ABC41A344374066AE1A2C38AB73D00B@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] Last Call: (Use Cases andRequirements for SIP-based Media Recording (SIPREC)) toInformational RFC X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 14 Apr 2011 16:27:17 -0000 I am not sure that having wall clock only for CS start is enough, especiall= y for partial metadata update. I will prefer to have on media level Leon -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 Sent: Thursday, April 14, 2011 3:58 PM To: Leon Portman; Muthu ArulMozhi Perumal (mperumal); ietf@ietf.org Cc: siprec@ietf.org Subject: RE: [siprec] Last Call: (Use Cases = andRequirements for SIP-based Media Recording (SIPREC)) toInformational RFC Understood, but if we have wall clock time for the start of a CS, wouldn't = that be sufficient? The new requirement would cover synchronization of all = media start/stops relative to that time. John (as individual) =20 > -----Original Message----- > From: Leon Portman [mailto:Leon.Portman@nice.com] > Sent: 14 April 2011 13:19 > To: Elwell, John; Muthu ArulMozhi Perumal (mperumal); ietf@ietf.org > Cc: siprec@ietf.org > Subject: RE: [siprec] Last Call:=20 > (Use Cases andRequirements for=20 > SIP-based Media Recording (SIPREC)) toInformational RFC >=20 > Actually REQ-022 and REQ-023 describing not only requirement to=20 > synchronize between different media streams but more importantly=20 > ability to relate them to real world (wall) clock. It is not only=20 > important to playback them correctly but also to know when it was=20 > said. > One example is continue trading after closing hour (even for one=20 > second is not allowed) >=20 > And if these media are synchronized to wall clock then they are also=20 > synchronized between them thus I am not sure if we need this=20 > additional requirement. >=20 > Thanks >=20 > Leon >=20 > -----Original Message----- > From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > Sent: Thursday, April 14, 2011 1:54 PM > To: Muthu ArulMozhi Perumal (mperumal); ietf@ietf.org > Cc: siprec@ietf.org > Subject: Re: [siprec] Last Call:=20 > (Use Cases andRequirements for=20 > SIP-based Media Recording (SIPREC)) toInformational RFC >=20 >=20 > =20 >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf Of Muthu > ArulMozhi Perumal > > (mperumal) > > Sent: 14 April 2011 07:34 > > To: ietf@ietf.org > > Cc: siprec@ietf.org > > Subject: Re: [siprec] Last Call:=20 > > (Use Cases andRequirements for=20 > > SIP-based Media Recording (SIPREC)) toInformational RFC > >=20 > > I've one major comment. It draft discusses synchronization > between the > > recorded media streams and synchronized playback, which > seem important > > for certain applications: > >=20 > > > > Some applications require the recording of more than one > media stream, > > possibly of different types. Media are synchronized, either > at storage > > or at playback. > > > >=20 > > However, in the requirements section it doesn't seem REQ-022 and > > REQ-023 are all that are need and sufficient to achieve this with=20 > > needed precision. So, I would suggest adding another requirement as > > follows: > > The mechanism MUST provide means for facilitating > synchronization of > > the recorded media streams and metadata either at storage or at=20 > > playback. > > This includes, but not limited to, the information needed as per > > REQ-022 and REQ-023. > [JRE] This seems a reasonable addition. I wonder if the new=20 > requirement (first sentence only) is sufficient as a > **replacement** for REQ-022 and REQ-023. On reading REQ-022 and=20 > REQ-023 again, it is not so clear what their purpose was, and they=20 > seem to be more like a solution than a requirement. > One purpose would certainly be that covered by Muthu's new=20 > requirement. Was there any other purpose? >=20 > John >=20 > >=20 > > A nitpick: > > Use Case 8 > > In cases where calls inside or between branches must be recorded, a=20 > > centralized recording system in data centers together with > telephony > > infrastructure (e.g. PBX) me deployed. > >=20 > > s/me/may be > >=20 > > Muthu > >=20 > > |-----Original Message----- > > |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of The IESG > > |Sent: Wednesday, April 06, 2011 6:20 PM > > |To: IETF-Announce > > |Cc: siprec@ietf.org > > |Subject: [siprec] Last Call: > > (Use Cases > > andRequirements for SIP-based > > |Media Recording (SIPREC)) toInformational RFC > > | > > | > > |The IESG has received a request from the SIP Recording WG > (siprec) to > > |consider the following document: > > |- 'Use Cases and Requirements for SIP-based Media > Recording (SIPREC)' > > | as an Informational RFC > > | > > |The IESG plans to make a decision in the next few weeks, > and solicits > > |final comments on this action. Please send substantive > > comments to the > > |ietf@ietf.org mailing lists by 2011-04-20. Exceptionally, > > comments may > > be > > |sent to iesg@ietf.org instead. In either case, please retain the=20 > > |beginning of the Subject line to allow automated sorting. > > | > > |The file can be obtained via > > |http://datatracker.ietf.org/doc/draft-ietf-siprec-req/ > > | > > |IESG discussion can be tracked via > > |http://datatracker.ietf.org/doc/draft-ietf-siprec-req/ > > | > > | > > | > > |No IPR declarations have been submitted directly on this I-D. > > |_______________________________________________ > > |siprec mailing 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 >=20 From rmohanr@cisco.com Thu Apr 14 09:42:45 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 22A02E079C; Thu, 14 Apr 2011 09:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.517 X-Spam-Level: X-Spam-Status: No, score=-10.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yt+FANOOE2vD; Thu, 14 Apr 2011 09:42:43 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfc.amsl.com (Postfix) with ESMTP id 2ED66E0663; Thu, 14 Apr 2011 09:42:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=7021; q=dns/txt; s=iport; t=1302799363; x=1304008963; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=6rUe3sEq4q/mACJdc92WAmc4p0YxXstExn5GPFIStGw=; b=mJsXDRQu1mfYueGrh0+2SgYlHp8ANlg218gJfXYMxzzR26m3TlIPg00o Zx5LpMvHWrUbGSc70v2uRRpFfS76emJ6MmdTJb9+drltcxmZrMIe8vm9S 4vgHesS8qxGwSXz/FfsbynMWVnSyD6fOIWJLuexGqOY300afJUBQm1GAm k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuQAAP8ip02Q/khNgWdsb2JhbACXeY19FAEBFiYlpEOcfoIhg00EhViMEQ X-IronPort-AV: E=Sophos;i="4.64,212,1301875200"; d="scan'208";a="25742336" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 14 Apr 2011 16:42:42 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3EGgfs1007873; Thu, 14 Apr 2011 16:42:41 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); Thu, 14 Apr 2011 22:12:40 +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, 14 Apr 2011 22:12:39 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD06009D00@XMB-BGL-417.cisco.com> In-Reply-To: <07465C1D981ABC41A344374066AE1A2C38AB73D110@TLVMBX01.nice.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Last Call: (Use Cases andRequirements for SIP-based MediaRecording (SIPREC)) toInformational RFC Thread-Index: Acv0WYBeRuGjGNBtTZSHeqn78QP5xwGEv6YwAAlHtwAAAvtH0AABcMXAAAdJn6AAAIZ7cA== References: <20110406125020.17538.70016.idtracker@localhost><1D062974A4845E4D8A343C65380492020533BB70@XMB-BGL-414.cisco.com><07465C1D981ABC41A344374066AE1A2C38AB73D00B@TLVMBX01.nice.com> <07465C1D981ABC41A344374066AE1A2C38AB73D110@TLVMBX01.nice.com> From: "Ram Mohan R (rmohanr)" To: "Leon Portman" , "Elwell, John" , "Muthu ArulMozhi Perumal (mperumal)" , X-OriginalArrivalTime: 14 Apr 2011 16:42:40.0734 (UTC) FILETIME=[F8587FE0:01CBFAC2] Cc: siprec@ietf.org Subject: Re: [siprec] Last Call: (Use Cases andRequirements for SIP-based MediaRecording (SIPREC)) toInformational RFC X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 14 Apr 2011 16:42:45 -0000 We already have attributes Start-Time / End-time in Media Stream block. This is for the same purpose to indicate the wall clock time for start/end of media. Ram > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Leon Portman > Sent: Thursday, April 14, 2011 9:57 PM > To: Elwell, John; Muthu ArulMozhi Perumal (mperumal); ietf@ietf.org > Cc: siprec@ietf.org > Subject: Re: [siprec] Last Call: (Use > Cases andRequirements for SIP-based MediaRecording (SIPREC)) > toInformational RFC >=20 > I am not sure that having wall clock only for CS start is enough, > especially for partial metadata update. I will prefer to have on media > level >=20 > Leon >=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Thursday, April 14, 2011 3:58 PM > To: Leon Portman; Muthu ArulMozhi Perumal (mperumal); ietf@ietf.org > Cc: siprec@ietf.org > Subject: RE: [siprec] Last Call: (Use > Cases andRequirements for SIP-based Media Recording (SIPREC)) > toInformational RFC >=20 > Understood, but if we have wall clock time for the start of a CS, > wouldn't that be sufficient? The new requirement would cover > synchronization of all media start/stops relative to that time. >=20 > John (as individual) >=20 >=20 > > -----Original Message----- > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > Sent: 14 April 2011 13:19 > > To: Elwell, John; Muthu ArulMozhi Perumal (mperumal); ietf@ietf.org > > Cc: siprec@ietf.org > > Subject: RE: [siprec] Last Call: > > (Use Cases andRequirements for > > SIP-based Media Recording (SIPREC)) toInformational RFC > > > > Actually REQ-022 and REQ-023 describing not only requirement to > > synchronize between different media streams but more importantly > > ability to relate them to real world (wall) clock. It is not only > > important to playback them correctly but also to know when it was > > said. > > One example is continue trading after closing hour (even for one > > second is not allowed) > > > > And if these media are synchronized to wall clock then they are also > > synchronized between them thus I am not sure if we need this > > additional requirement. > > > > Thanks > > > > Leon > > > > -----Original Message----- > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > > Sent: Thursday, April 14, 2011 1:54 PM > > To: Muthu ArulMozhi Perumal (mperumal); ietf@ietf.org > > Cc: siprec@ietf.org > > Subject: Re: [siprec] Last Call: > > (Use Cases andRequirements for > > SIP-based Media Recording (SIPREC)) toInformational RFC > > > > > > > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Muthu > > ArulMozhi Perumal > > > (mperumal) > > > Sent: 14 April 2011 07:34 > > > To: ietf@ietf.org > > > Cc: siprec@ietf.org > > > Subject: Re: [siprec] Last Call: > > > (Use Cases andRequirements for > > > SIP-based Media Recording (SIPREC)) toInformational RFC > > > > > > I've one major comment. It draft discusses synchronization > > between the > > > recorded media streams and synchronized playback, which > > seem important > > > for certain applications: > > > > > > > > > Some applications require the recording of more than one > > media stream, > > > possibly of different types. Media are synchronized, either > > at storage > > > or at playback. > > > > > > > > > However, in the requirements section it doesn't seem REQ-022 and > > > REQ-023 are all that are need and sufficient to achieve this with > > > needed precision. So, I would suggest adding another requirement as > > > follows: > > > The mechanism MUST provide means for facilitating > > synchronization of > > > the recorded media streams and metadata either at storage or at > > > playback. > > > This includes, but not limited to, the information needed as per > > > REQ-022 and REQ-023. > > [JRE] This seems a reasonable addition. I wonder if the new > > requirement (first sentence only) is sufficient as a > > **replacement** for REQ-022 and REQ-023. On reading REQ-022 and > > REQ-023 again, it is not so clear what their purpose was, and they > > seem to be more like a solution than a requirement. > > One purpose would certainly be that covered by Muthu's new > > requirement. Was there any other purpose? > > > > John > > > > > > > > A nitpick: > > > Use Case 8 > > > In cases where calls inside or between branches must be recorded, a > > > centralized recording system in data centers together with > > telephony > > > infrastructure (e.g. PBX) me deployed. > > > > > > s/me/may be > > > > > > Muthu > > > > > > |-----Original Message----- > > > |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > > Behalf Of The IESG > > > |Sent: Wednesday, April 06, 2011 6:20 PM > > > |To: IETF-Announce > > > |Cc: siprec@ietf.org > > > |Subject: [siprec] Last Call: > > > (Use Cases > > > andRequirements for SIP-based > > > |Media Recording (SIPREC)) toInformational RFC > > > | > > > | > > > |The IESG has received a request from the SIP Recording WG > > (siprec) to > > > |consider the following document: > > > |- 'Use Cases and Requirements for SIP-based Media > > Recording (SIPREC)' > > > | as an Informational RFC > > > | > > > |The IESG plans to make a decision in the next few weeks, > > and solicits > > > |final comments on this action. Please send substantive > > > comments to the > > > |ietf@ietf.org mailing lists by 2011-04-20. Exceptionally, > > > comments may > > > be > > > |sent to iesg@ietf.org instead. In either case, please retain the > > > |beginning of the Subject line to allow automated sorting. > > > | > > > |The file can be obtained via > > > |http://datatracker.ietf.org/doc/draft-ietf-siprec-req/ > > > | > > > |IESG discussion can be tracked via > > > |http://datatracker.ietf.org/doc/draft-ietf-siprec-req/ > > > | > > > | > > > | > > > |No IPR declarations have been submitted directly on this I-D. > > > |_______________________________________________ > > > |siprec mailing 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 mperumal@cisco.com Thu Apr 14 13:41:46 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9F486E07AB; Thu, 14 Apr 2011 13:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.099 X-Spam-Level: X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWcjnN-gUaZQ; Thu, 14 Apr 2011 13:41:45 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfc.amsl.com (Postfix) with ESMTP id 86D3BE075D; Thu, 14 Apr 2011 13:41:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=8285; q=dns/txt; s=iport; t=1302813704; x=1304023304; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=D3clFY1gSlqow6VkpWXOB40IUcfn9Z1iVHI5Yj1rh98=; b=MtD6N1FMxrL3M/1lIib6rbaZYmetvLnAIKEOW0+mAS9gQQuwv6YeCBeQ UCGg5DJdNROB0wM1VcGgKGI/rgUy9bA+CEEOwVMVxzlJlZqaV1+31sdZV rhAgOHDx/wfiOnWXrvdZlbnmtZk9Tl+OkXZNMqGejAd35iAhFwW8eKfh2 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAALpbp02Q/khNgWdsb2JhbACXfI19FAEBFiYlpjydCoIhg00EhViMEQ X-IronPort-AV: E=Sophos;i="4.64,213,1301875200"; d="scan'208";a="83637303" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 14 Apr 2011 20:41:43 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3EKfcwI024785; Thu, 14 Apr 2011 20:41:43 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 15 Apr 2011 02:11:38 +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: Fri, 15 Apr 2011 02:11:38 +0530 Message-ID: <1D062974A4845E4D8A343C65380492020533BD38@XMB-BGL-414.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD06009D00@XMB-BGL-417.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Last Call: (Use Cases andRequirements for SIP-based MediaRecording (SIPREC)) toInformational RFC Thread-Index: Acv0WYBeRuGjGNBtTZSHeqn78QP5xwGEv6YwAAlHtwAAAvtH0AABcMXAAAdJn6AAAIZ7cAAHjozg References: <20110406125020.17538.70016.idtracker@localhost><1D062974A4845E4D8A343C65380492020533BB70@XMB-BGL-414.cisco.com><07465C1D981ABC41A344374066AE1A2C38AB73D00B@TLVMBX01.nice.com> <07465C1D981ABC41A344374066AE1A2C38AB73D110@TLVMBX01.nice.com> <35BCE99A477D6A4986FB2216D8CF2CFD06009D00@XMB-BGL-417.cisco.com> From: "Muthu ArulMozhi Perumal (mperumal)" To: "Ram Mohan R (rmohanr)" , "Leon Portman" , "Elwell, John" , X-OriginalArrivalTime: 14 Apr 2011 20:41:38.0945 (UTC) FILETIME=[5A95DF10:01CBFAE4] Cc: siprec@ietf.org Subject: Re: [siprec] Last Call: (Use Cases andRequirements for SIP-based MediaRecording (SIPREC)) toInformational RFC X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 14 Apr 2011 20:41:46 -0000 I agree with John that these seem more like part of a solution rather than actual requirements. In addition, sending the wallclock time at media start/end alone may not suffice for achieving inter-media synchronization and playback, instead we may need to send the wallclock time periodically, like RTCP. For e.g, if there is a codec renegotiation in CS the RTP timestamp can restart from a random value. If silence suppression is enabled there would be gaps in the RTP timestamp.=20 These are things that need to be discussed as part of the solution -- the requirement itself should be generic enough, like what I described. REQ-022 and REQ-023 we have doesn't seem to clearly indicate the purpose. Muthu=20 |-----Original Message----- |From: Ram Mohan R (rmohanr) |Sent: Thursday, April 14, 2011 10:13 PM |To: Leon Portman; Elwell, John; Muthu ArulMozhi Perumal (mperumal); ietf@ietf.org |Cc: siprec@ietf.org |Subject: RE: [siprec] Last Call: (Use Cases andRequirements for SIP- |based MediaRecording (SIPREC)) toInformational RFC | |We already have attributes Start-Time / End-time in Media Stream block. This is for the same purpose |to indicate the wall clock time for start/end of media. | |Ram | |> -----Original Message----- |> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On |> Behalf Of Leon Portman |> Sent: Thursday, April 14, 2011 9:57 PM |> To: Elwell, John; Muthu ArulMozhi Perumal (mperumal); ietf@ietf.org |> Cc: siprec@ietf.org |> Subject: Re: [siprec] Last Call: (Use |> Cases andRequirements for SIP-based MediaRecording (SIPREC)) |> toInformational RFC |> |> I am not sure that having wall clock only for CS start is enough, |> especially for partial metadata update. I will prefer to have on media |> level |> |> Leon |> |> -----Original Message----- |> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] |> Sent: Thursday, April 14, 2011 3:58 PM |> To: Leon Portman; Muthu ArulMozhi Perumal (mperumal); ietf@ietf.org |> Cc: siprec@ietf.org |> Subject: RE: [siprec] Last Call: (Use |> Cases andRequirements for SIP-based Media Recording (SIPREC)) |> toInformational RFC |> |> Understood, but if we have wall clock time for the start of a CS, |> wouldn't that be sufficient? The new requirement would cover |> synchronization of all media start/stops relative to that time. |> |> John (as individual) |> |> |> > -----Original Message----- |> > From: Leon Portman [mailto:Leon.Portman@nice.com] |> > Sent: 14 April 2011 13:19 |> > To: Elwell, John; Muthu ArulMozhi Perumal (mperumal); ietf@ietf.org |> > Cc: siprec@ietf.org |> > Subject: RE: [siprec] Last Call: |> > (Use Cases andRequirements for |> > SIP-based Media Recording (SIPREC)) toInformational RFC |> > |> > Actually REQ-022 and REQ-023 describing not only requirement to |> > synchronize between different media streams but more importantly |> > ability to relate them to real world (wall) clock. It is not only |> > important to playback them correctly but also to know when it was |> > said. |> > One example is continue trading after closing hour (even for one |> > second is not allowed) |> > |> > And if these media are synchronized to wall clock then they are also |> > synchronized between them thus I am not sure if we need this |> > additional requirement. |> > |> > Thanks |> > |> > Leon |> > |> > -----Original Message----- |> > From: siprec-bounces@ietf.org |> > [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John |> > Sent: Thursday, April 14, 2011 1:54 PM |> > To: Muthu ArulMozhi Perumal (mperumal); ietf@ietf.org |> > Cc: siprec@ietf.org |> > Subject: Re: [siprec] Last Call: |> > (Use Cases andRequirements for |> > SIP-based Media Recording (SIPREC)) toInformational RFC |> > |> > |> > |> > |> > > -----Original Message----- |> > > From: siprec-bounces@ietf.org |> > > [mailto:siprec-bounces@ietf.org] On Behalf Of Muthu |> > ArulMozhi Perumal |> > > (mperumal) |> > > Sent: 14 April 2011 07:34 |> > > To: ietf@ietf.org |> > > Cc: siprec@ietf.org |> > > Subject: Re: [siprec] Last Call: |> > > (Use Cases andRequirements for |> > > SIP-based Media Recording (SIPREC)) toInformational RFC |> > > |> > > I've one major comment. It draft discusses synchronization |> > between the |> > > recorded media streams and synchronized playback, which |> > seem important |> > > for certain applications: |> > > |> > > |> > > Some applications require the recording of more than one |> > media stream, |> > > possibly of different types. Media are synchronized, either |> > at storage |> > > or at playback. |> > > |> > > |> > > However, in the requirements section it doesn't seem REQ-022 and |> > > REQ-023 are all that are need and sufficient to achieve this with |> > > needed precision. So, I would suggest adding another requirement as |> > > follows: |> > > The mechanism MUST provide means for facilitating |> > synchronization of |> > > the recorded media streams and metadata either at storage or at |> > > playback. |> > > This includes, but not limited to, the information needed as per |> > > REQ-022 and REQ-023. |> > [JRE] This seems a reasonable addition. I wonder if the new |> > requirement (first sentence only) is sufficient as a |> > **replacement** for REQ-022 and REQ-023. On reading REQ-022 and |> > REQ-023 again, it is not so clear what their purpose was, and they |> > seem to be more like a solution than a requirement. |> > One purpose would certainly be that covered by Muthu's new |> > requirement. Was there any other purpose? |> > |> > John |> > |> > > |> > > A nitpick: |> > > Use Case 8 |> > > In cases where calls inside or between branches must be recorded, a |> > > centralized recording system in data centers together with |> > telephony |> > > infrastructure (e.g. PBX) me deployed. |> > > |> > > s/me/may be |> > > |> > > Muthu |> > > |> > > |-----Original Message----- |> > > |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On |> > > Behalf Of The IESG |> > > |Sent: Wednesday, April 06, 2011 6:20 PM |> > > |To: IETF-Announce |> > > |Cc: siprec@ietf.org |> > > |Subject: [siprec] Last Call: |> > > (Use Cases |> > > andRequirements for SIP-based |> > > |Media Recording (SIPREC)) toInformational RFC |> > > | |> > > | |> > > |The IESG has received a request from the SIP Recording WG |> > (siprec) to |> > > |consider the following document: |> > > |- 'Use Cases and Requirements for SIP-based Media |> > Recording (SIPREC)' |> > > | as an Informational RFC |> > > | |> > > |The IESG plans to make a decision in the next few weeks, |> > and solicits |> > > |final comments on this action. Please send substantive |> > > comments to the |> > > |ietf@ietf.org mailing lists by 2011-04-20. Exceptionally, |> > > comments may |> > > be |> > > |sent to iesg@ietf.org instead. In either case, please retain the |> > > |beginning of the Subject line to allow automated sorting. |> > > | |> > > |The file can be obtained via |> > > |http://datatracker.ietf.org/doc/draft-ietf-siprec-req/ |> > > | |> > > |IESG discussion can be tracked via |> > > |http://datatracker.ietf.org/doc/draft-ietf-siprec-req/ |> > > | |> > > | |> > > | |> > > |No IPR declarations have been submitted directly on this I-D. |> > > |_______________________________________________ |> > > |siprec mailing 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 wwwrun@ietfc.amsl.com Thu Apr 14 15:24:57 2011 Return-Path: X-Original-To: siprec@ietf.org Delivered-To: siprec@ietfc.amsl.com Received: by ietfc.amsl.com (Postfix, from userid 30) id 8BC60E0665; Thu, 14 Apr 2011 15:24:57 -0700 (PDT) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110414222457.8BC60E0665@ietfc.amsl.com> Date: Thu, 14 Apr 2011 15:24:57 -0700 (PDT) Cc: siprec@ietf.org Subject: [siprec] SIPREC WG Virtual Interim Meeting, May 9, 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, 14 Apr 2011 22:24:57 -0000 The SIPREC WG will hold an interim virtual meeting on: 2011-05-09, 14.00-16.00 GMT Agenda and details will be announced on the SIPREC mailing list (http://www.ietf.org/mail-archive/web/siprec/) in due course. From eckelcu@cisco.com Thu Apr 14 16:29:21 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 87F42E06C4; Thu, 14 Apr 2011 16:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.393 X-Spam-Level: X-Spam-Status: No, score=-10.393 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9oCZkSyg6EoL; Thu, 14 Apr 2011 16:29:20 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfc.amsl.com (Postfix) with ESMTP id 88EDDE0794; Thu, 14 Apr 2011 16:29:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=9502; q=dns/txt; s=iport; t=1302823759; x=1304033359; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=QDdZ+c3W8XjRN73JvdYUW2cpG5YTakJDlJ4FqptvlS0=; b=hIy+YLmy1xQTW7W2yfJb7PsLSi8JcV7v7Iv0zrFDMWO+I7JGP9XhQagz nkWlqAAOHak2chLUul96Dl90W6KjjcEmU7B4QIclGF7QPS0U06OiPouqR dyacVOzbh2MhhT50TTuOY+K4r7vNlYAwfcF1XM+5IlbNdyoDqofLwXMUl c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al0BACSCp02rRDoG/2dsb2JhbACXf41+d6cnnHWCIYNNBIVajA8 X-IronPort-AV: E=Sophos;i="4.64,214,1301875200"; d="scan'208";a="337779740" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-2.cisco.com with ESMTP; 14 Apr 2011 23:29:18 +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 p3ENTIwS028622; Thu, 14 Apr 2011 23:29:18 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, 14 Apr 2011 16:29:18 -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, 14 Apr 2011 16:29:18 -0700 Message-ID: In-Reply-To: <1D062974A4845E4D8A343C65380492020533BD38@XMB-BGL-414.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Last Call:(Use Cases andRequirements forSIP-based MediaRecording (SIPREC)) toInformational RFC Thread-Index: Acv0WYBeRuGjGNBtTZSHeqn78QP5xwGEv6YwAAlHtwAAAvtH0AABcMXAAAdJn6AAAIZ7cAAHjozgAAa08QA= References: <20110406125020.17538.70016.idtracker@localhost><1D062974A4845E4D8A343C65380492020533BB70@XMB-BGL-414.cisco.com><07465C1D981ABC41A344374066AE1A2C38AB73D00B@TLVMBX01.nice.com><07465C1D981ABC41A344374066AE1A2C38AB73D110@TLVMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD06009D00@XMB-BGL-417.cisco.com> <1D062974A4845E4D8A343C65380492020533BD38@XMB-BGL-414.cisco.com> From: "Charles Eckel (eckelcu)" To: "Muthu ArulMozhi Perumal (mperumal)" , "Ram Mohan R (rmohanr)" , "Leon Portman" , "Elwell, John" , X-OriginalArrivalTime: 14 Apr 2011 23:29:18.0632 (UTC) FILETIME=[C6A04A80:01CBFAFB] Cc: siprec@ietf.org Subject: Re: [siprec] Last Call:(Use Cases andRequirements forSIP-based MediaRecording (SIPREC)) toInformational RFC X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 14 Apr 2011 23:29:21 -0000 I was thinking we needed a way to synchronize media from multiple CSs, which may be received by the SRS from one or more SRCs. Is this not a requirement? Thanks, Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Muthu ArulMozhi Perumal > (mperumal) > Sent: Thursday, April 14, 2011 1:42 PM > To: Ram Mohan R (rmohanr); Leon Portman; Elwell, John; ietf@ietf.org > Cc: siprec@ietf.org > Subject: Re: [siprec] Last Call:(Use Cases andRequirements forSIP-based > MediaRecording (SIPREC)) toInformational RFC >=20 > I agree with John that these seem more like part of a solution rather > than actual requirements. In addition, sending the wallclock time at > media start/end alone may not suffice for achieving inter-media > synchronization and playback, instead we may need to send the wallclock > time periodically, like RTCP. For e.g, if there is a codec renegotiation > in CS the RTP timestamp can restart from a random value. If silence > suppression is enabled there would be gaps in the RTP timestamp. >=20 > These are things that need to be discussed as part of the solution -- > the requirement itself should be generic enough, like what I described. > REQ-022 and REQ-023 we have doesn't seem to clearly indicate the > purpose. >=20 > Muthu >=20 > |-----Original Message----- > |From: Ram Mohan R (rmohanr) > |Sent: Thursday, April 14, 2011 10:13 PM > |To: Leon Portman; Elwell, John; Muthu ArulMozhi Perumal (mperumal); > ietf@ietf.org > |Cc: siprec@ietf.org > |Subject: RE: [siprec] Last Call: (Use > Cases andRequirements for SIP- > |based MediaRecording (SIPREC)) toInformational RFC > | > |We already have attributes Start-Time / End-time in Media Stream > block. This is for the same purpose > |to indicate the wall clock time for start/end of media. > | > |Ram > | > |> -----Original Message----- > |> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > |> Behalf Of Leon Portman > |> Sent: Thursday, April 14, 2011 9:57 PM > |> To: Elwell, John; Muthu ArulMozhi Perumal (mperumal); ietf@ietf.org > |> Cc: siprec@ietf.org > |> Subject: Re: [siprec] Last Call: (Use > |> Cases andRequirements for SIP-based MediaRecording (SIPREC)) > |> toInformational RFC > |> > |> I am not sure that having wall clock only for CS start is enough, > |> especially for partial metadata update. I will prefer to have on > media > |> level > |> > |> Leon > |> > |> -----Original Message----- > |> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > |> Sent: Thursday, April 14, 2011 3:58 PM > |> To: Leon Portman; Muthu ArulMozhi Perumal (mperumal); ietf@ietf.org > |> Cc: siprec@ietf.org > |> Subject: RE: [siprec] Last Call: (Use > |> Cases andRequirements for SIP-based Media Recording (SIPREC)) > |> toInformational RFC > |> > |> Understood, but if we have wall clock time for the start of a CS, > |> wouldn't that be sufficient? The new requirement would cover > |> synchronization of all media start/stops relative to that time. > |> > |> John (as individual) > |> > |> > |> > -----Original Message----- > |> > From: Leon Portman [mailto:Leon.Portman@nice.com] > |> > Sent: 14 April 2011 13:19 > |> > To: Elwell, John; Muthu ArulMozhi Perumal (mperumal); ietf@ietf.org > |> > Cc: siprec@ietf.org > |> > Subject: RE: [siprec] Last Call: > |> > (Use Cases andRequirements for > |> > SIP-based Media Recording (SIPREC)) toInformational RFC > |> > > |> > Actually REQ-022 and REQ-023 describing not only requirement to > |> > synchronize between different media streams but more importantly > |> > ability to relate them to real world (wall) clock. It is not only > |> > important to playback them correctly but also to know when it was > |> > said. > |> > One example is continue trading after closing hour (even for one > |> > second is not allowed) > |> > > |> > And if these media are synchronized to wall clock then they are > also > |> > synchronized between them thus I am not sure if we need this > |> > additional requirement. > |> > > |> > Thanks > |> > > |> > Leon > |> > > |> > -----Original Message----- > |> > From: siprec-bounces@ietf.org > |> > [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > |> > Sent: Thursday, April 14, 2011 1:54 PM > |> > To: Muthu ArulMozhi Perumal (mperumal); ietf@ietf.org > |> > Cc: siprec@ietf.org > |> > Subject: Re: [siprec] Last Call: > |> > (Use Cases andRequirements for > |> > SIP-based Media Recording (SIPREC)) toInformational RFC > |> > > |> > > |> > > |> > > |> > > -----Original Message----- > |> > > From: siprec-bounces@ietf.org > |> > > [mailto:siprec-bounces@ietf.org] On Behalf Of Muthu > |> > ArulMozhi Perumal > |> > > (mperumal) > |> > > Sent: 14 April 2011 07:34 > |> > > To: ietf@ietf.org > |> > > Cc: siprec@ietf.org > |> > > Subject: Re: [siprec] Last Call: > |> > > (Use Cases andRequirements for > |> > > SIP-based Media Recording (SIPREC)) toInformational RFC > |> > > > |> > > I've one major comment. It draft discusses synchronization > |> > between the > |> > > recorded media streams and synchronized playback, which > |> > seem important > |> > > for certain applications: > |> > > > |> > > > |> > > Some applications require the recording of more than one > |> > media stream, > |> > > possibly of different types. Media are synchronized, either > |> > at storage > |> > > or at playback. > |> > > > |> > > > |> > > However, in the requirements section it doesn't seem REQ-022 and > |> > > REQ-023 are all that are need and sufficient to achieve this with > |> > > needed precision. So, I would suggest adding another requirement > as > |> > > follows: > |> > > The mechanism MUST provide means for facilitating > |> > synchronization of > |> > > the recorded media streams and metadata either at storage or at > |> > > playback. > |> > > This includes, but not limited to, the information needed as per > |> > > REQ-022 and REQ-023. > |> > [JRE] This seems a reasonable addition. I wonder if the new > |> > requirement (first sentence only) is sufficient as a > |> > **replacement** for REQ-022 and REQ-023. On reading REQ-022 and > |> > REQ-023 again, it is not so clear what their purpose was, and they > |> > seem to be more like a solution than a requirement. > |> > One purpose would certainly be that covered by Muthu's new > |> > requirement. Was there any other purpose? > |> > > |> > John > |> > > |> > > > |> > > A nitpick: > |> > > Use Case 8 > |> > > In cases where calls inside or between branches must be recorded, > a > |> > > centralized recording system in data centers together with > |> > telephony > |> > > infrastructure (e.g. PBX) me deployed. > |> > > > |> > > s/me/may be > |> > > > |> > > Muthu > |> > > > |> > > |-----Original Message----- > |> > > |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] > On > |> > > Behalf Of The IESG > |> > > |Sent: Wednesday, April 06, 2011 6:20 PM > |> > > |To: IETF-Announce > |> > > |Cc: siprec@ietf.org > |> > > |Subject: [siprec] Last Call: > |> > > (Use Cases > |> > > andRequirements for SIP-based > |> > > |Media Recording (SIPREC)) toInformational RFC > |> > > | > |> > > | > |> > > |The IESG has received a request from the SIP Recording WG > |> > (siprec) to > |> > > |consider the following document: > |> > > |- 'Use Cases and Requirements for SIP-based Media > |> > Recording (SIPREC)' > |> > > | as an Informational RFC > |> > > | > |> > > |The IESG plans to make a decision in the next few weeks, > |> > and solicits > |> > > |final comments on this action. Please send substantive > |> > > comments to the > |> > > |ietf@ietf.org mailing lists by 2011-04-20. Exceptionally, > |> > > comments may > |> > > be > |> > > |sent to iesg@ietf.org instead. In either case, please retain the > |> > > |beginning of the Subject line to allow automated sorting. > |> > > | > |> > > |The file can be obtained via > |> > > |http://datatracker.ietf.org/doc/draft-ietf-siprec-req/ > |> > > | > |> > > |IESG discussion can be tracked via > |> > > |http://datatracker.ietf.org/doc/draft-ietf-siprec-req/ > |> > > | > |> > > | > |> > > | > |> > > |No IPR declarations have been submitted directly on this I-D. > |> > > |_______________________________________________ > |> > > |siprec mailing 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 partr@cisco.com Thu Apr 14 22:25:43 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id EB878E06E1; Thu, 14 Apr 2011 22:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.816 X-Spam-Level: X-Spam-Status: No, score=-9.816 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3jnbagFuGbM9; Thu, 14 Apr 2011 22:25:42 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfc.amsl.com (Postfix) with ESMTP id C53EBE0668; Thu, 14 Apr 2011 22:25:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=11456; q=dns/txt; s=iport; t=1302845142; x=1304054742; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=932S70tBg0lQU29j4pFRSSQ2cFcryBX7H511Ioj2CZ0=; b=j79DPE1lchdAUzevp3KhQF9JRAsN2FM4kLNIIIL5liOP28AtI7qjhqon AoSSsxUyfbVCds1HDVpxQhisbSJFU0LTCR7FSq5WrOw4FIk+Qlp+NV8Jt zIHsXMSAmUZGVLMSQ9FhuqBrXcmj8BCkjfNlx3KGKBqhNrQlAfJXiC+Mg I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtgAAEjWp02Q/khMgWdsb2JhbACYA41/FAEBFiYlqBqdBIIhXYJwBIVejBU X-IronPort-AV: E=Sophos;i="4.64,216,1301875200"; d="scan'208";a="25796408" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 15 Apr 2011 05:25:40 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3F5OxTN019517; Fri, 15 Apr 2011 05:25:40 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 15 Apr 2011 10:55: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: Fri, 15 Apr 2011 10:55:30 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] LastCall:(UseCases andRequirementsforSIP-basedMediaRecording (SIPREC)) toInformational RFC Thread-Index: Acv0WYBeRuGjGNBtTZSHeqn78QP5xwGEv6YwAAlHtwAAAvtH0AABcMXAAAdJn6AAAIZ7cAAHjozgAAa08QAACpF8MA== References: <20110406125020.17538.70016.idtracker@localhost><1D062974A4845E4D8A343C65380492020533BB70@XMB-BGL-414.cisco.com><07465C1D981ABC41A344374066AE1A2C38AB73D00B@TLVMBX01.nice.com><07465C1D981ABC41A344374066AE1A2C38AB73D110@TLVMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD06009D00@XMB-BGL-417.cisco.com><1D062974A4845E4D8A343C65380492020533BD38@XMB-BGL-414.cisco.com> From: "Parthasarathi R (partr)" To: "Charles Eckel (eckelcu)" , "Muthu ArulMozhi Perumal (mperumal)" , "Ram Mohan R (rmohanr)" , "Leon Portman" , "Elwell, John" , X-OriginalArrivalTime: 15 Apr 2011 05:25:31.0024 (UTC) FILETIME=[89908100:01CBFB2D] Cc: siprec@ietf.org Subject: Re: [siprec] LastCall:(UseCases andRequirementsforSIP-basedMediaRecording (SIPREC)) toInformational RFC X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 15 Apr 2011 05:25:44 -0000 Charles, synchronize multiple CS from multiple SRCs to single SRS is outside the scope of SIPREC. I'm not very clear about the requirement of media synchronization for multiple CS from single SRC because each CS have its own media stream, is there any need to synchronize between multiple CS? Muthu, I'm seeing two requirement here: 1) Timestamp synchronization between metadata and media stream. This is possible to be achieved by current metadata media stream start& stop time wherein media packet shall be stored or played back with the reference to start time of media stream block. Say Media stream start time as T0 and end time as T1, the first media packet is received at T0+ t[i] wherein t[i] is the time interval between T0 and first media packet. Here T0+t[i] is always less than T1. Playback shall use T0 as the reference value. Here there is no need of extra time reference required. 2) Timestamp synchronization between multiple media stream (audio + video) New requirement is to synchronize between media stream and there is need to identify the detailed requirement. Infact, I'm still not very much clear which may be due to my lack of specific details about audio+Video recording. Please correct in case I'm missing something. Thanks Partha -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Charles Eckel (eckelcu) Sent: Friday, April 15, 2011 4:59 AM To: Muthu ArulMozhi Perumal (mperumal); Ram Mohan R (rmohanr); Leon Portman; Elwell, John; ietf@ietf.org Cc: siprec@ietf.org Subject: Re: [siprec] LastCall:(Use Cases andRequirements forSIP-basedMediaRecording (SIPREC)) toInformational RFC I was thinking we needed a way to synchronize media from multiple CSs, which may be received by the SRS from one or more SRCs. Is this not a requirement? Thanks, Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Muthu ArulMozhi Perumal > (mperumal) > Sent: Thursday, April 14, 2011 1:42 PM > To: Ram Mohan R (rmohanr); Leon Portman; Elwell, John; ietf@ietf.org > Cc: siprec@ietf.org > Subject: Re: [siprec] Last Call:(Use Cases andRequirements forSIP-based > MediaRecording (SIPREC)) toInformational RFC >=20 > I agree with John that these seem more like part of a solution rather=20 > than actual requirements. In addition, sending the wallclock time at=20 > media start/end alone may not suffice for achieving inter-media=20 > synchronization and playback, instead we may need to send the wallclock > time periodically, like RTCP. For e.g, if there is a codec renegotiation > in CS the RTP timestamp can restart from a random value. If silence=20 > suppression is enabled there would be gaps in the RTP timestamp. >=20 > These are things that need to be discussed as part of the solution --=20 > the requirement itself should be generic enough, like what I described. > REQ-022 and REQ-023 we have doesn't seem to clearly indicate the=20 > purpose. >=20 > Muthu >=20 > |-----Original Message----- > |From: Ram Mohan R (rmohanr) > |Sent: Thursday, April 14, 2011 10:13 PM > |To: Leon Portman; Elwell, John; Muthu ArulMozhi Perumal (mperumal); > ietf@ietf.org > |Cc: siprec@ietf.org > |Subject: RE: [siprec] Last Call: (Use > Cases andRequirements for SIP- > |based MediaRecording (SIPREC)) toInformational RFC > | > |We already have attributes Start-Time / End-time in Media Stream > block. This is for the same purpose > |to indicate the wall clock time for start/end of media. > | > |Ram > | > |> -----Original Message----- > |> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > |> Behalf Of Leon Portman > |> Sent: Thursday, April 14, 2011 9:57 PM > |> To: Elwell, John; Muthu ArulMozhi Perumal (mperumal); ietf@ietf.org > |> Cc: siprec@ietf.org > |> Subject: Re: [siprec] Last Call: (Use > |> Cases andRequirements for SIP-based MediaRecording (SIPREC))=20 > |> toInformational RFC > |> > |> I am not sure that having wall clock only for CS start is enough,=20 > |> especially for partial metadata update. I will prefer to have on > media > |> level > |> > |> Leon > |> > |> -----Original Message----- > |> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > |> Sent: Thursday, April 14, 2011 3:58 PM > |> To: Leon Portman; Muthu ArulMozhi Perumal (mperumal); ietf@ietf.org > |> Cc: siprec@ietf.org > |> Subject: RE: [siprec] Last Call: (Use > |> Cases andRequirements for SIP-based Media Recording (SIPREC))=20 > |> toInformational RFC > |> > |> Understood, but if we have wall clock time for the start of a CS,=20 > |> wouldn't that be sufficient? The new requirement would cover=20 > |> synchronization of all media start/stops relative to that time. > |> > |> John (as individual) > |> > |> > |> > -----Original Message----- > |> > From: Leon Portman [mailto:Leon.Portman@nice.com] > |> > Sent: 14 April 2011 13:19 > |> > To: Elwell, John; Muthu ArulMozhi Perumal (mperumal); ietf@ietf.org > |> > Cc: siprec@ietf.org > |> > Subject: RE: [siprec] Last Call: > |> > (Use Cases andRequirements for=20 > |> > SIP-based Media Recording (SIPREC)) toInformational RFC > |> > > |> > Actually REQ-022 and REQ-023 describing not only requirement to=20 > |> > synchronize between different media streams but more importantly=20 > |> > ability to relate them to real world (wall) clock. It is not only > |> > important to playback them correctly but also to know when it was > |> > said. > |> > One example is continue trading after closing hour (even for one=20 > |> > second is not allowed) > |> > > |> > And if these media are synchronized to wall clock then they are > also > |> > synchronized between them thus I am not sure if we need this=20 > |> > additional requirement. > |> > > |> > Thanks > |> > > |> > Leon > |> > > |> > -----Original Message----- > |> > From: siprec-bounces@ietf.org > |> > [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > |> > Sent: Thursday, April 14, 2011 1:54 PM > |> > To: Muthu ArulMozhi Perumal (mperumal); ietf@ietf.org > |> > Cc: siprec@ietf.org > |> > Subject: Re: [siprec] Last Call: > |> > (Use Cases andRequirements for=20 > |> > SIP-based Media Recording (SIPREC)) toInformational RFC > |> > > |> > > |> > > |> > > |> > > -----Original Message----- > |> > > From: siprec-bounces@ietf.org > |> > > [mailto:siprec-bounces@ietf.org] On Behalf Of Muthu > |> > ArulMozhi Perumal > |> > > (mperumal) > |> > > Sent: 14 April 2011 07:34 > |> > > To: ietf@ietf.org > |> > > Cc: siprec@ietf.org > |> > > Subject: Re: [siprec] Last Call: > |> > > (Use Cases andRequirements for=20 > |> > > SIP-based Media Recording (SIPREC)) toInformational RFC > |> > > > |> > > I've one major comment. It draft discusses synchronization > |> > between the > |> > > recorded media streams and synchronized playback, which > |> > seem important > |> > > for certain applications: > |> > > > |> > > > |> > > Some applications require the recording of more than one > |> > media stream, > |> > > possibly of different types. Media are synchronized, either > |> > at storage > |> > > or at playback. > |> > > > |> > > > |> > > However, in the requirements section it doesn't seem REQ-022 and > |> > > REQ-023 are all that are need and sufficient to achieve this with > |> > > needed precision. So, I would suggest adding another requirement > as > |> > > follows: > |> > > The mechanism MUST provide means for facilitating > |> > synchronization of > |> > > the recorded media streams and metadata either at storage or at > |> > > playback. > |> > > This includes, but not limited to, the information needed as per > |> > > REQ-022 and REQ-023. > |> > [JRE] This seems a reasonable addition. I wonder if the new=20 > |> > requirement (first sentence only) is sufficient as a > |> > **replacement** for REQ-022 and REQ-023. On reading REQ-022 and > |> > REQ-023 again, it is not so clear what their purpose was, and they > |> > seem to be more like a solution than a requirement. > |> > One purpose would certainly be that covered by Muthu's new=20 > |> > requirement. Was there any other purpose? > |> > > |> > John > |> > > |> > > > |> > > A nitpick: > |> > > Use Case 8 > |> > > In cases where calls inside or between branches must be recorded, > a > |> > > centralized recording system in data centers together with > |> > telephony > |> > > infrastructure (e.g. PBX) me deployed. > |> > > > |> > > s/me/may be > |> > > > |> > > Muthu > |> > > > |> > > |-----Original Message----- > |> > > |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] > On > |> > > Behalf Of The IESG > |> > > |Sent: Wednesday, April 06, 2011 6:20 PM > |> > > |To: IETF-Announce > |> > > |Cc: siprec@ietf.org > |> > > |Subject: [siprec] Last Call: > |> > > (Use Cases > |> > > andRequirements for SIP-based > |> > > |Media Recording (SIPREC)) toInformational RFC > |> > > | > |> > > | > |> > > |The IESG has received a request from the SIP Recording WG > |> > (siprec) to > |> > > |consider the following document: > |> > > |- 'Use Cases and Requirements for SIP-based Media > |> > Recording (SIPREC)' > |> > > | as an Informational RFC > |> > > | > |> > > |The IESG plans to make a decision in the next few weeks, > |> > and solicits > |> > > |final comments on this action. Please send substantive > |> > > comments to the > |> > > |ietf@ietf.org mailing lists by 2011-04-20. Exceptionally, > |> > > comments may > |> > > be > |> > > |sent to iesg@ietf.org instead. In either case, please retain the > |> > > |beginning of the Subject line to allow automated sorting. > |> > > | > |> > > |The file can be obtained via > |> > > |http://datatracker.ietf.org/doc/draft-ietf-siprec-req/ > |> > > | > |> > > |IESG discussion can be tracked via=20 > |> > > |http://datatracker.ietf.org/doc/draft-ietf-siprec-req/ > |> > > | > |> > > | > |> > > | > |> > > |No IPR declarations have been submitted directly on this I-D. > |> > > |_______________________________________________ > |> > > |siprec mailing list > |> > > |siprec@ietf.org > |> > > |https://www.ietf.org/mailman/listinfo/siprec > |> > > _______________________________________________ > |> > > siprec mailing list > |> > > siprec@ietf.org > |> > > https://www.ietf.org/mailman/listinfo/siprec > |> > > > |> > _______________________________________________ > |> > siprec mailing list > |> > siprec@ietf.org > |> > https://www.ietf.org/mailman/listinfo/siprec > |> > > |> _______________________________________________ > |> siprec mailing list > |> siprec@ietf.org > |> https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From john.elwell@siemens-enterprise.com Thu Apr 14 23:22:55 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C9E7DE069D; Thu, 14 Apr 2011 23:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.924 X-Spam-Level: X-Spam-Status: No, score=-102.924 tagged_above=-999 required=5 tests=[AWL=-0.325, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id miRTmq+YKCS7; Thu, 14 Apr 2011 23:22:54 -0700 (PDT) Received: from mail216.messagelabs.com (mail216.messagelabs.com [85.158.143.99]) by ietfc.amsl.com (Postfix) with SMTP id DE29CE0693; Thu, 14 Apr 2011 23:22:50 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-15.tower-216.messagelabs.com!1302848569!2311714!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 31408 invoked from network); 15 Apr 2011 06:22:49 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-15.tower-216.messagelabs.com with SMTP; 15 Apr 2011 06:22:49 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 8FA501EB83E1; Fri, 15 Apr 2011 08:22:49 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 15 Apr 2011 08:22:49 +0200 From: "Elwell, John" To: "Muthu ArulMozhi Perumal (mperumal)" , "Ram Mohan R (rmohanr)" , Leon Portman , "ietf@ietf.org" Date: Fri, 15 Apr 2011 08:22:48 +0200 Thread-Topic: [siprec] Last Call: (Use Cases andRequirements for SIP-based MediaRecording (SIPREC)) toInformational RFC Thread-Index: Acv0WYBeRuGjGNBtTZSHeqn78QP5xwGEv6YwAAlHtwAAAvtH0AABcMXAAAdJn6AAAIZ7cAAHjozgABTz8IA= Message-ID: References: <20110406125020.17538.70016.idtracker@localhost><1D062974A4845E4D8A343C65380492020533BB70@XMB-BGL-414.cisco.com><07465C1D981ABC41A344374066AE1A2C38AB73D00B@TLVMBX01.nice.com> <07465C1D981ABC41A344374066AE1A2C38AB73D110@TLVMBX01.nice.com> <35BCE99A477D6A4986FB2216D8CF2CFD06009D00@XMB-BGL-417.cisco.com> <1D062974A4845E4D8A343C65380492020533BD38@XMB-BGL-414.cisco.com> In-Reply-To: <1D062974A4845E4D8A343C65380492020533BD38@XMB-BGL-414.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 Cc: "siprec@ietf.org" Subject: Re: [siprec] Last Call: (Use Cases andRequirements for SIP-based MediaRecording (SIPREC)) toInformational RFC X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 15 Apr 2011 06:22:56 -0000 So perhaps if we replace REQ-022 and REQ-023 with the requirement that Muth= u has proposed and one further requirement, e.g.: "REQ-022 The mechanism MUST provide means for facilitating synchronization = of the recorded media streams and metadata either at storage or at playback. REQ-023 The mechanism MUST provide means for relating recordings to wall cl= ock time." John (as individual)=20 > -----Original Message----- > From: Muthu ArulMozhi Perumal (mperumal) [mailto:mperumal@cisco.com]=20 > Sent: 14 April 2011 21:42 > To: Ram Mohan R (rmohanr); Leon Portman; Elwell, John; ietf@ietf.org > Cc: siprec@ietf.org > Subject: RE: [siprec] Last Call:=20 > (Use Cases andRequirements for=20 > SIP-based MediaRecording (SIPREC)) toInformational RFC >=20 > I agree with John that these seem more like part of a solution rather > than actual requirements. In addition, sending the wallclock time at > media start/end alone may not suffice for achieving inter-media > synchronization and playback, instead we may need to send the=20 > wallclock > time periodically, like RTCP. For e.g, if there is a codec=20 > renegotiation > in CS the RTP timestamp can restart from a random value. If silence > suppression is enabled there would be gaps in the RTP timestamp.=20 >=20 > These are things that need to be discussed as part of the solution -- > the requirement itself should be generic enough, like what I=20 > described. > REQ-022 and REQ-023 we have doesn't seem to clearly indicate the > purpose. >=20 > Muthu=20 >=20 > |-----Original Message----- > |From: Ram Mohan R (rmohanr) > |Sent: Thursday, April 14, 2011 10:13 PM > |To: Leon Portman; Elwell, John; Muthu ArulMozhi Perumal (mperumal); > ietf@ietf.org > |Cc: siprec@ietf.org > |Subject: RE: [siprec] Last Call: (Use > Cases andRequirements for SIP- > |based MediaRecording (SIPREC)) toInformational RFC > | > |We already have attributes Start-Time / End-time in Media Stream > block. This is for the same purpose > |to indicate the wall clock time for start/end of media. > | > |Ram > | > |> -----Original Message----- > |> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > |> Behalf Of Leon Portman > |> Sent: Thursday, April 14, 2011 9:57 PM > |> To: Elwell, John; Muthu ArulMozhi Perumal (mperumal); ietf@ietf.org > |> Cc: siprec@ietf.org > |> Subject: Re: [siprec] Last Call: (Use > |> Cases andRequirements for SIP-based MediaRecording (SIPREC)) > |> toInformational RFC > |> > |> I am not sure that having wall clock only for CS start is enough, > |> especially for partial metadata update. I will prefer to have on > media > |> level > |> > |> Leon > |> > |> -----Original Message----- > |> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > |> Sent: Thursday, April 14, 2011 3:58 PM > |> To: Leon Portman; Muthu ArulMozhi Perumal (mperumal); ietf@ietf.org > |> Cc: siprec@ietf.org > |> Subject: RE: [siprec] Last Call:=20 > (Use > |> Cases andRequirements for SIP-based Media Recording (SIPREC)) > |> toInformational RFC > |> > |> Understood, but if we have wall clock time for the start of a CS, > |> wouldn't that be sufficient? The new requirement would cover > |> synchronization of all media start/stops relative to that time. > |> > |> John (as individual) > |> > |> > |> > -----Original Message----- > |> > From: Leon Portman [mailto:Leon.Portman@nice.com] > |> > Sent: 14 April 2011 13:19 > |> > To: Elwell, John; Muthu ArulMozhi Perumal (mperumal);=20 > ietf@ietf.org > |> > Cc: siprec@ietf.org > |> > Subject: RE: [siprec] Last Call: > |> > (Use Cases andRequirements for > |> > SIP-based Media Recording (SIPREC)) toInformational RFC > |> > > |> > Actually REQ-022 and REQ-023 describing not only requirement to > |> > synchronize between different media streams but more importantly > |> > ability to relate them to real world (wall) clock. It is not only > |> > important to playback them correctly but also to know when it was > |> > said. > |> > One example is continue trading after closing hour (even for one > |> > second is not allowed) > |> > > |> > And if these media are synchronized to wall clock then they are > also > |> > synchronized between them thus I am not sure if we need this > |> > additional requirement. > |> > > |> > Thanks > |> > > |> > Leon > |> > > |> > -----Original Message----- > |> > From: siprec-bounces@ietf.org > |> > [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > |> > Sent: Thursday, April 14, 2011 1:54 PM > |> > To: Muthu ArulMozhi Perumal (mperumal); ietf@ietf.org > |> > Cc: siprec@ietf.org > |> > Subject: Re: [siprec] Last Call: > |> > (Use Cases andRequirements for > |> > SIP-based Media Recording (SIPREC)) toInformational RFC > |> > > |> > > |> > > |> > > |> > > -----Original Message----- > |> > > From: siprec-bounces@ietf.org > |> > > [mailto:siprec-bounces@ietf.org] On Behalf Of Muthu > |> > ArulMozhi Perumal > |> > > (mperumal) > |> > > Sent: 14 April 2011 07:34 > |> > > To: ietf@ietf.org > |> > > Cc: siprec@ietf.org > |> > > Subject: Re: [siprec] Last Call: > |> > > (Use Cases andRequirements for > |> > > SIP-based Media Recording (SIPREC)) toInformational RFC > |> > > > |> > > I've one major comment. It draft discusses synchronization > |> > between the > |> > > recorded media streams and synchronized playback, which > |> > seem important > |> > > for certain applications: > |> > > > |> > > > |> > > Some applications require the recording of more than one > |> > media stream, > |> > > possibly of different types. Media are synchronized, either > |> > at storage > |> > > or at playback. > |> > > > |> > > > |> > > However, in the requirements section it doesn't seem=20 > REQ-022 and > |> > > REQ-023 are all that are need and sufficient to=20 > achieve this with > |> > > needed precision. So, I would suggest adding another=20 > requirement > as > |> > > follows: > |> > > The mechanism MUST provide means for facilitating > |> > synchronization of > |> > > the recorded media streams and metadata either at storage or at > |> > > playback. > |> > > This includes, but not limited to, the information=20 > needed as per > |> > > REQ-022 and REQ-023. > |> > [JRE] This seems a reasonable addition. I wonder if the new > |> > requirement (first sentence only) is sufficient as a > |> > **replacement** for REQ-022 and REQ-023. On reading REQ-022 and > |> > REQ-023 again, it is not so clear what their purpose=20 > was, and they > |> > seem to be more like a solution than a requirement. > |> > One purpose would certainly be that covered by Muthu's new > |> > requirement. Was there any other purpose? > |> > > |> > John > |> > > |> > > > |> > > A nitpick: > |> > > Use Case 8 > |> > > In cases where calls inside or between branches must=20 > be recorded, > a > |> > > centralized recording system in data centers together with > |> > telephony > |> > > infrastructure (e.g. PBX) me deployed. > |> > > > |> > > s/me/may be > |> > > > |> > > Muthu > |> > > > |> > > |-----Original Message----- > |> > > |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] > On > |> > > Behalf Of The IESG > |> > > |Sent: Wednesday, April 06, 2011 6:20 PM > |> > > |To: IETF-Announce > |> > > |Cc: siprec@ietf.org > |> > > |Subject: [siprec] Last Call: > |> > > (Use Cases > |> > > andRequirements for SIP-based > |> > > |Media Recording (SIPREC)) toInformational RFC > |> > > | > |> > > | > |> > > |The IESG has received a request from the SIP Recording WG > |> > (siprec) to > |> > > |consider the following document: > |> > > |- 'Use Cases and Requirements for SIP-based Media > |> > Recording (SIPREC)' > |> > > | as an Informational RFC > |> > > | > |> > > |The IESG plans to make a decision in the next few weeks, > |> > and solicits > |> > > |final comments on this action. Please send substantive > |> > > comments to the > |> > > |ietf@ietf.org mailing lists by 2011-04-20. Exceptionally, > |> > > comments may > |> > > be > |> > > |sent to iesg@ietf.org instead. In either case, please=20 > retain the > |> > > |beginning of the Subject line to allow automated sorting. > |> > > | > |> > > |The file can be obtained via > |> > > |http://datatracker.ietf.org/doc/draft-ietf-siprec-req/ > |> > > | > |> > > |IESG discussion can be tracked via > |> > > |http://datatracker.ietf.org/doc/draft-ietf-siprec-req/ > |> > > | > |> > > | > |> > > | > |> > > |No IPR declarations have been submitted directly on this I-D. > |> > > |_______________________________________________ > |> > > |siprec mailing list > |> > > |siprec@ietf.org > |> > > |https://www.ietf.org/mailman/listinfo/siprec > |> > > _______________________________________________ > |> > > siprec mailing list > |> > > siprec@ietf.org > |> > > https://www.ietf.org/mailman/listinfo/siprec > |> > > > |> > _______________________________________________ > |> > siprec mailing list > |> > siprec@ietf.org > |> > https://www.ietf.org/mailman/listinfo/siprec > |> > > |> _______________________________________________ > |> siprec mailing list > |> siprec@ietf.org > |> https://www.ietf.org/mailman/listinfo/siprec > = From rmohanr@cisco.com Fri Apr 15 02:56:37 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 38E67E070E for ; Fri, 15 Apr 2011 02:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.624 X-Spam-Level: X-Spam-Status: No, score=-9.624 tagged_above=-999 required=5 tests=[AWL=-0.825, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SuFH-Idp9Rxg for ; Fri, 15 Apr 2011 02:56:34 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfc.amsl.com (Postfix) with ESMTP id EB4AAE0752 for ; Fri, 15 Apr 2011 02:56:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=23306; q=dns/txt; s=iport; t=1302861394; x=1304070994; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=o2B6Z3T8rDklm8aObz6O0BVsPO85Z9/YQP5JhfLYkJw=; b=NwElNPK7ZNvuT5Mp8+ZAsi4BZFScVPWd4YCyCB4Xvy9zZLEIc+xHZhvH Ku9otFLem5nE+GXopb3B5w4aLDkLHdmlK9k1xrKBc37jNMfprEF/AAU5C ilciCLJefEnONG5sjTtg6NdQzYfVw2Z53vTGOxCvEnlIFBbx0AausBPrU 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtgAABAWqE2Q/khMgWdsb2JhbACYAo1+FAEBFiYliG+dapx3gn+CbwSFXowV X-IronPort-AV: E=Sophos;i="4.64,217,1301875200"; d="scan'208";a="83718827" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 15 Apr 2011 09:56:32 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3F9uHHV031236 for ; Fri, 15 Apr 2011 09:56:32 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); Fri, 15 Apr 2011 15:26:31 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-hashedpuzzle: xh0= AjRX BkQN Dlhm DwKx EBOh EVcQ Ej10 E+0d FhOg GZb0 GiwQ ILa5 JP4p J7sQ KG9Z; 1; cwBpAHAAcgBlAGMAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {4FF628E5-037A-4950-BDEF-C8A69D00091D}; cgBtAG8AaABhAG4AcgBAAGMAaQBzAGMAbwAuAGMAbwBtAA==; Fri, 15 Apr 2011 09:56:19 GMT; RgBXADoAIABbAHMAaQBwAHIAZQBjAF0AIABEAG8AIAB3AGUAIABuAGUAZQBkACAAdABvACAAbQBvAGQAZQBsACAAcABhAHIAdABpAGMAaQBwAGEAbgB0AHMAIABuAG8AdAAgAHAAYQByAHQAIABvAGYAIABDAFMAIABiAHUAdABhAHMAcwBvAGMAaQBhAHQAZQBkACAAdwBpAHQAaAAgAE0AZQBkAGkAYQAgAFMAdAByAGUAYQBtACAAYgBsAG8AYwBrACAAaQBuACAAdABoAGUAIABtAGUAdABhAGQAYQB0AGEAIABtAG8AZABlAGwAIAA/ACAAKAB3AGEAcwAgAFIARQA6ACAAUABhAHIAdABpAGEAbAAgAHUAcABkAGEAdABlAHMAIABhAG4AZAAgAGkAZABlAG4AdABpAGYAaQBlAHIAcwApAA== x-cr-puzzleid: {4FF628E5-037A-4950-BDEF-C8A69D00091D} Content-class: urn:content-classes:message Date: Fri, 15 Apr 2011 15:26:19 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD061331FF@XMB-BGL-417.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Do we need to model participants not part of CS butassociated with Media Stream block in the metadata model ? (was RE: Partial updates and identifiers) Thread-Index: Acv0jVXI4ji2YTo+SquJ6T6YR3i+lQAdOkDgAEETmvAAg54qsAADKDEgAADSn+AAEAO1UAANZylQABBzW2AABHtBwACZNyqA From: "Ram Mohan R (rmohanr)" To: X-OriginalArrivalTime: 15 Apr 2011 09:56:31.0585 (UTC) FILETIME=[659D3510:01CBFB53] Subject: [siprec] FW: Do we need to model participants not part of CS butassociated with Media Stream block in the metadata model ? (was RE: Partial updates and identifiers) X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 15 Apr 2011 09:56:37 -0000 I request people to provide inputs on this and help to take it to a closure. This issue has been open for several months now. Ram -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Ram Mohan R (rmohanr) Sent: Tuesday, April 12, 2011 3:04 PM To: Elwell, John; Charles Eckel (eckelcu); Parthasarathi R (partr); Paul Kyzivat (pkyzivat); siprec@ietf.org Cc: Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr) Subject: [siprec] Do we need to model participants not part of CS but associated with Media Stream block in the metadata model ? (was RE: Partial updates and identifiers) Renaming the mail thread to discussion to this specific issue - "Metadata for participants not part of CS" which we have been discussing from several weeks. Please continue the other issues in original thread and lets use this thread to close this issue. I would request people to give inputs for this issue on this thread and take it to a conclusion. We(Authors of Metadata model) included participants that are not part of CS to imply: - Participants that does NOT contribute to signaling in CS but contributes to media=20 The intent is to give more flexibility in the metamodel to represent these types of participants. Following are some of use case where this can happen- Use-Case 1: A conference where one of the participants is a SRC. In these case the Focus which talks to this SRC becomes part of CS contributing signaling as well as media. However the media includes media from other participants that are not part of CS. Please note SRC has to subscribe to conf event packet to get this information (which may not be always feasible). Use-Case 2: one UA in CS works in 3pcc mode to acquire an MoH media stream, this might be reflected as unique source for media stream without having a reported signaling relationship to it. E.g is given here by Henry Lum http://www.ietf.org/mail-archive/web/siprec/current/msg01372.html In some sense these participants are *still* part of CS as they contribute to CS media. There are three approaches I can see- Don't model the participants that does not contribute signaling in CS and only contribute Media Model these participants as not part of CS in the model but associated with Media Stream block ( current approach) Model these participants to be associated with CS but have the association labeled as "indirect participant"=20 Let me know your thoughts. Thanks, Ram > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Elwell, John > Sent: Tuesday, April 12, 2011 12:13 PM > To: Charles Eckel (eckelcu); Parthasarathi R (partr); Paul Kyzivat > (pkyzivat); siprec@ietf.org > Cc: Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr) > Subject: Re: [siprec] Partial updates and identifiers >=20 > I think the attached message was the last in that thread. So I don't > really think we had closure. >=20 > John >=20 > > -----Original Message----- > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > Sent: 11 April 2011 23:53 > > To: Elwell, John; Parthasarathi R (partr); Paul Kyzivat (pkyzivat); > > siprec@ietf.org > > Cc: Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr); Hadriel > > Kaplan > > Subject: RE: [siprec] Partial updates and identifiers > > > > Hi John, > > > > I have attached the last e-mail I have from the thread in which I > > first raised this issue. Unfortunately, I do not have the e-mail with > > the ultimate agreement, but maybe someone else does or this will help > > prompt some memories. > > > > Cheers, > > Charles > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Elwell, John > > > Sent: Monday, April 11, 2011 9:46 AM > > > To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); > > siprec@ietf.org > > > Cc: Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr); > Hadriel > > Kaplan > > > Subject: Re: [siprec] Partial updates and identifiers > > > > > > Partha, > > > > > > Thanks for reminding me - I now recall the discussion some > > weeks/months ago about the participants > > > obtained from the conference event package. I was never > particularly > > comfortable with the fact these > > > were not considered part of the CS. While that might be > > correct if we > > consider the CS to be the SIP > > > dialog between the SRC and the conference focus, taking a > > broader view > > of CS those participants behind > > > the focus could be considered part of the CS. I don't particularly > > want to open up the old discussion > > > if people are happy with what we have, but something doesn't seem > > quite right to me. > > > > > > For example, if these "participants" are not considered part of the > > CS, and if we don't have specific > > > information about their involvement in media streams, do they > really > > merit being considered > > > Participant objects? > > > > > > In other words, two possible approaches are: > > > > > > 1) The CS extends only as far as the focus / mixer. The > > focus/mixer is > > a "Participant" and the users > > > behind the focus are not separate Participants but are just > > additional > > data associated with the > > > focus/mixer Participant. The only Media Streams we are > > concerned with > > are between the mixer and the > > > SRC. > > > > > > 2) The CS extends beyond the focus/mixer to users learned via the > > conference event package, each of > > > those users is a separate Participant object, and we are concerned > > with Media Stream objects that > > > those participants send and receive. I am not sure how feasible > this > > approach is, because I am not > > > sure that the SRC can obtain enough information about media > > streams at > > users behind the focus/mixer. > > > > > > It seems the present solution is somewhere between the two, which > is > > why I am uncomfortable. > > > > > > Regards, > > > > > > John (as individual) > > > > > > > > > > -----Original Message----- > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > Sent: 11 April 2011 10:29 > > > > To: Elwell, John; Paul Kyzivat (pkyzivat); siprec@ietf.org > > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe Hildebrand > > > > (jhildebr) > > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > > > John, > > > > > > > > Please read inline. > > > > > > > > Thanks > > > > Partha > > > > > > > > -----Original Message----- > > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > Sent: Monday, April 11, 2011 2:11 PM > > > > To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); > > siprec@ietf.org > > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe Hildebrand > > > > (jhildebr) > > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > > Sent: 11 April 2011 08:35 > > > > > To: Elwell, John; Paul Kyzivat (pkyzivat); siprec@ietf.org > > > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe > Hildebrand > > > > > (jhildebr) > > > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > > > > > John, > > > > > > > > > > As I mentioned below, stream block will be unique > > within CS, (not > > > > > required to be unique across multiple CS) and so, xml:id or > > > > enhancing > > > > > the normative statement of RFC 4574 label attribute to be > unique > > > > > within CS will serve the purpose. I'm fine with any of the > above > > > > > mentioned id. > > > > > Please note that RFC 4574 "label" attribute is the nature > > > > data for RS > > > > > dialog. > > > > > > > > > > In case participant within CS, xml:id will serve the purpose > but > > we > > > > > need to get more clarity about participants who are not > > > > part of CS but > > > > > > > > > within RS. > > > > [JRE] If I understand the figure in section 3 of metadata-04 > > > > correctly, a Participant can have a relationship with a CS, but > no > > > > direct relationship with an RS. > > > > > > > > Sorry, I mixed up my statement with the latest update of > > > > making CSG optional. As per Sec 3 of metadata-04, participant has > > > > direct relationship with CSG in case CS is left completely > > > > unattached. In case CSG is optional, then participant will have > > > > direct relationship with RS in case there is no relationship > > > > between CS and participant. > > > > > > > > > > > > So a participant that does not have a relationship with a CS is > > left > > > > completely unattached, unless it has a relationship with a Media > > > > Stream (which always has a relationship with a CS). So to > > > > summarize: > > > > - a Participant can have a direct relationship with a CS; or > > > > - a Participant can have an indirect relationship with a CS (via > a > > > > Media Stream); agreed > > > > - a Participant can have no relationship with a CS, and > > therefore no > > > > relationship with an RS. > > > > Do we really need this last case? > > > > > > > > I'm happy if the last case is not required because it > > > > simplify the solution and there is no need of unique id for > > > > participant. But SRS implementers may prefer to have relationship > > > > with participant and RS. I wish more opinion before taking > > > > decision whether to remove the last case > > > > > > > > > Because CS may span across different RS how about the > > > > participant who > > > > > are not part of CS? > > > > [JRE] I don't understand the words "Because CS may span across > > > > different RS", because in the rest of the sentence you are > talking > > > > about a Participant that is not part of a CS. > > > > > > > > > Ex: One of the user in the conference acts as SRC, fetch > > > > participant > > > > > info using conferene package and new RS is created > > during initial > > > > > conference creation and hold&resume of a user within CS. > > > > [JRE] I am not sure what you are trying to say here. I would > > > > consider a user whose identity is obtained via a conference event > > > > package as being part of the CS. > > > > > > > > I'm trying to give the example where participant is not > > > > associated with CS directly but related to CSG (/RS). This > > > > scenario was considered as a blocking in -03 version of metadata. > > > > I'm not arguing to have this scenario but it is major concern for > > > > few folks. > > > > > > > > CS is between focus and UA, UA acts as SRC, UA receives the > > > > participant info via conference event package but those > > > > participants are not related in CS directly (and only focus is > > > > related) but they contributed for the mixed stream. > > > > > > > > That user is sending/receiving Media Streams that are part of a > > > > CS, or if it isn't sending/receiving Media Streams, what is the > > > > relevance > > of > > > > that Participant? > > > > > > > > Mixed media stream from focus to UA belongs to the > > Conference > > > > event package participants. There participant are not directly > > > > involved as part of CS. Why would we create a new RS > > > > for such a participant? > > > > RS is not created for participant. Multiple RS shall be > > > > created the same CS during the different time frame as shown > below > > > > > > > > <-------------------CS1-------------> > > > > <---RS1--> <---RS2------> > > > > > > > > CS1 is between UA (SRC) and focus whereas RS1, RS2 is between UA > > (SRC) > > > > and SRS. Here tangling (conference event package) participant has > > > > to be grouped together in RS1, RS2 by some means through given > > > > metadata. > > The > > > > question whether this corner has to be solved ? > > > > > > > > John (as individual) > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > Partha > > > > > > > > > > -----Original Message----- > > > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > > Sent: Friday, April 08, 2011 9:36 PM > > > > > To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); > > > > siprec@ietf.org > > > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe > Hildebrand > > > > > (jhildebr) > > > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > > > > > Focusing just on participant and stream for the time being, > > > > do these > > > > > need to be unique across multiple CSs or not? > > > > > > > > > > John > > > > > > > > > > > -----Original Message----- > > > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > > > Sent: 07 April 2011 10:51 > > > > > > To: Paul Kyzivat (pkyzivat); siprec@ietf.org; Elwell, John > > > > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe > > Hildebrand > > > > > > (jhildebr) > > > > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > > > > > > > John, > > > > > > > > > > > > Sorry for the lengthy mail but it contains lot of analysis > and > > > > > > reasoning for this id approach. > > > > > > > > > > > > Adding to Paul's point, I wish to give more background and > > > > > reason for > > > > > > these globally unique id. Initially I had the impression that > > the > > > > > > single unique id (RS dialog-id) in the recording (session > > > > > level) and > > > > > > some relevant natural id for the rest of the element will > > > > serve the > > > > > > purpose. > > > > > > There are usecases where this assumption fails. Even I have > > > > > thought of > > > > > > > > > > > using "xml:id" instead of URN UUID to avoid long string but > > > > > xml:id may > > > > > > > > > > > not end up with unique value always. Our analysis for URN > > > > UUID for > > > > > > each level is as follows and please provide your input in > case > > id > > > > > > shall be > > > > > > tweaked: > > > > > > > > > > > > 1) Recording block: The reason for globally unique id is > > > > > that multiple > > > > > > > > > > > SRC with same id to single SRS. > > > > > > > > > > > > Topology: > > > > > > > > > > > > SRC1 SRC2 > > > > > > | | > > > > > > | ----(RS1-ID1)-----SRS1 > > > > > > | > > > > > > ---(RS2-ID1)------------------SRS1 > > > > > > > > > > > > In the above topology, it is possible for ID1 is generated by > > both > > > > > > SRC1 and SRC2 at the same time. > > > > > > > > > > > > 2) group (CSG) block: Grouping mechanism (Hadriel > > > > session-id, Paul > > > > > > Jones > > > > > > Session-UUID) is outside the scope of SIPREC. URN UUID > > > > > abstracts the > > > > > > exact mechanism to SRS and provides the information only > > > > about the > > > > > > group of CS from SRC perspective. It possible that group may > > span > > > > > > across multiple RS and It is up to SRS to group and view > > > > as single > > > > > > recording. > > > > > > Here, the single level id in the top will fail. The counter > > > > > argument > > > > > > is to force the single RS having complete CSG but > > it*may not* be > > > > > > possible in SRC implementation. Here, xml:id will not > > serve the > > > > > > purpose > > > > > > > > > > > > 3) session (CS) block: At the immediate look, session > > > > falls exactly > > > > > > under recording block. Use case 3 of draft-ietf-siprec-req-09 > > > > > > illustrates where CS span across multiple RS. This > > > > > requirement calls > > > > > > for unique id in session by which these session shall be > > > > viewed as > > > > > > single CS even though there is no group exists among > > > > them. IMO, in > > > > > > case session should not have globally unique id, then it is > > > > > preferred > > > > > > to remove usecase 3 in the requirement. > > > > > > > > > > > > 4) participant block: It needs some id which may be AOR but > > > > > AOR is not > > > > > > > > > > > unique. IMO, xml:id may serve the purpose with session > > > > > unique id. The > > > > > > trick exists for participant who are not associated with > > > > > CS. We shall > > > > > > discuss and fine tune if required. > > > > > > > > > > > > 5) stream block: Label attribute shall be used as unique > > > > > value but RFC > > > > > > 4574 does not mandate label attribute has to be unique across > > the > > > > > > dialog or CS and so, it may possible to change within > > RS and no > > > > > > normative statement to stop this implementation. IMO, > > > > > xml:id may serve > > > > > > > > > > > the purpose with session unique id. Here as well, We shall > > > > > discuss and > > > > > > > > > > > fine tune if required. > > > > > > > > > > > > 6) extensiondata block: This is tracked in the separate > > > > mail thread > > > > > > whether unique id is required or not. Let us close this > > > > as part of > > > > > > that mail thread. > > > > > > > > > > > > Including explicitly Hadriel, Peter, Joe in this mail > > > > > thread as they > > > > > > have different view on this ID mechanism. > > > > > > > > > > > > I had offline discussion with Hadriel in Prague after > > > > > SIPREC meeting > > > > > > and my understanding of his major concern is that how SRS > > > > > will be able > > > > > > > > > > > to design the database in case partial update does not have > > > > > recording > > > > > > (top) id information. I'll put more thought > > processing to close > > > > > > Hadriel concern of how top id has to be tracked in case > > > > > partial update > > > > > > > > > > > by which SRS implementation will be simplified in terms of > > > > > aggregation > > > > > > > > > > > maintenance. > > > > > > > > > > > > Thanks > > > > > > Partha > > > > > > > > > > > > -----Original Message----- > > > > > > From: siprec-bounces@ietf.org > > > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > > > > > (pkyzivat) > > > > > > Sent: Thursday, April 07, 2011 12:33 AM > > > > > > To: siprec@ietf.org > > > > > > Subject: Re: [siprec] Partial updates and identifiers > > > > > > > > > > > > John, > > > > > > > > > > > > For the moment we have proposed that the ids be conveyed in > > > > > the form > > > > > > of URIs that are globally unique, and specifically that > > > > > they be UUID > > > > > > URNs. > > > > > > There is no dependency on the particular form of the URI, but > > > > > > specifying they must be UUID URNs makes it possible to > > > > perform some > > > > > > internal optimizations for storage. > > > > > > > > > > > > The UUID URN is a pretty inefficient encoding. A UUID can > > > > > be expressed > > > > > > > > > > > in 32 bits, so we could consider retaining UUIDs but alter > the > > > > > > encoding if its really an issue. However I am far from > > > > > convinced that > > > > > > the size of the IDs is going to be a major issue in the > > > > > overall size > > > > > > of messages, so I think its probably premature to worry about > > it. > > > > > > > > > > > > Because the ids can be expressed in 32 bits, the SRC and > > > > > SRS can store > > > > > > > > > > > them internally that way, thus reducing the runtime cost of > > > > > > maintaining the data. > > > > > > > > > > > > The use of unique ids is a significant part of the overall > > > > > approach to > > > > > > > > > > > formatting updates. If somebody has a different concept > > > > in mind it > > > > > > could be useful to have an alternative proposal for the > > > > > format. If we > > > > > > had two worked out approaches we could compare the > > > > > tradeoffs in each. > > > > > > > > > > > > Thanks, > > > > > > Paul > > > > > > > > > > > > On 4/6/2011 10:24 AM, Elwell, John wrote: > > > > > > > Much of the discussion on draft-ram-metadata-format > > in Prague > > > > > > concerned the mechanism for performing partial updates and > > > > > the use of > > > > > > identifiers. The draft permits partial updates by allowing > > > > > individual > > > > > > objects (e.g., CS, participant, media stream) to be sent > > > > > with updated > > > > > > content, without having to send again other objects that have > > not > > > > > > changed. So, for example, in a large conference, it would > > > > > be possible > > > > > > to add or modify an individual participant object without > > > > having to > > > > > > send all the other participant objects again. I do not recall > > any > > > > > > opposition to this basic principle. > > > > > > > > > > > > > > However, to achieve this, every object requires an > > > > > > identifier, and it > > > > > > was asserted that these identifiers need to be globally > > > > > unique for all > > > > > > > > > > > time. Although this might be efficient for updating an > > individual > > > > > > object, when sending many objects (e.g., at the start of a > > > > > CS or when > > > > > > refreshing the entire metadata), this can make the > > metadata very > > > > > > bulky. > > > > > > It depends, of course, on the format of the identifiers, > > > > and it was > > > > > > stated that there could be alternatives to UUID. > > > > Nevertheless, some > > > > > > people had concerns. These concerns also extended to the > > > > > impact on the > > > > > > > > > > > database where metadata is stored, since it might not be > > > > > feasible to > > > > > > convert to a database-friendly mechanism for linking > > > > > objects together. > > > > > > > > > > > > > > One alternative proposal during the meeting was to have a > > single > > > > > > unique identifier at the top level (for the RS) and use local > > > > > > identifiers for other objects. Thus when updating a single > > > > > object, it > > > > > > would be necessary to include the top level identifier as > > > > > well as one > > > > > > or more local identifiers. However, there were also concerns > > this > > > > > > might not fulfil actual or perceived future requirements. > > > > > > > > > > > > > > Please continue discussion on this. > > > > > > > > > > > > > > John (as chair) > > > > > > > _______________________________________________ > > > > > > > siprec mailing list > > > > > > > siprec@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > > > > > > _______________________________________________ > > > > > > siprec mailing list > > > > > > siprec@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > > > > > > > > > > > _______________________________________________ > > > siprec mailing 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 Fri Apr 15 04:04:30 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 505B3E0717 for ; Fri, 15 Apr 2011 04:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.744 X-Spam-Level: X-Spam-Status: No, score=-103.744 tagged_above=-999 required=5 tests=[AWL=0.455, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vdohOoufe5a5 for ; Fri, 15 Apr 2011 04:04:27 -0700 (PDT) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfc.amsl.com (Postfix) with SMTP id E8B8FE06C0 for ; Fri, 15 Apr 2011 04:04:26 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1302865464!36241571!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 15229 invoked from network); 15 Apr 2011 11:04:24 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-8.tower-27.messagelabs.com with SMTP; 15 Apr 2011 11:04:24 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id B9EFB23F03DB; Fri, 15 Apr 2011 13:04:25 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 15 Apr 2011 13:04:25 +0200 From: "Elwell, John" To: "Ram Mohan R (rmohanr)" , "siprec@ietf.org" Date: Fri, 15 Apr 2011 13:04:24 +0200 Thread-Topic: [siprec] FW: Do we need to model participants not part of CS butassociated with Media Stream block in the metadata model ? (was RE: Partial updates and identifiers) Thread-Index: Acv0jVXI4ji2YTo+SquJ6T6YR3i+lQAdOkDgAEETmvAAg54qsAADKDEgAADSn+AAEAO1UAANZylQABBzW2AABHtBwACZNyqAAAGC+nA= Message-ID: References: <35BCE99A477D6A4986FB2216D8CF2CFD061331FF@XMB-BGL-417.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD061331FF@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] FW: Do we need to model participants not part of CS butassociated with Media Stream block in the metadata model ? (was RE: Partial updates and identifiers) X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 15 Apr 2011 11:04:30 -0000 As an individual, my opinion, which I have pretty much stated before, is th= at a participant must always be part of a CS. A couple of situations have b= een mentioned where alternatives might be required, but I don't believe so. 1. Conferences. I think depending what view the SRC has of the CS, there ar= e two situations: (a) The SRC sees all parties in the conference and has visibility of what M= edia Streams each party sends and receives. In this case, I think the whole= conference can be modelled as a CS and each party can be modelled as a Par= ticipant in that CS. Such a view will typically be feasible when the SRC is= located at a conference focus/mixer (e.g., an MCU). (b) The SRC sees the conference focus mixer as a party but has limited info= rmation about parties behind the focus/mixer. In this case I think the SRC = can regard the CS as terminating at the conference (focus/mixer), with the = conference a Participant in that CS. Information about parties behind the c= onference may or may not be available, in which case they can be additional= attributes of the conference Participant object. One typical case will be = where the SRC is located at a UA of one of the conference parties, or at a = B2BUA between the focus/mixer and a party UA. In that case the CS would hav= e two Participants: the party concerned and the conference. Am extreme case= is where the conference is the sole Participant and just records Media Str= eams sent by the conference to parties in the conference. Hybrid situations can occur, e.g., for cascaded conferences, where particip= ants at one conference are modelled as Participants but other conferences a= re just modelled each as a single Participant. 2. IVR and similar. I would model the Media Server as a Participant in the = CS, i.e., there is a CS between the Media Server and the caller. John > -----Original Message----- > From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On Behalf Of Ram Mohan R (rmohanr) > Sent: 15 April 2011 10:56 > To: siprec@ietf.org > Subject: [siprec] FW: Do we need to model participants not > part of CS butassociated with Media Stream block in the > metadata model ? (was RE: Partial updates and identifiers) > > I request people to provide inputs on this and help to take it to a > closure. This issue has been open for several months now. > > Ram > > -----Original Message----- > From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On Behalf > Of Ram Mohan R (rmohanr) > Sent: Tuesday, April 12, 2011 3:04 PM > To: Elwell, John; Charles Eckel (eckelcu); Parthasarathi R > (partr); Paul > Kyzivat (pkyzivat); siprec@ietf.org > Cc: Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr) > Subject: [siprec] Do we need to model participants not part of CS but > associated with Media Stream block in the metadata model ? (was RE: > Partial updates and identifiers) > > Renaming the mail thread to discussion to this specific issue - > "Metadata for participants not part of CS" which we have been > discussing > from several weeks. > > Please continue the other issues in original thread and lets use this > thread to close this issue. I would request people to give inputs for > this issue on this thread and take it to a conclusion. > > We(Authors of Metadata model) included participants that are > not part of > CS to imply: > - Participants that does NOT contribute to signaling in CS but > contributes to media > The intent is to give more flexibility in the metamodel to represent > these types of participants. > > Following are some of use case where this can happen- > > Use-Case 1: A conference where one of the participants is a SRC. In > these case the Focus which talks to this SRC becomes part of CS > contributing signaling as well as media. However the media includes > media from other participants that are not part of CS. Please note SRC > has to subscribe to conf event packet to get this information > (which may > not be always feasible). > > Use-Case 2: one UA in CS works in 3pcc mode to acquire an MoH media > stream, this might be reflected as unique source for media stream > without having a reported signaling relationship to it. E.g is given > here by Henry Lum > http://www.ietf.org/mail-archive/web/siprec/current/msg01372.html > > In some sense these participants are *still* part of CS as they > contribute to CS media. > > There are three approaches I can see- > Don't model the participants that does not contribute signaling in CS > and only contribute Media > Model these participants as not part of CS in the model but associated > with Media Stream block ( current approach) > Model these participants to be associated with CS but have the > association labeled as "indirect participant" > > Let me know your thoughts. > > Thanks, > Ram > > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Elwell, John > > Sent: Tuesday, April 12, 2011 12:13 PM > > To: Charles Eckel (eckelcu); Parthasarathi R (partr); Paul Kyzivat > > (pkyzivat); siprec@ietf.org > > Cc: Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr) > > Subject: Re: [siprec] Partial updates and identifiers > > > > I think the attached message was the last in that thread. So I don't > > really think we had closure. > > > > John > > > > > -----Original Message----- > > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > Sent: 11 April 2011 23:53 > > > To: Elwell, John; Parthasarathi R (partr); Paul Kyzivat > (pkyzivat); > > > siprec@ietf.org > > > Cc: Peter Saint-Andre (psaintan); Joe Hildebrand > (jhildebr); Hadriel > > > Kaplan > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > Hi John, > > > > > > I have attached the last e-mail I have from the thread in which I > > > first raised this issue. Unfortunately, I do not have the e-mail > with > > > the ultimate agreement, but maybe someone else does or this will > help > > > prompt some memories. > > > > > > Cheers, > > > Charles > > > > > > > -----Original Message----- > > > > From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On > > > Behalf Of Elwell, John > > > > Sent: Monday, April 11, 2011 9:46 AM > > > > To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); > > > siprec@ietf.org > > > > Cc: Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr); > > Hadriel > > > Kaplan > > > > Subject: Re: [siprec] Partial updates and identifiers > > > > > > > > Partha, > > > > > > > > Thanks for reminding me - I now recall the discussion some > > > weeks/months ago about the participants > > > > obtained from the conference event package. I was never > > particularly > > > comfortable with the fact these > > > > were not considered part of the CS. While that might be > > > correct if we > > > consider the CS to be the SIP > > > > dialog between the SRC and the conference focus, taking a > > > broader view > > > of CS those participants behind > > > > the focus could be considered part of the CS. I don't > particularly > > > want to open up the old discussion > > > > if people are happy with what we have, but something > doesn't seem > > > quite right to me. > > > > > > > > For example, if these "participants" are not considered part of > the > > > CS, and if we don't have specific > > > > information about their involvement in media streams, do they > > really > > > merit being considered > > > > Participant objects? > > > > > > > > In other words, two possible approaches are: > > > > > > > > 1) The CS extends only as far as the focus / mixer. The > > > focus/mixer is > > > a "Participant" and the users > > > > behind the focus are not separate Participants but are just > > > additional > > > data associated with the > > > > focus/mixer Participant. The only Media Streams we are > > > concerned with > > > are between the mixer and the > > > > SRC. > > > > > > > > 2) The CS extends beyond the focus/mixer to users > learned via the > > > conference event package, each of > > > > those users is a separate Participant object, and we > are concerned > > > with Media Stream objects that > > > > those participants send and receive. I am not sure how feasible > > this > > > approach is, because I am not > > > > sure that the SRC can obtain enough information about media > > > streams at > > > users behind the focus/mixer. > > > > > > > > It seems the present solution is somewhere between the > two, which > > is > > > why I am uncomfortable. > > > > > > > > Regards, > > > > > > > > John (as individual) > > > > > > > > > > > > > -----Original Message----- > > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > > Sent: 11 April 2011 10:29 > > > > > To: Elwell, John; Paul Kyzivat (pkyzivat); siprec@ietf.org > > > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe > Hildebrand > > > > > (jhildebr) > > > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > > > > > John, > > > > > > > > > > Please read inline. > > > > > > > > > > Thanks > > > > > Partha > > > > > > > > > > -----Original Message----- > > > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > > Sent: Monday, April 11, 2011 2:11 PM > > > > > To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); > > > siprec@ietf.org > > > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe > Hildebrand > > > > > (jhildebr) > > > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > > > Sent: 11 April 2011 08:35 > > > > > > To: Elwell, John; Paul Kyzivat (pkyzivat); siprec@ietf.org > > > > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe > > Hildebrand > > > > > > (jhildebr) > > > > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > > > > > > > John, > > > > > > > > > > > > As I mentioned below, stream block will be unique > > > within CS, (not > > > > > > required to be unique across multiple CS) and so, xml:id or > > > > > enhancing > > > > > > the normative statement of RFC 4574 label attribute to be > > unique > > > > > > within CS will serve the purpose. I'm fine with any of the > > above > > > > > > mentioned id. > > > > > > Please note that RFC 4574 "label" attribute is the nature > > > > > data for RS > > > > > > dialog. > > > > > > > > > > > > In case participant within CS, xml:id will serve the purpose > > but > > > we > > > > > > need to get more clarity about participants who are not > > > > > part of CS but > > > > > > > > > > > within RS. > > > > > [JRE] If I understand the figure in section 3 of metadata-04 > > > > > correctly, a Participant can have a relationship with > a CS, but > > no > > > > > direct relationship with an RS. > > > > > > > > > > Sorry, I mixed up my statement with the latest update > of > > > > > making CSG optional. As per Sec 3 of metadata-04, participant > has > > > > > direct relationship with CSG in case CS is left completely > > > > > unattached. In case CSG is optional, then participant > will have > > > > > direct relationship with RS in case there is no relationship > > > > > between CS and participant. > > > > > > > > > > > > > > > So a participant that does not have a relationship > with a CS is > > > left > > > > > completely unattached, unless it has a relationship > with a Media > > > > > Stream (which always has a relationship with a CS). So to > > > > > summarize: > > > > > - a Participant can have a direct relationship with a CS; or > > > > > - a Participant can have an indirect relationship > with a CS (via > > a > > > > > Media Stream); agreed > > > > > - a Participant can have no relationship with a CS, and > > > therefore no > > > > > relationship with an RS. > > > > > Do we really need this last case? > > > > > > > > > > I'm happy if the last case is not required because it > > > > > simplify the solution and there is no need of unique id for > > > > > participant. But SRS implementers may prefer to have > relationship > > > > > with participant and RS. I wish more opinion before taking > > > > > decision whether to remove the last case > > > > > > > > > > > Because CS may span across different RS how about the > > > > > participant who > > > > > > are not part of CS? > > > > > [JRE] I don't understand the words "Because CS may span across > > > > > different RS", because in the rest of the sentence you are > > talking > > > > > about a Participant that is not part of a CS. > > > > > > > > > > > Ex: One of the user in the conference acts as SRC, fetch > > > > > participant > > > > > > info using conferene package and new RS is created > > > during initial > > > > > > conference creation and hold&resume of a user within CS. > > > > > [JRE] I am not sure what you are trying to say here. I would > > > > > consider a user whose identity is obtained via a conference > event > > > > > package as being part of the CS. > > > > > > > > > > I'm trying to give the example where > participant is not > > > > > associated with CS directly but related to CSG (/RS). This > > > > > scenario was considered as a blocking in -03 version of > metadata. > > > > > I'm not arguing to have this scenario but it is major concern > for > > > > > few folks. > > > > > > > > > > CS is between focus and UA, UA acts as SRC, UA receives the > > > > > participant info via conference event package but those > > > > > participants are not related in CS directly (and only focus is > > > > > related) but they contributed for the mixed stream. > > > > > > > > > > That user is sending/receiving Media Streams that > are part of a > > > > > CS, or if it isn't sending/receiving Media Streams, > what is the > > > > > relevance > > > of > > > > > that Participant? > > > > > > > > > > Mixed media stream from focus to UA belongs to the > > > Conference > > > > > event package participants. There participant are not directly > > > > > involved as part of CS. Why would we > create a new RS > > > > > for such a participant? > > > > > RS is not created for participant. Multiple > RS shall be > > > > > created the same CS during the different time frame as shown > > below > > > > > > > > > > <-------------------CS1-------------> > > > > > <---RS1--> <---RS2------> > > > > > > > > > > CS1 is between UA (SRC) and focus whereas RS1, RS2 is > between UA > > > (SRC) > > > > > and SRS. Here tangling (conference event package) participant > has > > > > > to be grouped together in RS1, RS2 by some means through given > > > > > metadata. > > > The > > > > > question whether this corner has to be solved ? > > > > > > > > > > John (as individual) > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > Partha > > > > > > > > > > > > -----Original Message----- > > > > > > From: Elwell, John > [mailto:john.elwell@siemens-enterprise.com] > > > > > > Sent: Friday, April 08, 2011 9:36 PM > > > > > > To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); > > > > > siprec@ietf.org > > > > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe > > Hildebrand > > > > > > (jhildebr) > > > > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > > > > > > > Focusing just on participant and stream for the time being, > > > > > do these > > > > > > need to be unique across multiple CSs or not? > > > > > > > > > > > > John > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > > > > Sent: 07 April 2011 10:51 > > > > > > > To: Paul Kyzivat (pkyzivat); siprec@ietf.org; Elwell, John > > > > > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe > > > Hildebrand > > > > > > > (jhildebr) > > > > > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > > > > > > > > > John, > > > > > > > > > > > > > > Sorry for the lengthy mail but it contains lot of analysis > > and > > > > > > > reasoning for this id approach. > > > > > > > > > > > > > > Adding to Paul's point, I wish to give more background and > > > > > > reason for > > > > > > > these globally unique id. Initially I had the impression > that > > > the > > > > > > > single unique id (RS dialog-id) in the recording (session > > > > > > level) and > > > > > > > some relevant natural id for the rest of the element will > > > > > serve the > > > > > > > purpose. > > > > > > > There are usecases where this assumption fails. > Even I have > > > > > > thought of > > > > > > > > > > > > > using "xml:id" instead of URN UUID to avoid long > string but > > > > > > xml:id may > > > > > > > > > > > > > not end up with unique value always. Our analysis for URN > > > > > UUID for > > > > > > > each level is as follows and please provide your input in > > case > > > id > > > > > > > shall be > > > > > > > tweaked: > > > > > > > > > > > > > > 1) Recording block: The reason for globally unique id is > > > > > > that multiple > > > > > > > > > > > > > SRC with same id to single SRS. > > > > > > > > > > > > > > Topology: > > > > > > > > > > > > > > SRC1 SRC2 > > > > > > > | | > > > > > > > | ----(RS1-ID1)-----SRS1 > > > > > > > | > > > > > > > ---(RS2-ID1)------------------SRS1 > > > > > > > > > > > > > > In the above topology, it is possible for ID1 is generated > by > > > both > > > > > > > SRC1 and SRC2 at the same time. > > > > > > > > > > > > > > 2) group (CSG) block: Grouping mechanism (Hadriel > > > > > session-id, Paul > > > > > > > Jones > > > > > > > Session-UUID) is outside the scope of SIPREC. URN UUID > > > > > > abstracts the > > > > > > > exact mechanism to SRS and provides the information only > > > > > about the > > > > > > > group of CS from SRC perspective. It possible > that group may > > > span > > > > > > > across multiple RS and It is up to SRS to group and view > > > > > as single > > > > > > > recording. > > > > > > > Here, the single level id in the top will fail. > The counter > > > > > > argument > > > > > > > is to force the single RS having complete CSG but > > > it*may not* be > > > > > > > possible in SRC implementation. Here, xml:id will not > > > serve the > > > > > > > purpose > > > > > > > > > > > > > > 3) session (CS) block: At the immediate look, session > > > > > falls exactly > > > > > > > under recording block. Use case 3 of > draft-ietf-siprec-req-09 > > > > > > > illustrates where CS span across multiple RS. This > > > > > > requirement calls > > > > > > > for unique id in session by which these session shall be > > > > > viewed as > > > > > > > single CS even though there is no group exists among > > > > > them. IMO, in > > > > > > > case session should not have globally unique id, > then it is > > > > > > preferred > > > > > > > to remove usecase 3 in the requirement. > > > > > > > > > > > > > > 4) participant block: It needs some id which may > be AOR but > > > > > > AOR is not > > > > > > > > > > > > > unique. IMO, xml:id may serve the purpose with session > > > > > > unique id. The > > > > > > > trick exists for participant who are not associated with > > > > > > CS. We shall > > > > > > > discuss and fine tune if required. > > > > > > > > > > > > > > 5) stream block: Label attribute shall be used as unique > > > > > > value but RFC > > > > > > > 4574 does not mandate label attribute has to be unique > across > > > the > > > > > > > dialog or CS and so, it may possible to change within > > > RS and no > > > > > > > normative statement to stop this implementation. IMO, > > > > > > xml:id may serve > > > > > > > > > > > > > the purpose with session unique id. Here as well, We shall > > > > > > discuss and > > > > > > > > > > > > > fine tune if required. > > > > > > > > > > > > > > 6) extensiondata block: This is tracked in the separate > > > > > mail thread > > > > > > > whether unique id is required or not. Let us close this > > > > > as part of > > > > > > > that mail thread. > > > > > > > > > > > > > > Including explicitly Hadriel, Peter, Joe in this mail > > > > > > thread as they > > > > > > > have different view on this ID mechanism. > > > > > > > > > > > > > > I had offline discussion with Hadriel in Prague after > > > > > > SIPREC meeting > > > > > > > and my understanding of his major concern is that how SRS > > > > > > will be able > > > > > > > > > > > > > to design the database in case partial update > does not have > > > > > > recording > > > > > > > (top) id information. I'll put more thought > > > processing to close > > > > > > > Hadriel concern of how top id has to be tracked in case > > > > > > partial update > > > > > > > > > > > > > by which SRS implementation will be simplified in terms of > > > > > > aggregation > > > > > > > > > > > > > maintenance. > > > > > > > > > > > > > > Thanks > > > > > > > Partha > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: siprec-bounces@ietf.org > > > > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > > > > > > (pkyzivat) > > > > > > > Sent: Thursday, April 07, 2011 12:33 AM > > > > > > > To: siprec@ietf.org > > > > > > > Subject: Re: [siprec] Partial updates and identifiers > > > > > > > > > > > > > > John, > > > > > > > > > > > > > > For the moment we have proposed that the ids be > conveyed in > > > > > > the form > > > > > > > of URIs that are globally unique, and specifically that > > > > > > they be UUID > > > > > > > URNs. > > > > > > > There is no dependency on the particular form of the URI, > but > > > > > > > specifying they must be UUID URNs makes it possible to > > > > > perform some > > > > > > > internal optimizations for storage. > > > > > > > > > > > > > > The UUID URN is a pretty inefficient encoding. A UUID can > > > > > > be expressed > > > > > > > > > > > > > in 32 bits, so we could consider retaining UUIDs but alter > > the > > > > > > > encoding if its really an issue. However I am far from > > > > > > convinced that > > > > > > > the size of the IDs is going to be a major issue in the > > > > > > overall size > > > > > > > of messages, so I think its probably premature to worry > about > > > it. > > > > > > > > > > > > > > Because the ids can be expressed in 32 bits, the SRC and > > > > > > SRS can store > > > > > > > > > > > > > them internally that way, thus reducing the > runtime cost of > > > > > > > maintaining the data. > > > > > > > > > > > > > > The use of unique ids is a significant part of the overall > > > > > > approach to > > > > > > > > > > > > > formatting updates. If somebody has a different concept > > > > > in mind it > > > > > > > could be useful to have an alternative proposal for the > > > > > > format. If we > > > > > > > had two worked out approaches we could compare the > > > > > > tradeoffs in each. > > > > > > > > > > > > > > Thanks, > > > > > > > Paul > > > > > > > > > > > > > > On 4/6/2011 10:24 AM, Elwell, John wrote: > > > > > > > > Much of the discussion on draft-ram-metadata-format > > > in Prague > > > > > > > concerned the mechanism for performing partial updates and > > > > > > the use of > > > > > > > identifiers. The draft permits partial updates by allowing > > > > > > individual > > > > > > > objects (e.g., CS, participant, media stream) to be sent > > > > > > with updated > > > > > > > content, without having to send again other objects that > have > > > not > > > > > > > changed. So, for example, in a large conference, it would > > > > > > be possible > > > > > > > to add or modify an individual participant object without > > > > > having to > > > > > > > send all the other participant objects again. I do not > recall > > > any > > > > > > > opposition to this basic principle. > > > > > > > > > > > > > > > > However, to achieve this, every object requires an > > > > > > > identifier, and it > > > > > > > was asserted that these identifiers need to be globally > > > > > > unique for all > > > > > > > > > > > > > time. Although this might be efficient for updating an > > > individual > > > > > > > object, when sending many objects (e.g., at the start of a > > > > > > CS or when > > > > > > > refreshing the entire metadata), this can make the > > > metadata very > > > > > > > bulky. > > > > > > > It depends, of course, on the format of the identifiers, > > > > > and it was > > > > > > > stated that there could be alternatives to UUID. > > > > > Nevertheless, some > > > > > > > people had concerns. These concerns also extended to the > > > > > > impact on the > > > > > > > > > > > > > database where metadata is stored, since it might not be > > > > > > feasible to > > > > > > > convert to a database-friendly mechanism for linking > > > > > > objects together. > > > > > > > > > > > > > > > > One alternative proposal during the meeting was > to have a > > > single > > > > > > > unique identifier at the top level (for the RS) and use > local > > > > > > > identifiers for other objects. Thus when updating a single > > > > > > object, it > > > > > > > would be necessary to include the top level identifier as > > > > > > well as one > > > > > > > or more local identifiers. However, there were > also concerns > > > this > > > > > > > might not fulfil actual or perceived future requirements. > > > > > > > > > > > > > > > > Please continue discussion on this. > > > > > > > > > > > > > > > > John (as chair) > > > > > > > > _______________________________________________ > > > > > > > > siprec mailing list > > > > > > > > siprec@ietf.org > > > > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > siprec mailing list > > > > > > > siprec@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > siprec mailing 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 partr@cisco.com Fri Apr 15 04:58:28 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id ADCC1E06CE for ; Fri, 15 Apr 2011 04:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.927 X-Spam-Level: X-Spam-Status: No, score=-8.927 tagged_above=-999 required=5 tests=[AWL=-0.728, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ERQz3YES-5S6 for ; Fri, 15 Apr 2011 04:58:25 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfc.amsl.com (Postfix) with ESMTP id 0721DE06D5 for ; Fri, 15 Apr 2011 04:58:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=28581; q=dns/txt; s=iport; t=1302868705; x=1304078305; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=eLtURsdIZ3ummUJskIi4Yg0Q/xssU8cdNjuQ+X/zIEw=; b=VbaTINSn2Utynpu033ZtXjd5EVYsEscYg+y5m+iiAw3GjNRLtqCAqzmG cYAJfaCqE/bCCOiRQiYaE6sgUlyF97nixxbqYGs7VK/LuKLUsS2YJ/NtX STbXRnnerkBpuPFhA5WT/AYS/96M/tIyQ5jihl+ZMhdY2qc5Q98RjlxvB U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjcBAC8yqE2Q/khRgWdsb2JhbACYAI1/FAEBFiYliG+ePZx2gn+CbwSFXowV X-IronPort-AV: E=Sophos;i="4.64,218,1301875200"; d="scan'208";a="83737514" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 15 Apr 2011 11:58:24 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3FBw5PO026849; Fri, 15 Apr 2011 11:58:23 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 15 Apr 2011 17:28:10 +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: Fri, 15 Apr 2011 17:28:11 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] FW: Do we need to model participants not part ofCS butassociated with Media Stream block in the metadatamodel ? (was RE: Partial updates and identifiers) Thread-Index: Acv0jVXI4ji2YTo+SquJ6T6YR3i+lQAdOkDgAEETmvAAg54qsAADKDEgAADSn+AAEAO1UAANZylQABBzW2AABHtBwACZNyqAAAGC+nAAAd/QMA== References: <35BCE99A477D6A4986FB2216D8CF2CFD061331FF@XMB-BGL-417.cisco.com> From: "Parthasarathi R (partr)" To: "Elwell, John" , "Ram Mohan R (rmohanr)" , X-OriginalArrivalTime: 15 Apr 2011 11:58:10.0871 (UTC) FILETIME=[6453DC70:01CBFB64] Subject: Re: [siprec] FW: Do we need to model participants not part ofCS butassociated with Media Stream block in the metadatamodel ? (was RE: Partial updates and identifiers) X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 15 Apr 2011 11:58:28 -0000 John point of view looks reasonable to me because CS is not directly associated with dialogs but instead it represents session with the list of participant involved in it.=20 In case of participant list received through conference package to SRC with UA, those multiple participants from focus shall be represented as individual participant block who are pointed to single mixed media stream metadata block and all participant belongs within single conference CS in this scenario. The model is as follows (part in the diagram represents participant): RS | CS------------------------------- | | ----------------------- part5(SRC) | | | | |=20 | | | | media stream2 part1 part2 part3 part4 | | | | ------------------------- | Media stream1 Thanks Partha=20 -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John Sent: Friday, April 15, 2011 4:34 PM To: Ram Mohan R (rmohanr); siprec@ietf.org Subject: Re: [siprec] FW: Do we need to model participants not part ofCS butassociated with Media Stream block in the metadatamodel ? (was RE: Partial updates and identifiers) As an individual, my opinion, which I have pretty much stated before, is that a participant must always be part of a CS. A couple of situations have been mentioned where alternatives might be required, but I don't believe so. 1. Conferences. I think depending what view the SRC has of the CS, there are two situations: (a) The SRC sees all parties in the conference and has visibility of what Media Streams each party sends and receives. In this case, I think the whole conference can be modelled as a CS and each party can be modelled as a Participant in that CS. Such a view will typically be feasible when the SRC is located at a conference focus/mixer (e.g., an MCU). (b) The SRC sees the conference focus mixer as a party but has limited information about parties behind the focus/mixer. In this case I think the SRC can regard the CS as terminating at the conference (focus/mixer), with the conference a Participant in that CS. Information about parties behind the conference may or may not be available, in which case they can be additional attributes of the conference Participant object. One typical case will be where the SRC is located at a UA of one of the conference parties, or at a B2BUA between the focus/mixer and a party UA. In that case the CS would have two Participants: the party concerned and the conference. Am extreme case is where the conference is the sole Participant and just records Media Streams sent by the conference to parties in the conference. Hybrid situations can occur, e.g., for cascaded conferences, where participants at one conference are modelled as Participants but other conferences are just modelled each as a single Participant. 2. IVR and similar. I would model the Media Server as a Participant in the CS, i.e., there is a CS between the Media Server and the caller. John > -----Original Message----- > From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On Behalf Of Ram Mohan R (rmohanr) > Sent: 15 April 2011 10:56 > To: siprec@ietf.org > Subject: [siprec] FW: Do we need to model participants not part of CS=20 > butassociated with Media Stream block in the metadata model ? (was RE: > Partial updates and identifiers) > > I request people to provide inputs on this and help to take it to a=20 > closure. This issue has been open for several months now. > > Ram > > -----Original Message----- > From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On Behalf Of Ram Mohan R (rmohanr) > Sent: Tuesday, April 12, 2011 3:04 PM > To: Elwell, John; Charles Eckel (eckelcu); Parthasarathi R (partr);=20 > Paul Kyzivat (pkyzivat); siprec@ietf.org > Cc: Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr) > Subject: [siprec] Do we need to model participants not part of CS but=20 > associated with Media Stream block in the metadata model ? (was RE: > Partial updates and identifiers) > > Renaming the mail thread to discussion to this specific issue -=20 > "Metadata for participants not part of CS" which we have been=20 > discussing from several weeks. > > Please continue the other issues in original thread and lets use this=20 > thread to close this issue. I would request people to give inputs for=20 > this issue on this thread and take it to a conclusion. > > We(Authors of Metadata model) included participants that are not part=20 > of CS to imply: > - Participants that does NOT contribute to signaling in CS but=20 > contributes to media The intent is to give more flexibility in the=20 > metamodel to represent these types of participants. > > Following are some of use case where this can happen- > > Use-Case 1: A conference where one of the participants is a SRC. In=20 > these case the Focus which talks to this SRC becomes part of CS=20 > contributing signaling as well as media. However the media includes=20 > media from other participants that are not part of CS. Please note SRC > has to subscribe to conf event packet to get this information (which=20 > may not be always feasible). > > Use-Case 2: one UA in CS works in 3pcc mode to acquire an MoH media=20 > stream, this might be reflected as unique source for media stream > without having a reported signaling relationship to it. E.g is given > here by Henry Lum > http://www.ietf.org/mail-archive/web/siprec/current/msg01372.html > > In some sense these participants are *still* part of CS as they=20 > contribute to CS media. > > There are three approaches I can see- > Don't model the participants that does not contribute signaling in CS=20 > and only contribute Media Model these participants as not part of CS=20 > in the model but associated with Media Stream block ( current=20 > approach) Model these participants to be associated with CS but have=20 > the association labeled as "indirect participant" > > Let me know your thoughts. > > Thanks, > Ram > > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > > Behalf Of Elwell, John > > Sent: Tuesday, April 12, 2011 12:13 PM > > To: Charles Eckel (eckelcu); Parthasarathi R (partr); Paul Kyzivat=20 > > (pkyzivat); siprec@ietf.org > > Cc: Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr) > > Subject: Re: [siprec] Partial updates and identifiers > > > > I think the attached message was the last in that thread. So I don't > > really think we had closure. > > > > John > > > > > -----Original Message----- > > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > Sent: 11 April 2011 23:53 > > > To: Elwell, John; Parthasarathi R (partr); Paul Kyzivat > (pkyzivat); > > > siprec@ietf.org > > > Cc: Peter Saint-Andre (psaintan); Joe Hildebrand > (jhildebr); Hadriel > > > Kaplan > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > Hi John, > > > > > > I have attached the last e-mail I have from the thread in which I=20 > > > first raised this issue. Unfortunately, I do not have the e-mail > with > > > the ultimate agreement, but maybe someone else does or this will > help > > > prompt some memories. > > > > > > Cheers, > > > Charles > > > > > > > -----Original Message----- > > > > From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On > > > Behalf Of Elwell, John > > > > Sent: Monday, April 11, 2011 9:46 AM > > > > To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); > > > siprec@ietf.org > > > > Cc: Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr); > > Hadriel > > > Kaplan > > > > Subject: Re: [siprec] Partial updates and identifiers > > > > > > > > Partha, > > > > > > > > Thanks for reminding me - I now recall the discussion some > > > weeks/months ago about the participants > > > > obtained from the conference event package. I was never > > particularly > > > comfortable with the fact these > > > > were not considered part of the CS. While that might be > > > correct if we > > > consider the CS to be the SIP > > > > dialog between the SRC and the conference focus, taking a > > > broader view > > > of CS those participants behind > > > > the focus could be considered part of the CS. I don't > particularly > > > want to open up the old discussion > > > > if people are happy with what we have, but something > doesn't seem > > > quite right to me. > > > > > > > > For example, if these "participants" are not considered part of > the > > > CS, and if we don't have specific > > > > information about their involvement in media streams, do they > > really > > > merit being considered > > > > Participant objects? > > > > > > > > In other words, two possible approaches are: > > > > > > > > 1) The CS extends only as far as the focus / mixer. The > > > focus/mixer is > > > a "Participant" and the users > > > > behind the focus are not separate Participants but are just > > > additional > > > data associated with the > > > > focus/mixer Participant. The only Media Streams we are > > > concerned with > > > are between the mixer and the > > > > SRC. > > > > > > > > 2) The CS extends beyond the focus/mixer to users > learned via the > > > conference event package, each of > > > > those users is a separate Participant object, and we > are concerned > > > with Media Stream objects that > > > > those participants send and receive. I am not sure how feasible > > this > > > approach is, because I am not > > > > sure that the SRC can obtain enough information about media > > > streams at > > > users behind the focus/mixer. > > > > > > > > It seems the present solution is somewhere between the > two, which > > is > > > why I am uncomfortable. > > > > > > > > Regards, > > > > > > > > John (as individual) > > > > > > > > > > > > > -----Original Message----- > > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > > Sent: 11 April 2011 10:29 > > > > > To: Elwell, John; Paul Kyzivat (pkyzivat); siprec@ietf.org > > > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe > Hildebrand > > > > > (jhildebr) > > > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > > > > > John, > > > > > > > > > > Please read inline. > > > > > > > > > > Thanks > > > > > Partha > > > > > > > > > > -----Original Message----- > > > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > > Sent: Monday, April 11, 2011 2:11 PM > > > > > To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); > > > siprec@ietf.org > > > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe > Hildebrand > > > > > (jhildebr) > > > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > > > Sent: 11 April 2011 08:35 > > > > > > To: Elwell, John; Paul Kyzivat (pkyzivat); siprec@ietf.org > > > > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe > > Hildebrand > > > > > > (jhildebr) > > > > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > > > > > > > John, > > > > > > > > > > > > As I mentioned below, stream block will be unique > > > within CS, (not > > > > > > required to be unique across multiple CS) and so, xml:id or > > > > > enhancing > > > > > > the normative statement of RFC 4574 label attribute to be > > unique > > > > > > within CS will serve the purpose. I'm fine with any of the > > above > > > > > > mentioned id. > > > > > > Please note that RFC 4574 "label" attribute is the nature > > > > > data for RS > > > > > > dialog. > > > > > > > > > > > > In case participant within CS, xml:id will serve the purpose > > but > > > we > > > > > > need to get more clarity about participants who are not > > > > > part of CS but > > > > > > > > > > > within RS. > > > > > [JRE] If I understand the figure in section 3 of metadata-04=20 > > > > > correctly, a Participant can have a relationship with > a CS, but > > no > > > > > direct relationship with an RS. > > > > > > > > > > Sorry, I mixed up my statement with the latest update > of > > > > > making CSG optional. As per Sec 3 of metadata-04, participant > has > > > > > direct relationship with CSG in case CS is left completely=20 > > > > > unattached. In case CSG is optional, then participant > will have > > > > > direct relationship with RS in case there is no relationship=20 > > > > > between CS and participant. > > > > > > > > > > > > > > > So a participant that does not have a relationship > with a CS is > > > left > > > > > completely unattached, unless it has a relationship > with a Media > > > > > Stream (which always has a relationship with a CS). So to > > > > > summarize: > > > > > - a Participant can have a direct relationship with a CS; or > > > > > - a Participant can have an indirect relationship > with a CS (via > > a > > > > > Media Stream); agreed > > > > > - a Participant can have no relationship with a CS, and > > > therefore no > > > > > relationship with an RS. > > > > > Do we really need this last case? > > > > > > > > > > I'm happy if the last case is not required because it > > > > > simplify the solution and there is no need of unique id for=20 > > > > > participant. But SRS implementers may prefer to have > relationship > > > > > with participant and RS. I wish more opinion before taking=20 > > > > > decision whether to remove the last case > > > > > > > > > > > Because CS may span across different RS how about the > > > > > participant who > > > > > > are not part of CS? > > > > > [JRE] I don't understand the words "Because CS may span across > > > > > different RS", because in the rest of the sentence you are > > talking > > > > > about a Participant that is not part of a CS. > > > > > > > > > > > Ex: One of the user in the conference acts as SRC, fetch > > > > > participant > > > > > > info using conferene package and new RS is created > > > during initial > > > > > > conference creation and hold&resume of a user within CS. > > > > > [JRE] I am not sure what you are trying to say here. I would=20 > > > > > consider a user whose identity is obtained via a conference > event > > > > > package as being part of the CS. > > > > > > > > > > I'm trying to give the example where > participant is not > > > > > associated with CS directly but related to CSG (/RS). This=20 > > > > > scenario was considered as a blocking in -03 version of > metadata. > > > > > I'm not arguing to have this scenario but it is major concern > for > > > > > few folks. > > > > > > > > > > CS is between focus and UA, UA acts as SRC, UA receives the=20 > > > > > participant info via conference event package but those=20 > > > > > participants are not related in CS directly (and only focus is > > > > > related) but they contributed for the mixed stream. > > > > > > > > > > That user is sending/receiving Media Streams that > are part of a > > > > > CS, or if it isn't sending/receiving Media Streams, > what is the > > > > > relevance > > > of > > > > > that Participant? > > > > > > > > > > Mixed media stream from focus to UA belongs to the > > > Conference > > > > > event package participants. There participant are not directly > > > > > involved as part of CS. Why would we > create a new RS > > > > > for such a participant? > > > > > RS is not created for participant. Multiple > RS shall be > > > > > created the same CS during the different time frame as shown > > below > > > > > > > > > > <-------------------CS1-------------> > > > > > <---RS1--> <---RS2------> > > > > > > > > > > CS1 is between UA (SRC) and focus whereas RS1, RS2 is > between UA > > > (SRC) > > > > > and SRS. Here tangling (conference event package) participant > has > > > > > to be grouped together in RS1, RS2 by some means through given > > > > > metadata. > > > The > > > > > question whether this corner has to be solved ? > > > > > > > > > > John (as individual) > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > Partha > > > > > > > > > > > > -----Original Message----- > > > > > > From: Elwell, John > [mailto:john.elwell@siemens-enterprise.com] > > > > > > Sent: Friday, April 08, 2011 9:36 PM > > > > > > To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); > > > > > siprec@ietf.org > > > > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe > > Hildebrand > > > > > > (jhildebr) > > > > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > > > > > > > Focusing just on participant and stream for the time being, > > > > > do these > > > > > > need to be unique across multiple CSs or not? > > > > > > > > > > > > John > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > > > > Sent: 07 April 2011 10:51 > > > > > > > To: Paul Kyzivat (pkyzivat); siprec@ietf.org; Elwell, John > > > > > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe > > > Hildebrand > > > > > > > (jhildebr) > > > > > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > > > > > > > > > John, > > > > > > > > > > > > > > Sorry for the lengthy mail but it contains lot of analysis > > and > > > > > > > reasoning for this id approach. > > > > > > > > > > > > > > Adding to Paul's point, I wish to give more background and > > > > > > reason for > > > > > > > these globally unique id. Initially I had the impression > that > > > the > > > > > > > single unique id (RS dialog-id) in the recording (session > > > > > > level) and > > > > > > > some relevant natural id for the rest of the element will > > > > > serve the > > > > > > > purpose. > > > > > > > There are usecases where this assumption fails. > Even I have > > > > > > thought of > > > > > > > > > > > > > using "xml:id" instead of URN UUID to avoid long > string but > > > > > > xml:id may > > > > > > > > > > > > > not end up with unique value always. Our analysis for URN > > > > > UUID for > > > > > > > each level is as follows and please provide your input in > > case > > > id > > > > > > > shall be > > > > > > > tweaked: > > > > > > > > > > > > > > 1) Recording block: The reason for globally unique id is > > > > > > that multiple > > > > > > > > > > > > > SRC with same id to single SRS. > > > > > > > > > > > > > > Topology: > > > > > > > > > > > > > > SRC1 SRC2 > > > > > > > | | > > > > > > > | ----(RS1-ID1)-----SRS1 > > > > > > > | > > > > > > > ---(RS2-ID1)------------------SRS1 > > > > > > > > > > > > > > In the above topology, it is possible for ID1 is generated > by > > > both > > > > > > > SRC1 and SRC2 at the same time. > > > > > > > > > > > > > > 2) group (CSG) block: Grouping mechanism (Hadriel > > > > > session-id, Paul > > > > > > > Jones > > > > > > > Session-UUID) is outside the scope of SIPREC. URN UUID > > > > > > abstracts the > > > > > > > exact mechanism to SRS and provides the information only > > > > > about the > > > > > > > group of CS from SRC perspective. It possible > that group may > > > span > > > > > > > across multiple RS and It is up to SRS to group and view > > > > > as single > > > > > > > recording. > > > > > > > Here, the single level id in the top will fail. > The counter > > > > > > argument > > > > > > > is to force the single RS having complete CSG but > > > it*may not* be > > > > > > > possible in SRC implementation. Here, xml:id will not > > > serve the > > > > > > > purpose > > > > > > > > > > > > > > 3) session (CS) block: At the immediate look, session > > > > > falls exactly > > > > > > > under recording block. Use case 3 of > draft-ietf-siprec-req-09 > > > > > > > illustrates where CS span across multiple RS. This > > > > > > requirement calls > > > > > > > for unique id in session by which these session shall be > > > > > viewed as > > > > > > > single CS even though there is no group exists among > > > > > them. IMO, in > > > > > > > case session should not have globally unique id, > then it is > > > > > > preferred > > > > > > > to remove usecase 3 in the requirement. > > > > > > > > > > > > > > 4) participant block: It needs some id which may > be AOR but > > > > > > AOR is not > > > > > > > > > > > > > unique. IMO, xml:id may serve the purpose with session > > > > > > unique id. The > > > > > > > trick exists for participant who are not associated with > > > > > > CS. We shall > > > > > > > discuss and fine tune if required. > > > > > > > > > > > > > > 5) stream block: Label attribute shall be used as unique > > > > > > value but RFC > > > > > > > 4574 does not mandate label attribute has to be unique > across > > > the > > > > > > > dialog or CS and so, it may possible to change within > > > RS and no > > > > > > > normative statement to stop this implementation. IMO, > > > > > > xml:id may serve > > > > > > > > > > > > > the purpose with session unique id. Here as well, We shall > > > > > > discuss and > > > > > > > > > > > > > fine tune if required. > > > > > > > > > > > > > > 6) extensiondata block: This is tracked in the separate > > > > > mail thread > > > > > > > whether unique id is required or not. Let us close this > > > > > as part of > > > > > > > that mail thread. > > > > > > > > > > > > > > Including explicitly Hadriel, Peter, Joe in this mail > > > > > > thread as they > > > > > > > have different view on this ID mechanism. > > > > > > > > > > > > > > I had offline discussion with Hadriel in Prague after > > > > > > SIPREC meeting > > > > > > > and my understanding of his major concern is that how SRS > > > > > > will be able > > > > > > > > > > > > > to design the database in case partial update > does not have > > > > > > recording > > > > > > > (top) id information. I'll put more thought > > > processing to close > > > > > > > Hadriel concern of how top id has to be tracked in case > > > > > > partial update > > > > > > > > > > > > > by which SRS implementation will be simplified in terms of > > > > > > aggregation > > > > > > > > > > > > > maintenance. > > > > > > > > > > > > > > Thanks > > > > > > > Partha > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: siprec-bounces@ietf.org=20 > > > > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > > > > > > (pkyzivat) > > > > > > > Sent: Thursday, April 07, 2011 12:33 AM > > > > > > > To: siprec@ietf.org > > > > > > > Subject: Re: [siprec] Partial updates and identifiers > > > > > > > > > > > > > > John, > > > > > > > > > > > > > > For the moment we have proposed that the ids be > conveyed in > > > > > > the form > > > > > > > of URIs that are globally unique, and specifically that > > > > > > they be UUID > > > > > > > URNs. > > > > > > > There is no dependency on the particular form of the URI, > but > > > > > > > specifying they must be UUID URNs makes it possible to > > > > > perform some > > > > > > > internal optimizations for storage. > > > > > > > > > > > > > > The UUID URN is a pretty inefficient encoding. A UUID can > > > > > > be expressed > > > > > > > > > > > > > in 32 bits, so we could consider retaining UUIDs but alter > > the > > > > > > > encoding if its really an issue. However I am far from > > > > > > convinced that > > > > > > > the size of the IDs is going to be a major issue in the > > > > > > overall size > > > > > > > of messages, so I think its probably premature to worry > about > > > it. > > > > > > > > > > > > > > Because the ids can be expressed in 32 bits, the SRC and > > > > > > SRS can store > > > > > > > > > > > > > them internally that way, thus reducing the > runtime cost of > > > > > > > maintaining the data. > > > > > > > > > > > > > > The use of unique ids is a significant part of the overall > > > > > > approach to > > > > > > > > > > > > > formatting updates. If somebody has a different concept > > > > > in mind it > > > > > > > could be useful to have an alternative proposal for the > > > > > > format. If we > > > > > > > had two worked out approaches we could compare the > > > > > > tradeoffs in each. > > > > > > > > > > > > > > Thanks, > > > > > > > Paul > > > > > > > > > > > > > > On 4/6/2011 10:24 AM, Elwell, John wrote: > > > > > > > > Much of the discussion on draft-ram-metadata-format > > > in Prague > > > > > > > concerned the mechanism for performing partial updates and > > > > > > the use of > > > > > > > identifiers. The draft permits partial updates by allowing > > > > > > individual > > > > > > > objects (e.g., CS, participant, media stream) to be sent > > > > > > with updated > > > > > > > content, without having to send again other objects that > have > > > not > > > > > > > changed. So, for example, in a large conference, it would > > > > > > be possible > > > > > > > to add or modify an individual participant object without > > > > > having to > > > > > > > send all the other participant objects again. I do not > recall > > > any > > > > > > > opposition to this basic principle. > > > > > > > > > > > > > > > > However, to achieve this, every object requires an > > > > > > > identifier, and it > > > > > > > was asserted that these identifiers need to be globally > > > > > > unique for all > > > > > > > > > > > > > time. Although this might be efficient for updating an > > > individual > > > > > > > object, when sending many objects (e.g., at the start of a > > > > > > CS or when > > > > > > > refreshing the entire metadata), this can make the > > > metadata very > > > > > > > bulky. > > > > > > > It depends, of course, on the format of the identifiers, > > > > > and it was > > > > > > > stated that there could be alternatives to UUID. > > > > > Nevertheless, some > > > > > > > people had concerns. These concerns also extended to the > > > > > > impact on the > > > > > > > > > > > > > database where metadata is stored, since it might not be > > > > > > feasible to > > > > > > > convert to a database-friendly mechanism for linking > > > > > > objects together. > > > > > > > > > > > > > > > > One alternative proposal during the meeting was > to have a > > > single > > > > > > > unique identifier at the top level (for the RS) and use > local > > > > > > > identifiers for other objects. Thus when updating a single > > > > > > object, it > > > > > > > would be necessary to include the top level identifier as > > > > > > well as one > > > > > > > or more local identifiers. However, there were > also concerns > > > this > > > > > > > might not fulfil actual or perceived future requirements. > > > > > > > > > > > > > > > > Please continue discussion on this. > > > > > > > > > > > > > > > > John (as chair) > > > > > > > > _______________________________________________ > > > > > > > > siprec mailing list > > > > > > > > siprec@ietf.org > > > > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > siprec mailing list > > > > > > > siprec@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > siprec mailing 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 partr@cisco.com Fri Apr 15 07:26:38 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 41B85E0745 for ; Fri, 15 Apr 2011 07:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.084 X-Spam-Level: X-Spam-Status: No, score=-10.084 tagged_above=-999 required=5 tests=[AWL=0.515, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21OcfdMf-3sN for ; Fri, 15 Apr 2011 07:26:33 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfc.amsl.com (Postfix) with ESMTP id D2033E0670 for ; Fri, 15 Apr 2011 07:26:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=26684; q=dns/txt; s=iport; t=1302877593; x=1304087193; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=H7U8wzC3s8GkZrmP7hMF+OZ/IR9YneawUIM0rHWdoZU=; b=mdxCW7zbO22dBaBoyeviIEcc0R4s7jGcWi3kq81kfWcCuXDmDS1awJSJ /HraN6KaJCxhdXJJBbtgAZ1LsgrbfUMJ6feoqwqIFfmV9/9xnpbsE+H0t GGbVhX5DrOhtPMt0RofrT9FYkw1GNJiSwlWxFC6QGtuBi3gkKUAZftNms k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjcBAE9VqE2Q/khLgWdsb2JhbACYAI1/FAEBFiYliG+eQJx7gn6CcASFXowV X-IronPort-AV: E=Sophos;i="4.64,219,1301875200"; d="scan'208";a="83767422" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 15 Apr 2011 14:26:31 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3FEQUjl008170; Fri, 15 Apr 2011 14:26:31 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 15 Apr 2011 19:56:29 +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: Fri, 15 Apr 2011 19:56:29 +0530 Message-ID: In-Reply-To: <4DA6F618.7080005@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] start/stop times & the metamodel Thread-Index: Acv6p68xjkf6yjmvT8mCaMfEpKI3swA0SIdA References: <4D9CDADD.1020403@cisco.com> <4DA2FC17.1060100@cisco.com><07465C1D981ABC41A344374066AE1A2C38AB6E1DE4@TLVMBX01.nice.com><4DA334F0.9050301@cisco.com><059AF07365DC474393A19A3AF187DF7406E67CB4@NAHALD.us.int.genesyslab.com><1D062974A4845E4D8A343C65380492020533B45B@XMB-BGL-414.cisco.com> <059AF07365DC474393A19A3AF187DF7406EF2378@NAHALD.us.int.genesyslab.com> <1D062974A4845E4D8A343C65380492020533B880@XMB-BGL-414.cisco.com> <1D062974A4845E4D8A343C65380492020533B93C@XMB-BGL-414.cisco.com> <4DA59DF3.7020500@cisco.com> <4DA6F618.7080005@cisco.com> From: "Parthasarathi R (partr)" To: "Paul Kyzivat (pkyzivat)" , "Elwell, John" X-OriginalArrivalTime: 15 Apr 2011 14:26:29.0944 (UTC) FILETIME=[1C96A380:01CBFB79] Cc: siprec@ietf.org Subject: Re: [siprec] start/stop times & the metamodel X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 15 Apr 2011 14:26:38 -0000 Paul, Scenario 2: In case of this RTP translator (forwarding) scenario, Metadata media stream block start time has to act as reference timestamp rather than RTP timestamp. Say Media stream start time as T0 and end time as T1, the first media packet is received at T0+ t[i] wherein t[i] is the time interval between T0 and first media packet. Here T0+t[i] is always less than T1. Playback shall use T0 as the reference value. Here, B's media will be played back in SRS how A sees it and A media will be replayed as if A speaks.=20 Scenario 3: This scenario needs some extra interface between A & B apart from SIPREC. Let us assume it exists. Then also, it is not possible to synchronize the media stream because A will not know how B receives it and B will not know how A receives it. So, these sort of recording will replay how A and B speaks at the given time rather than how A or B listen to it. Thanks Partha -----Original Message----- From: Paul Kyzivat (pkyzivat)=20 Sent: Thursday, April 14, 2011 6:57 PM To: Elwell, John Cc: Parthasarathi R (partr); siprec@ietf.org Subject: Re: [siprec] start/stop times & the metamodel On 4/14/2011 7:12 AM, Elwell, John wrote: > I guess it depends what we are trying to capture here. Consider a 2-party call between A and B. > > First consider the case where the SRC is collocated with UA A. Do we wish to record the time A sends media and the time A receives media. Note that the time B receives media will be later than the time A sends it, and the time B sends media will be earlier than the time A receives it. When reconstructing audio during playback, do we want to reconstruct the audio with synchronization between the two directions in accordance with what took place at A or with what took place at B? > > Second, consider the case where the SRC is at a B2BUA. Here the times that media pass through equate neither to the time that A sends and receives nor the time that B sends and receives. So do we want to reconstruct the audio as observed by the B2BUA, or what took place at A, or what took place at B? > > Another point is that for calls partly over TDM (PSTN), timings for what happens beyond the gateway will not be available. So it will not be possible to reconstruct a conversation from the perspective of a user participating via PSTN. > > It would be possible to simplify things and say that we record in a way that what gets reconstructed on playback is what is observed at the point where the SRC is located. Sure, this is a simplification, but trying to do anything else would be harder and still would not reflect what is observed by some or all of the participants. > > If we assume this simplification, the only other point is trying to compensate for delays, or in particular differing delays, on the RS path. I don't think we can legislate this. But maybe we can at least identify for the SRS what it is that it has. This depends a lot on the RTP model that is used for directing media to the SRS. For instance, in your first case: If A mixes the audio it receives from B with that it sends to B, in accord with the order it receives it from its mic and sends to its speaker, and clocks it all consistently, then the SRS will be able to play back a rendition as A heard it. If A simply clones the media stream it gets from B and the one it sends to A, and forwards the clones to the SRS, either as separate streams or as one stream with two SSRCs, then the SRS will have difficulty reconstructing things as heard by A, or by B. Its not so clear *what* it should do to play the two back in a reasonable way. If A, instead of cloning the stream from B itself, instead asks B to clone the stream and send a copy to the SRS, then things are again different. Similar situations apply in the second case. Thanks, Paul > John (as individual) > > >> -----Original Message----- >> From: siprec-bounces@ietf.org >> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: 13 April 2011 13:58 >> To: Parthasarathi R (partr) >> Cc: siprec@ietf.org >> Subject: Re: [siprec] start/stop times& the metamodel >> >> >> >> On 4/13/2011 7:50 AM, Parthasarathi R (partr) wrote: >>> Muthu, >>> >>> Even now, Media stream block attributes like start-time, end-time in >>> metadata from SRC facilitates SRS to have synchronized >> playback media in >>> case SRS maps metadata from SRC with the received raw >> media. Proposed >>> requirement is going one level deeper wherein the timestamp >> from SRC has >>> to be based on RTP layer timestamp or SRC SIP signaling? >>> >>> IMO, SIP signaling serves the purpose and there is no need >> of explicitly >>> mention how SRC find start timestamp. In case you have >> strong usecase >>> for RTP timestamp based requirement, it requires changes in SIPREC=20 >>> requirement because it is specific mechanism insisted on SRC. >> >> Let me start out by saying that I don't know what the >> answer(s) are here >> - I have a very limited knowledge of RTP. >> >> The timestamps in the metadata (or in the sip messages that carry the >> metadata) are a *piece* of the solution. How *sufficient* they are=20 >> remains to be seen - perhaps by demonstrating some procedures for=20 >> using them to achieve a useful playback result in various scenarios. >> >> The problem seems to be that even if a timestamp from the CS=20 >> signaling is passed in the metadata, its not clear how that can be=20 >> synchronized with RTP data arriving at the SRS. *Perhaps* its enough=20 >> if you assume that RTP packets will begin to arrive at the SRS=20 >> concurrently with the signaling that describes the corresponding=20 >> stream. I'm certain that is >> *not* true, but I don't know how *far* from true it is, or how much=20 >> that will vary based on scenario. >> >> It does seem to me that it is a mistake to standardize a mechanism=20 >> that >> *depends* on such a shaky mechanism. (But a mechanism that uses this=20 >> as a fallback mechanism might make sense.) >> >> Thanks, >> Paul >> >>> Thanks >>> Partha >>> >>> -----Original Message----- >>> From: Muthu ArulMozhi Perumal (mperumal) >>> Sent: Wednesday, April 13, 2011 4:07 PM >>> To: Parthasarathi R (partr); 'Henry Lum'; Paul Kyzivat >> (pkyzivat); 'Leon >>> Portman' >>> Cc: 'siprec@ietf.org' >>> Subject: RE: [siprec] start/stop times& the metamodel >>> >>> I don't think the requirements need to go to the level of >> RTP timestamp. >>> But it may be useful to add a requirement that the SRC needs to=20 >>> facilitate synchronized querying/playback of the recorded >> media streams >>> and metadata. I couldn't derive that directly from the >> requirements we >>> already have, but would like to hear from others if this is already=20 >>> implied. >>> >>> Muthu >>> >>> |-----Original Message----- >>> |From: Parthasarathi R (partr) >>> |Sent: Wednesday, April 13, 2011 2:46 PM >>> |To: Muthu ArulMozhi Perumal (mperumal); 'Henry Lum'; Paul Kyzivat >>> (pkyzivat); 'Leon Portman' >>> |Cc: 'siprec@ietf.org' >>> |Subject: RE: [siprec] start/stop times& the metamodel >>> | >>> |ISTM, SRC has to act only as RTP Endpoint or RTP Mixer (not RTP >>> |translator) in case these requirement has to be considered within=20 >>> |SIPREC. IMO, these requirement has to be mentioned in SIPREC=20 >>> |requirement document to define the exact role what SRC >> does with media >>> timestamp and what SRS does with media timestamp? >>> | >>> |Thanks >>> |Partha >>> | >>> |-----Original Message----- >>> |From: Muthu ArulMozhi Perumal (mperumal) >>> |Sent: Wednesday, April 13, 2011 12:36 PM >>> |To: Parthasarathi R (partr); 'Henry Lum'; Paul Kyzivat (pkyzivat); >>> 'Leon Portman' >>> |Cc: 'siprec@ietf.org' >>> |Subject: RE: [siprec] start/stop times& the metamodel >>> | >>> |After the use-case Paul described, it seem to me that if >> we keep out of >>> >>> |scope it will put a lot of burden on the SRS to support >> synchronized >>> |querying/playback which looks an important aspect for >> media recording. >>> So, we may want to consider the ways in which the SRC can >> facilitate it. >>> | >>> |Muthu >>> | >>> ||-----Original Message----- >>> ||From: Parthasarathi R (partr) >>> ||Sent: Wednesday, April 13, 2011 11:20 AM >>> ||To: Henry Lum; Muthu ArulMozhi Perumal (mperumal); Paul Kyzivat=20 >>> ||(pkyzivat); Leon Portman >>> ||Cc: siprec@ietf.org >>> ||Subject: RE: [siprec] start/stop times& the metamodel >>> || >>> ||Henry, >>> || >>> ||I attached the follow up mail to below mail thread. Till >> now, We don't >>> >>> ||have strong requirement to solve in SIPREC. Let us identify the=20 >>> ||requirement before going to the >>> |solution. >>> || >>> ||Thanks >>> ||Partha >>> || >>> ||-----Original Message----- >>> ||From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 >>> ||Behalf Of Henry Lum >>> ||Sent: Wednesday, April 13, 2011 2:43 AM >>> ||To: Muthu ArulMozhi Perumal (mperumal); Paul Kyzivat >> (pkyzivat); Leon >>> ||Portman >>> ||Cc: siprec@ietf.org >>> ||Subject: Re: [siprec] start/stop times& the metamodel >>> || >>> ||I don't think it is guaranteed that participants will >> send SR reports >>> ||(or any RTCP), plus we will also have to assume that the NTP=20 >>> ||timestamps are in sync. We could mandate the SRC to generate SR=20 >>> ||reports but then we are fixing the RTP model for >>> |the SRC. >>> || >>> ||Regards, >>> ||Henry >>> || >>> ||> -----Original Message----- >>> ||> From: Muthu ArulMozhi Perumal (mperumal) >> [mailto:mperumal@cisco.com] >>> ||> Sent: Monday, April 11, 2011 10:45 PM >>> ||> To: Henry Lum; Paul Kyzivat (pkyzivat); Leon Portman >>> ||> Cc: siprec@ietf.org >>> ||> Subject: RE: [siprec] start/stop times& the metamodel >>> ||> >>> ||> While I see it may be useful for the SRS to know when >> certain things >>> >>> ||> happened in CS signaling (participant joining, >> leaving, going mute >>> ||etc) >>> ||> I don't see how useful it would be for it know how >> those things are >>> ||> related to when the participant actually sent/received >> (or stopped >>> ||> sending/receiving) RTP. >>> ||> >>> ||> If we see any use, one way to do it is using the NTP timestamp >>> ||> carried in RTCP SR reports, provided the SRC, SRS and the >>> ||> participants have access to the same reference wallclock. >>> ||> >>> ||> Muthu >>> ||> >>> ||> |-----Original Message----- >>> ||> |From: siprec-bounces@ietf.org >> [mailto:siprec-bounces@ietf.org] On >>> ||> Behalf Of Henry Lum >>> ||> |Sent: Tuesday, April 12, 2011 2:56 AM >>> ||> |To: Paul Kyzivat (pkyzivat); Leon Portman >>> ||> |Cc: siprec@ietf.org >>> ||> |Subject: Re: [siprec] start/stop times& the metamodel >>> ||> | >>> ||> |A related question on the RTP model is that if the >> SRC as an RTP >>> ||> |translator chooses to relay the RTP timestamps, then >> how would the >>> ||SRC >>> ||> |synchronize the timestamps between the SIP messages >> the multiple >>> ||> |RTP streams? >>> ||> | >>> ||> |Henry >>> ||> | >>> ||> |> -----Original Message----- >>> ||> |> From: siprec-bounces@ietf.org >> [mailto:siprec-bounces@ietf.org] On >>> >>> ||> |> Behalf Of Paul Kyzivat >>> ||> |> Sent: Monday, April 11, 2011 1:06 PM >>> ||> |> To: Leon Portman >>> ||> |> Cc: siprec@ietf.org >>> ||> |> Subject: Re: [siprec] start/stop times& the metamodel >>> ||> |> >>> ||> |> >>> ||> |> >>> ||> |> On 4/11/2011 9:36 AM, Leon Portman wrote: >>> ||> |> > Paul Hi >>> ||> |> > >>> ||> |> > I agree with proposed method of time stamping >> metadata elements >>> ||> with >>> ||> |> SRC clock (it is like a wall clock from the requirement >>> document). >>> ||> |> > About RTP time synchronization to metadata >> events, we either >>> ||> should >>> ||> |> have some low latency event from SRC to SRS with >> SRC time that >>> ||> |> will allow SRS to maintain time difference between >> its clock and >>> ||> |> SRC >>> ||> clock >>> ||> |> and then apply it also to receive time of RTP >> packet (assuming no >>> ||> |> buffering) >>> ||> |> >>> ||> |> ISTM the issue isn't the latency of the event - it >> is what it is >>> ||> |> - >>> ||> but >>> ||> |> rather how to correlate a sip message containing >> metadata with a >>> ||> |> particular RTP packet. I suspect that needs to be >> tied into the >>> ||> |> discussion of the various models for how the SRC >> might handle >>> RDP. >>> ||> |> >>> ||> |> Thanks, >>> ||> |> Paul >>> ||> |> >>> ||> |> > Leon >>> ||> |> > >>> ||> |> > -----Original Message----- >>> ||> |> > From: siprec-bounces@ietf.org >> [mailto:siprec-bounces@ietf.org] >>> ||> |> > On >>> ||> |> Behalf Of Paul Kyzivat >>> ||> |> > Sent: Monday, April 11, 2011 4:03 PM >>> ||> |> > To: Elwell, John >>> ||> |> > Cc: siprec@ietf.org >>> ||> |> > Subject: Re: [siprec] start/stop times& the metamodel >>> ||> |> > >>> ||> |> > >>> ||> |> > >>> ||> |> > On 4/8/2011 11:53 AM, Elwell, John wrote: >>> ||> |> >> Paul, >>> ||> |> >> >>> ||> |> >> I think much of what you say makes sense. I >> was concerned that >>> ||we >>> ||> |> probably need to record when a participant stops or starts >>> ||> |> sending >>> ||> or >>> ||> |> receiving a stream, which seems to be covered by >> your statement: >>> ||> |> "Changes to media streams should similarly be >> tagged with the >>> ||> |> time >>> ||> |they >>> ||> |> occurred in the CS signaling. Each participant relationship >>> ||> |> change (send, receive, inactive,) will be there." >> That doesn't >>> ||> |> seem to be >>> ||> in >>> ||> |> the model at present. >>> ||> |> > >>> ||> |> > John, >>> ||> |> > >>> ||> |> > I agree the current model doesn't reflect this >> - it was a >>> ||> |> > private >>> ||> |> thought by me, provoked by the work and discussion >> to date. It is >>> >>> ||> |> a >>> ||> |bit >>> ||> |> of a change of direction, so I'm interested in >> what others think >>> ||> about >>> ||> |> it. >>> ||> |> > >>> ||> |> > Thanks, >>> ||> |> > Paul >>> ||> |> > >>> ||> |> >> John (as individual) >>> ||> |> >> >>> ||> |> >> >>> ||> |> >>> -----Original Message----- >>> ||> |> >>> From: siprec-bounces@ietf.org >>> ||> |> >>> [mailto:siprec-bounces@ietf.org] On Behalf Of >> Paul Kyzivat >>> ||> |> >>> Sent: 06 April 2011 22:28 >>> ||> |> >>> To: siprec@ietf.org >>> ||> |> >>> Subject: [siprec] start/stop times& the metamodel >>> ||> |> >>> >>> ||> |> >>> In Prague, one of the open issues was around >> start/stop >>> times. >>> ||> The >>> ||> |> >>> format draft floated the possibility of >> having explicit >>> ||> start/stop >>> ||> |> >>> times signaled for each of the metatdata >> elements. But then >>> ||> |> >>> we >>> ||> |> asked >>> ||> |> >>> for feedback on which make sense. >>> ||> |> >>> >>> ||> |> >>> IMO explicit start/stop times make more sense >> for some things >>> ||> than >>> ||> |> >>> others. >>> ||> |> >>> >>> ||> |> >>> One place where we potentially have explicit >> times to report >>> ||> with >>> ||> |> the >>> ||> |> >>> dialogs that constitute a CS. Each such >> dialog presumably has >>> >>> ||> |> >>> a >>> ||> |> start >>> ||> |> >>> and stop time observable by the SRC, which >> might differ, at >>> ||> least >>> ||> |a >>> ||> |> >>> bit, from the corresponding signaling on the RS. >>> ||> |> >>> >>> ||> |> >>> We might want to report those times. Or, >> since we abstract >>> ||> |> >>> the >>> ||> CS >>> ||> |> >>> away from the dialog, we might want to report >> the start time >>> ||> |> >>> of >>> ||> |the >>> ||> |> >>> first dialog in the CS as the CS start time, >> and the stop >>> ||> |> >>> time >>> ||> of >>> ||> |> the >>> ||> |> >>> last dialog in the CS as the CS stop time. >>> ||> |> >>> >>> ||> |> >>> Similarly, we have abstracted media streams >> away from the >>> ||> |> >>> media streams in the sip dialogs that make up >> the CS. We >>> ||> |> >>> might want >>> ||to >>> ||> |> >>> report the start time of a media stream as the time >>> ||> |> >>> (according >>> ||> to >>> ||> |> the >>> ||> |> >>> CS) of the first participant to a new media >> stream, and the >>> ||stop >>> ||> |> time >>> ||> |> >>> as the time that the last participant leaves the media >>> stream. >>> ||> |> >>> >>> ||> |> >>> There are several things that complicate this: >>> ||> |> >>> >>> ||> |> >>> - Do we consider the case of a stream that starts with >>> recvonly >>> ||> |> >>> or inactive participants, and only later >> gets a sender? >>> ||> |> >>> If >>> ||> |so, >>> ||> |> >>> is the start time of the stream when the first >>> ||> |> >>> participant >>> ||> |> arrived, >>> ||> |> >>> or when the first sender arrived? >>> ||> |> >>> >>> ||> |> >>> - How do we get the clock times for the media streams? >>> ||> |> >>> IIUC the correct ones are in the >> RTP/RTCP, but the >>> ||> reporting >>> ||> |> of >>> ||> |> >>> these events is driven by the signaling, >> and we don't >>> ||> |> >>> have >>> ||> |> good >>> ||> |> >>> sync between those. (E.g. media could >> start flowing >>> ||> |> >>> before >>> ||> |the >>> ||> |> >>> corresponding signaling, and we would >> like to include >>> ||> |> >>> that >>> ||> if >>> ||> |> we >>> ||> |> >>> can figure it out.) So, even if the >> clocks used for >>> ||> |> >>> media >>> ||> and >>> ||> |> >>> signaling are in sync, we might see >> media packets arrive >>> ||> with >>> ||> |> >>> a timestamp prior to the timestamp for >> the signaling >>> that >>> ||> |> >>> indicates the send state of the >> participant. This could >>> ||> cause >>> ||> |> >>> trouble in playback. >>> ||> |> >>> >>> ||> |> >>> - There isn't any guarantee that the clock >> used for signaling >>> ||> |> >>> messages is synchronized with the clock used in >>> RTP/RTCP. >>> ||> |> >>> >>> ||> |> >>> - There isn't any guarantee that there will >> be any RTCP at >>> all, >>> ||> |> >>> to provide correlation of the RTP to clocktime. >>> ||> |> >>> >>> ||> |> >>> The best I can see to deal with all of this is: >>> ||> |> >>> >>> ||> |> >>> - All the metadata messages should be >> timestamped by the SRC >>> ||> |> >>> using its local clock. This is easily >> achieved by the >>> Date >>> ||> |> >>> header in the sip message. >>> ||> |> >>> >>> ||> |> >>> - Changes to a CS, including changes of >> participants, should >>> ||> |> >>> be explicitly tagged with the time they >> occurred in the >>> ||> |> >>> CS signaling, according to the SRC's >> clock. (If that is >>> ||> |> >>> unavailable for some reason, then use >> the time the SRC >>> ||> |> >>> became aware of it.) >>> ||> |> >>> >>> ||> |> >>> - We could provide a metadata update element >> to indicate end >>> ||> |> >>> of a CS, but I suggest this just be shorthand for >>> ||> indicating >>> ||> |> >>> removal of all participants from it. >> (While its possible >>> ||to >>> ||> |> >>> mark that the CS is truly ended, that >> simply introduces >>> an >>> ||> |> >>> error case if added metadata about it is >> subsequently >>> ||> sent.) >>> ||> |> >>> The actual start/stop time would be >> determined by the >>> SRS >>> ||> |> >>> based on the timestamps of first and >> last data about it. >>> ||> |> >>> >>> ||> |> >>> - Changes to media streams should similarly >> be tagged with >>> ||> |> >>> the time they occurred in the CS signaling. Each >>> ||> participant >>> ||> |> >>> relationship change (send, receive, >> inactive,) will be >>> ||> there. >>> ||> |> >>> The actual start/stop time of the media >> stream again >>> ||> |> >>> would >>> ||> be >>> ||> |> >>> derived by the SRS. >>> ||> |> >>> >>> ||> |> >>> - CS-Groups can simply be tagged by the >> timestamps of the >>> ||> |> >>> updates that put CSs into them. Explicit >> start/stop >>> ||> |> >>> times >>> ||> |> don't >>> ||> |> >>> seem useful. If desired, the SRS can >> derive start/stop >>> ||> times >>> ||> |> >>> from the start/stop times of the contained stuff. >>> ||> |> >>> >>> ||> |> >>> - I now think that CS-Groups should not be >> "contained" within >>> ||> |> >>> a recording. This just seems to >> introduce unnecessary >>> ||error >>> ||> |> >>> conditions, and limitations on future >> enhancements. The >>> ||> |> >>> lifetime of CS-Groups will probably be >> naturally limited >>> ||by >>> ||> |> >>> the ability of the SRC to remember the >> IDs of old ones. >>> ||> |> >>> For instance, if a CS-G is created >> during one Recording, >>> ||> |> >>> and then another CS is added to it from >> a different >>> ||> recording >>> ||> |> >>> session, would we prefer to fail that, >> or just allow it? >>> ||> |> >>> (I think allow.) >>> ||> |> >>> >>> ||> |> >>> - Rather, I think every update transmitted >> during a recording >>> ||> |> >>> session can be tagged with a link to the >> metadata of the >>> ||> |> >>> recording session it came from. This need not be >>> ||> |> >>> explicit >>> ||- >>> ||> |> the >>> ||> |> >>> SRS can do it automatically. The >> recording session >>> entity >>> ||> |> >>> itself will also have a start/stop time >> which is the >>> ||start/ >>> ||> |> >>> stop of the RS dialog as observed by the SRS. >>> ||> |> >>> >>> ||> |> >>> (Note the above doesn't solve the problem of >> getting correct >>> ||> clock >>> ||> |> >>> times for RTP media. If anyone has a >> suggestion for this I'm >>> ||all >>> ||> |> >>> ears.) >>> ||> |> >>> >>> ||> |> >>> Thanks, >>> ||> |> >>> Paul >>> ||> |> >>> _______________________________________________ >>> ||> |> >>> siprec mailing 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 >>> ||> | >>> ||> | >>> ||> >>> >> |||----------------------------------------------------------- >> ---------- >>> |||- >>> ||> - >>> ||> ------------------------------- >>> ||> |------------- >>> ||> |CONFIDENTIALITY NOTICE: This e-mail and any files attached=20 >>> ||> 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. >>> ||> | >>> ||> |_______________________________________________ >>> ||> |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=20 >>> ||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=20 >>> |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. >>> || >>> ||_______________________________________________ >>> ||siprec mailing list >>> ||siprec@ietf.org >>> ||https://www.ietf.org/mailman/listinfo/siprec >>> >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >> > From eckelcu@cisco.com Fri Apr 15 07:55:32 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id AD095E0890; Fri, 15 Apr 2011 07:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.105 X-Spam-Level: X-Spam-Status: No, score=-10.105 tagged_above=-999 required=5 tests=[AWL=-0.106, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bobbUuUSNmIo; Fri, 15 Apr 2011 07:55:28 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfc.amsl.com (Postfix) with ESMTP id C689EE06BA; Fri, 15 Apr 2011 07:55:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=13025; q=dns/txt; s=iport; t=1302879327; x=1304088927; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=Pm8WADuWCEr124yapDRxj+/B6Hps9EVBAueLKwwV3cU=; b=VNyVwmY+/0tCv8mckjlHD06ByXCbQqgzc+0djF5GZOIeHrBX6/k9r4qz 8loLpvux4D1lg1I72yNSzFANsey7Z6buUeH3ZWqEDRQ4/wc1/sjPwGjlQ f5nk0AaDiVLZUH29txtFYSAQpVQ+l/MsXe0s4h9FLWa+6lBX8TncuUsp1 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmwBABxcqE2rRDoJ/2dsb2JhbACYBI1/d6conHqCIV2CcASFYIwT X-IronPort-AV: E=Sophos;i="4.64,219,1301875200"; d="scan'208";a="338371160" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-2.cisco.com with ESMTP; 15 Apr 2011 14:55:27 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3FEtRFX002425; Fri, 15 Apr 2011 14:55:27 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 15 Apr 2011 07:55:26 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 15 Apr 2011 07:55:26 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] LastCall:(UseCases andRequirementsforSIP-basedMediaRecording (SIPREC)) toInformational RFC Thread-Index: Acv0WYBeRuGjGNBtTZSHeqn78QP5xwGEv6YwAAlHtwAAAvtH0AABcMXAAAdJn6AAAIZ7cAAHjozgAAa08QAACpF8MAAVoayQ References: <20110406125020.17538.70016.idtracker@localhost><1D062974A4845E4D8A343C65380492020533BB70@XMB-BGL-414.cisco.com><07465C1D981ABC41A344374066AE1A2C38AB73D00B@TLVMBX01.nice.com><07465C1D981ABC41A344374066AE1A2C38AB73D110@TLVMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD06009D00@XMB-BGL-417.cisco.com><1D062974A4845E4D8A343C65380492020533BD38@XMB-BGL-414.cisco.com> From: "Charles Eckel (eckelcu)" To: "Parthasarathi R (partr)" , "Muthu ArulMozhi Perumal (mperumal)" , "Ram Mohan R (rmohanr)" , "Leon Portman" , "Elwell, John" , X-OriginalArrivalTime: 15 Apr 2011 14:55:26.0990 (UTC) FILETIME=[27F2D2E0:01CBFB7D] Cc: siprec@ietf.org Subject: Re: [siprec] LastCall:(UseCases andRequirementsforSIP-basedMediaRecording (SIPREC)) toInformational RFC X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 15 Apr 2011 14:55:32 -0000 I suppose the most common case of multiple CS from a single SRC is a conference focus acting as SRC. In this case, the SRC could help synchronization of the individual CSs as part of sending to RS. Perhaps it is not required to do so, but it should if it can. For the case of multiple SRCs which you say is out of scope, I do not see anything in the requirements that says otherwise, but it was always my assumption that you could have multiple SRCs. For example, a point to point call and each sends its stream to RS. I will reread the requirements more closely. Cheers, Charles > -----Original Message----- > From: Parthasarathi R (partr) > Sent: Thursday, April 14, 2011 10:26 PM > To: Charles Eckel (eckelcu); Muthu ArulMozhi Perumal (mperumal); Ram Mohan R (rmohanr); Leon Portman; > Elwell, John; ietf@ietf.org > Cc: siprec@ietf.org > Subject: RE: [siprec] LastCall:(UseCases andRequirementsforSIP- > basedMediaRecording (SIPREC)) toInformational RFC >=20 > Charles, >=20 > synchronize multiple CS from multiple SRCs to single SRS is outside the scope of SIPREC. I'm not very > clear about the requirement of media synchronization for multiple CS from single SRC because each CS > have its own media stream, is there any need to synchronize between multiple CS? >=20 > Muthu, >=20 > I'm seeing two requirement here: >=20 > 1) Timestamp synchronization between metadata and media stream. >=20 > This is possible to be achieved by current metadata media stream start& stop time wherein media packet > shall be stored or played back with the reference to start time of media stream block. Say Media > stream start time as T0 and end time as T1, the first media packet is received at T0+ t[i] wherein > t[i] is the time interval between T0 and first media packet. Here T0+t[i] is always less than T1. > Playback shall use T0 as the reference value. Here there is no need of extra time reference required. >=20 > 2) Timestamp synchronization between multiple media stream (audio + video) >=20 > New requirement is to synchronize between media stream and there is need to identify the detailed > requirement. Infact, I'm still not very much clear which may be due to my lack of specific details > about audio+Video recording. >=20 > Please correct in case I'm missing something. >=20 > Thanks > Partha >=20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Charles Eckel (eckelcu) > Sent: Friday, April 15, 2011 4:59 AM > To: Muthu ArulMozhi Perumal (mperumal); Ram Mohan R (rmohanr); Leon Portman; Elwell, John; > ietf@ietf.org > Cc: siprec@ietf.org > Subject: Re: [siprec] LastCall:(Use Cases andRequirements forSIP- > basedMediaRecording (SIPREC)) toInformational RFC >=20 > I was thinking we needed a way to synchronize media from multiple CSs, which may be received by the > SRS from one or more SRCs. Is this not a requirement? >=20 > Thanks, > Charles >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Muthu ArulMozhi Perumal > > (mperumal) > > Sent: Thursday, April 14, 2011 1:42 PM > > To: Ram Mohan R (rmohanr); Leon Portman; Elwell, John; ietf@ietf.org > > Cc: siprec@ietf.org > > Subject: Re: [siprec] Last Call:(Use > Cases andRequirements forSIP-based > > MediaRecording (SIPREC)) toInformational RFC > > > > I agree with John that these seem more like part of a solution rather > > than actual requirements. In addition, sending the wallclock time at > > media start/end alone may not suffice for achieving inter-media > > synchronization and playback, instead we may need to send the > wallclock > > time periodically, like RTCP. For e.g, if there is a codec > renegotiation > > in CS the RTP timestamp can restart from a random value. If silence > > suppression is enabled there would be gaps in the RTP timestamp. > > > > These are things that need to be discussed as part of the solution -- > > the requirement itself should be generic enough, like what I > described. > > REQ-022 and REQ-023 we have doesn't seem to clearly indicate the > > purpose. > > > > Muthu > > > > |-----Original Message----- > > |From: Ram Mohan R (rmohanr) > > |Sent: Thursday, April 14, 2011 10:13 PM > > |To: Leon Portman; Elwell, John; Muthu ArulMozhi Perumal (mperumal); > > ietf@ietf.org > > |Cc: siprec@ietf.org > > |Subject: RE: [siprec] Last Call: (Use > > Cases andRequirements for SIP- > > |based MediaRecording (SIPREC)) toInformational RFC > > | > > |We already have attributes Start-Time / End-time in Media Stream > > block. This is for the same purpose > > |to indicate the wall clock time for start/end of media. > > | > > |Ram > > | > > |> -----Original Message----- > > |> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > |> Behalf Of Leon Portman > > |> Sent: Thursday, April 14, 2011 9:57 PM > > |> To: Elwell, John; Muthu ArulMozhi Perumal (mperumal); ietf@ietf.org > > |> Cc: siprec@ietf.org > > |> Subject: Re: [siprec] Last Call: (Use > > |> Cases andRequirements for SIP-based MediaRecording (SIPREC)) > > |> toInformational RFC > > |> > > |> I am not sure that having wall clock only for CS start is enough, > > |> especially for partial metadata update. I will prefer to have on > > media > > |> level > > |> > > |> Leon > > |> > > |> -----Original Message----- > > |> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > |> Sent: Thursday, April 14, 2011 3:58 PM > > |> To: Leon Portman; Muthu ArulMozhi Perumal (mperumal); ietf@ietf.org > > |> Cc: siprec@ietf.org > > |> Subject: RE: [siprec] Last Call: > (Use > > |> Cases andRequirements for SIP-based Media Recording (SIPREC)) > > |> toInformational RFC > > |> > > |> Understood, but if we have wall clock time for the start of a CS, > > |> wouldn't that be sufficient? The new requirement would cover > > |> synchronization of all media start/stops relative to that time. > > |> > > |> John (as individual) > > |> > > |> > > |> > -----Original Message----- > > |> > From: Leon Portman [mailto:Leon.Portman@nice.com] > > |> > Sent: 14 April 2011 13:19 > > |> > To: Elwell, John; Muthu ArulMozhi Perumal (mperumal); > ietf@ietf.org > > |> > Cc: siprec@ietf.org > > |> > Subject: RE: [siprec] Last Call: > > |> > (Use Cases andRequirements for > > |> > SIP-based Media Recording (SIPREC)) toInformational RFC > > |> > > > |> > Actually REQ-022 and REQ-023 describing not only requirement to > > |> > synchronize between different media streams but more importantly > > |> > ability to relate them to real world (wall) clock. It is not only > > |> > important to playback them correctly but also to know when it was > > |> > said. > > |> > One example is continue trading after closing hour (even for one > > |> > second is not allowed) > > |> > > > |> > And if these media are synchronized to wall clock then they are > > also > > |> > synchronized between them thus I am not sure if we need this > > |> > additional requirement. > > |> > > > |> > Thanks > > |> > > > |> > Leon > > |> > > > |> > -----Original Message----- > > |> > From: siprec-bounces@ietf.org > > |> > [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > > |> > Sent: Thursday, April 14, 2011 1:54 PM > > |> > To: Muthu ArulMozhi Perumal (mperumal); ietf@ietf.org > > |> > Cc: siprec@ietf.org > > |> > Subject: Re: [siprec] Last Call: > > |> > (Use Cases andRequirements for > > |> > SIP-based Media Recording (SIPREC)) toInformational RFC > > |> > > > |> > > > |> > > > |> > > > |> > > -----Original Message----- > > |> > > From: siprec-bounces@ietf.org > > |> > > [mailto:siprec-bounces@ietf.org] On Behalf Of Muthu > > |> > ArulMozhi Perumal > > |> > > (mperumal) > > |> > > Sent: 14 April 2011 07:34 > > |> > > To: ietf@ietf.org > > |> > > Cc: siprec@ietf.org > > |> > > Subject: Re: [siprec] Last Call: > > |> > > (Use Cases andRequirements for > > |> > > SIP-based Media Recording (SIPREC)) toInformational RFC > > |> > > > > |> > > I've one major comment. It draft discusses synchronization > > |> > between the > > |> > > recorded media streams and synchronized playback, which > > |> > seem important > > |> > > for certain applications: > > |> > > > > |> > > > > |> > > Some applications require the recording of more than one > > |> > media stream, > > |> > > possibly of different types. Media are synchronized, either > > |> > at storage > > |> > > or at playback. > > |> > > > > |> > > > > |> > > However, in the requirements section it doesn't seem REQ-022 > and > > |> > > REQ-023 are all that are need and sufficient to achieve this > with > > |> > > needed precision. So, I would suggest adding another > requirement > > as > > |> > > follows: > > |> > > The mechanism MUST provide means for facilitating > > |> > synchronization of > > |> > > the recorded media streams and metadata either at storage or at > > |> > > playback. > > |> > > This includes, but not limited to, the information needed as > per > > |> > > REQ-022 and REQ-023. > > |> > [JRE] This seems a reasonable addition. I wonder if the new > > |> > requirement (first sentence only) is sufficient as a > > |> > **replacement** for REQ-022 and REQ-023. On reading REQ-022 and > > |> > REQ-023 again, it is not so clear what their purpose was, and > they > > |> > seem to be more like a solution than a requirement. > > |> > One purpose would certainly be that covered by Muthu's new > > |> > requirement. Was there any other purpose? > > |> > > > |> > John > > |> > > > |> > > > > |> > > A nitpick: > > |> > > Use Case 8 > > |> > > In cases where calls inside or between branches must be > recorded, > > a > > |> > > centralized recording system in data centers together with > > |> > telephony > > |> > > infrastructure (e.g. PBX) me deployed. > > |> > > > > |> > > s/me/may be > > |> > > > > |> > > Muthu > > |> > > > > |> > > |-----Original Message----- > > |> > > |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] > > On > > |> > > Behalf Of The IESG > > |> > > |Sent: Wednesday, April 06, 2011 6:20 PM > > |> > > |To: IETF-Announce > > |> > > |Cc: siprec@ietf.org > > |> > > |Subject: [siprec] Last Call: > > |> > > (Use Cases > > |> > > andRequirements for SIP-based > > |> > > |Media Recording (SIPREC)) toInformational RFC > > |> > > | > > |> > > | > > |> > > |The IESG has received a request from the SIP Recording WG > > |> > (siprec) to > > |> > > |consider the following document: > > |> > > |- 'Use Cases and Requirements for SIP-based Media > > |> > Recording (SIPREC)' > > |> > > | as an Informational RFC > > |> > > | > > |> > > |The IESG plans to make a decision in the next few weeks, > > |> > and solicits > > |> > > |final comments on this action. Please send substantive > > |> > > comments to the > > |> > > |ietf@ietf.org mailing lists by 2011-04-20. Exceptionally, > > |> > > comments may > > |> > > be > > |> > > |sent to iesg@ietf.org instead. In either case, please retain > the > > |> > > |beginning of the Subject line to allow automated sorting. > > |> > > | > > |> > > |The file can be obtained via > > |> > > |http://datatracker.ietf.org/doc/draft-ietf-siprec-req/ > > |> > > | > > |> > > |IESG discussion can be tracked via > > |> > > |http://datatracker.ietf.org/doc/draft-ietf-siprec-req/ > > |> > > | > > |> > > | > > |> > > | > > |> > > |No IPR declarations have been submitted directly on this I-D. > > |> > > |_______________________________________________ > > |> > > |siprec mailing list > > |> > > |siprec@ietf.org > > |> > > |https://www.ietf.org/mailman/listinfo/siprec > > |> > > _______________________________________________ > > |> > > siprec mailing list > > |> > > siprec@ietf.org > > |> > > https://www.ietf.org/mailman/listinfo/siprec > > |> > > > > |> > _______________________________________________ > > |> > siprec mailing list > > |> > siprec@ietf.org > > |> > https://www.ietf.org/mailman/listinfo/siprec > > |> > > > |> _______________________________________________ > > |> siprec mailing list > > |> siprec@ietf.org > > |> https://www.ietf.org/mailman/listinfo/siprec > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From rmohanr@cisco.com Fri Apr 15 08:04:59 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 09960E08C3 for ; Fri, 15 Apr 2011 08:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.261 X-Spam-Level: X-Spam-Status: No, score=-9.261 tagged_above=-999 required=5 tests=[AWL=-1.062, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9hxocL8fniX0 for ; Fri, 15 Apr 2011 08:04:54 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfc.amsl.com (Postfix) with ESMTP id 5423FE08C1 for ; Fri, 15 Apr 2011 08:04:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=31058; q=dns/txt; s=iport; t=1302879893; x=1304089493; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=UXN37385DKwyxJ8d3HioWhwOfXLOq/iqvVi2GqxQ9dg=; b=kD+7+E2ug87OIPvGlCkYYRvbhmh3/ODExCIBPEIb/aMM7DG2jWQsHPAZ WZGScViG1T9rqnyR+xbiQ5QNFwZl1GtWhVZH+fuey30z705H15tIDfrFZ Q0bejPifDOsnWKGe6iVNVngK0VJMLZZLc+Fypjz7fzaa8mVwBTVdWWz9F Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjcBAJNdqE2Q/khLgWdsb2JhbACYBI1/FAEBFiYliG+eRJx6gn+CbwSFXowV X-IronPort-AV: E=Sophos;i="4.64,219,1301875200"; d="scan'208";a="83775227" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 15 Apr 2011 15:04:52 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3FF4CSo016235; Fri, 15 Apr 2011 15:04:51 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); Fri, 15 Apr 2011 20:34:42 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-hashedpuzzle: AV4G Chzh EPXE E87+ FABw F3Sq GxpJ G4Ch LeZU Oodw PrIm TDBT Ttm0 VHbm Yfcb YjsF; 2; agBvAGgAbgAuAGUAbAB3AGUAbABsAEAAcwBpAGUAbQBlAG4AcwAtAGUAbgB0AGUAcgBwAHIAaQBzAGUALgBjAG8AbQA7AHMAaQBwAHIAZQBjAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {042EAB47-BCF8-49DD-9D78-B189B34B4F47}; cgBtAG8AaABhAG4AcgBAAGMAaQBzAGMAbwAuAGMAbwBtAA==; Fri, 15 Apr 2011 15:04:17 GMT; UgBFADoAIABbAHMAaQBwAHIAZQBjAF0AIABGAFcAOgAgAEQAbwAgAHcAZQAgAG4AZQBlAGQAIAB0AG8AIABtAG8AZABlAGwAIABwAGEAcgB0AGkAYwBpAHAAYQBuAHQAcwAgAG4AbwB0ACAAcABhAHIAdAAgAG8AZgBDAFMAIABiAHUAdABhAHMAcwBvAGMAaQBhAHQAZQBkACAAdwBpAHQAaAAgAE0AZQBkAGkAYQAgAFMAdAByAGUAYQBtACAAYgBsAG8AYwBrACAAaQBuACAAdABoAGUAIABtAGUAdABhAGQAYQB0AGEAbQBvAGQAZQBsACAAPwAJACgAdwBhAHMAIABSAEUAOgAgAFAAYQByAHQAaQBhAGwAIAB1AHAAZABhAHQAZQBzACAAYQBuAGQAIABpAGQAZQBuAHQAaQBmAGkAZQByAHMAKQA= x-cr-puzzleid: {042EAB47-BCF8-49DD-9D78-B189B34B4F47} Content-class: urn:content-classes:message Date: Fri, 15 Apr 2011 20:34:17 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD061332DC@XMB-BGL-417.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] FW: Do we need to model participants not part ofCS butassociated with Media Stream block in the metadatamodel ? (was RE: Partial updates and identifiers) Thread-Index: Acv0jVXI4ji2YTo+SquJ6T6YR3i+lQAdOkDgAEETmvAAg54qsAADKDEgAADSn+AAEAO1UAANZylQABBzW2AABHtBwACZNyqAAAGC+nAAAd/QMAAHC/qg References: <35BCE99A477D6A4986FB2216D8CF2CFD061331FF@XMB-BGL-417.cisco.com> From: "Ram Mohan R (rmohanr)" To: "Parthasarathi R (partr)" , "Elwell, John" , X-OriginalArrivalTime: 15 Apr 2011 15:04:42.0910 (UTC) FILETIME=[734D7BE0:01CBFB7E] Subject: Re: [siprec] FW: Do we need to model participants not part ofCS butassociated with Media Stream block in the metadatamodel ? (was RE: Partial updates and identifiers) X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 15 Apr 2011 15:04:59 -0000 I am ok with associating participants behind a UA [ for case where UA is capable of learning them] in CS as part of that CS in the model/format. One question I have is, Do we need to distinguish these participants from the others by having some attributes as part of participant block? Or is it sufficient if we just treat them as any other participants of CS. There are three categories of participants: Participants who contribute both signaling and media to CS Participants who contribute only media in the CS [ like the below case] Participants who contribute only signaling to CS [e.g. 3pcc controller] Ram > -----Original Message----- > From: Parthasarathi R (partr) > Sent: Friday, April 15, 2011 5:28 PM > To: Elwell, John; Ram Mohan R (rmohanr); siprec@ietf.org > Subject: RE: [siprec] FW: Do we need to model participants not part > ofCS butassociated with Media Stream block in the metadatamodel ? (was > RE: Partial updates and identifiers) >=20 > John point of view looks reasonable to me because CS is not directly > associated with dialogs but instead it represents session with the list > of participant involved in it. >=20 > In case of participant list received through conference package to SRC > with UA, those multiple participants from focus shall be represented as > individual participant block who are pointed to single mixed media > stream metadata block and all participant belongs within single > conference CS in this scenario. The model is as follows (part in the > diagram represents participant): >=20 >=20 > RS > | > CS------------------------------- > | | > ----------------------- part5(SRC) > | | | | | > | | | | media stream2 > part1 part2 part3 part4 > | | | | > ------------------------- > | > Media stream1 >=20 > Thanks > Partha >=20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Elwell, John > Sent: Friday, April 15, 2011 4:34 PM > To: Ram Mohan R (rmohanr); siprec@ietf.org > Subject: Re: [siprec] FW: Do we need to model participants not part > ofCS butassociated with Media Stream block in the metadatamodel ? (was > RE: Partial updates and identifiers) >=20 > As an individual, my opinion, which I have pretty much stated before, > is that a participant must always be part of a CS. A couple of > situations have been mentioned where alternatives might be required, > but I don't believe so. >=20 > 1. Conferences. I think depending what view the SRC has of the CS, > there are two situations: >=20 > (a) The SRC sees all parties in the conference and has visibility of > what Media Streams each party sends and receives. In this case, I think > the whole conference can be modelled as a CS and each party can be > modelled as a Participant in that CS. Such a view will typically be > feasible when the SRC is located at a conference focus/mixer (e.g., an > MCU). >=20 > (b) The SRC sees the conference focus mixer as a party but has limited > information about parties behind the focus/mixer. In this case I think > the SRC can regard the CS as terminating at the conference > (focus/mixer), with the conference a Participant in that CS. > Information about parties behind the conference may or may not be > available, in which case they can be additional attributes of the > conference Participant object. One typical case will be where the SRC > is located at a UA of one of the conference parties, or at a B2BUA > between the focus/mixer and a party UA. In that case the CS would have > two Participants: the party concerned and the conference. Am extreme > case is where the conference is the sole Participant and just records > Media Streams sent by the conference to parties in the conference. >=20 > Hybrid situations can occur, e.g., for cascaded conferences, where > participants at one conference are modelled as Participants but other > conferences are just modelled each as a single Participant. >=20 > 2. IVR and similar. I would model the Media Server as a Participant in > the CS, i.e., there is a CS between the Media Server and the caller. >=20 > John >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf Of Ram Mohan R (rmohanr) > > Sent: 15 April 2011 10:56 > > To: siprec@ietf.org > > Subject: [siprec] FW: Do we need to model participants not part of CS > > butassociated with Media Stream block in the metadata model ? (was > RE: > > Partial updates and identifiers) > > > > I request people to provide inputs on this and help to take it to a > > closure. This issue has been open for several months now. > > > > Ram > > > > -----Original Message----- > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf Of Ram Mohan R (rmohanr) > > Sent: Tuesday, April 12, 2011 3:04 PM > > To: Elwell, John; Charles Eckel (eckelcu); Parthasarathi R (partr); > > Paul Kyzivat (pkyzivat); siprec@ietf.org > > Cc: Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr) > > Subject: [siprec] Do we need to model participants not part of CS but > > associated with Media Stream block in the metadata model ? (was RE: > > Partial updates and identifiers) > > > > Renaming the mail thread to discussion to this specific issue - > > "Metadata for participants not part of CS" which we have been > > discussing from several weeks. > > > > Please continue the other issues in original thread and lets use this > > thread to close this issue. I would request people to give inputs for > > this issue on this thread and take it to a conclusion. > > > > We(Authors of Metadata model) included participants that are not part > > of CS to imply: > > - Participants that does NOT contribute to signaling in CS but > > contributes to media The intent is to give more flexibility in the > > metamodel to represent these types of participants. > > > > Following are some of use case where this can happen- > > > > Use-Case 1: A conference where one of the participants is a SRC. In > > these case the Focus which talks to this SRC becomes part of CS > > contributing signaling as well as media. However the media includes > > media from other participants that are not part of CS. Please note > SRC > > has to subscribe to conf event packet to get this information (which > > may not be always feasible). > > > > Use-Case 2: one UA in CS works in 3pcc mode to acquire an MoH media > > stream, this might be reflected as unique source for media stream > > without having a reported signaling relationship to it. E.g is > given > > here by Henry Lum > > http://www.ietf.org/mail-archive/web/siprec/current/msg01372.html > > > > In some sense these participants are *still* part of CS as they > > contribute to CS media. > > > > There are three approaches I can see- > > Don't model the participants that does not contribute signaling in CS > > and only contribute Media Model these participants as not part of CS > > in the model but associated with Media Stream block ( current > > approach) Model these participants to be associated with CS but have > > the association labeled as "indirect participant" > > > > Let me know your thoughts. > > > > Thanks, > > Ram > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > > Behalf Of Elwell, John > > > Sent: Tuesday, April 12, 2011 12:13 PM > > > To: Charles Eckel (eckelcu); Parthasarathi R (partr); Paul Kyzivat > > > (pkyzivat); siprec@ietf.org > > > Cc: Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr) > > > Subject: Re: [siprec] Partial updates and identifiers > > > > > > I think the attached message was the last in that thread. So I > don't > > > really think we had closure. > > > > > > John > > > > > > > -----Original Message----- > > > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > > Sent: 11 April 2011 23:53 > > > > To: Elwell, John; Parthasarathi R (partr); Paul Kyzivat > > (pkyzivat); > > > > siprec@ietf.org > > > > Cc: Peter Saint-Andre (psaintan); Joe Hildebrand > > (jhildebr); Hadriel > > > > Kaplan > > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > > > Hi John, > > > > > > > > I have attached the last e-mail I have from the thread in which I > > > > first raised this issue. Unfortunately, I do not have the e-mail > > with > > > > the ultimate agreement, but maybe someone else does or this will > > help > > > > prompt some memories. > > > > > > > > Cheers, > > > > Charles > > > > > > > > > -----Original Message----- > > > > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On > > > > Behalf Of Elwell, John > > > > > Sent: Monday, April 11, 2011 9:46 AM > > > > > To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); > > > > siprec@ietf.org > > > > > Cc: Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr); > > > Hadriel > > > > Kaplan > > > > > Subject: Re: [siprec] Partial updates and identifiers > > > > > > > > > > Partha, > > > > > > > > > > Thanks for reminding me - I now recall the discussion some > > > > weeks/months ago about the participants > > > > > obtained from the conference event package. I was never > > > particularly > > > > comfortable with the fact these > > > > > were not considered part of the CS. While that might be > > > > correct if we > > > > consider the CS to be the SIP > > > > > dialog between the SRC and the conference focus, taking a > > > > broader view > > > > of CS those participants behind > > > > > the focus could be considered part of the CS. I don't > > particularly > > > > want to open up the old discussion > > > > > if people are happy with what we have, but something > > doesn't seem > > > > quite right to me. > > > > > > > > > > For example, if these "participants" are not considered part of > > the > > > > CS, and if we don't have specific > > > > > information about their involvement in media streams, do they > > > really > > > > merit being considered > > > > > Participant objects? > > > > > > > > > > In other words, two possible approaches are: > > > > > > > > > > 1) The CS extends only as far as the focus / mixer. The > > > > focus/mixer is > > > > a "Participant" and the users > > > > > behind the focus are not separate Participants but are just > > > > additional > > > > data associated with the > > > > > focus/mixer Participant. The only Media Streams we are > > > > concerned with > > > > are between the mixer and the > > > > > SRC. > > > > > > > > > > 2) The CS extends beyond the focus/mixer to users > > learned via the > > > > conference event package, each of > > > > > those users is a separate Participant object, and we > > are concerned > > > > with Media Stream objects that > > > > > those participants send and receive. I am not sure how feasible > > > this > > > > approach is, because I am not > > > > > sure that the SRC can obtain enough information about media > > > > streams at > > > > users behind the focus/mixer. > > > > > > > > > > It seems the present solution is somewhere between the > > two, which > > > is > > > > why I am uncomfortable. > > > > > > > > > > Regards, > > > > > > > > > > John (as individual) > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > > > Sent: 11 April 2011 10:29 > > > > > > To: Elwell, John; Paul Kyzivat (pkyzivat); siprec@ietf.org > > > > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe > > Hildebrand > > > > > > (jhildebr) > > > > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > > > > > > > John, > > > > > > > > > > > > Please read inline. > > > > > > > > > > > > Thanks > > > > > > Partha > > > > > > > > > > > > -----Original Message----- > > > > > > From: Elwell, John [mailto:john.elwell@siemens- > enterprise.com] > > > > > > Sent: Monday, April 11, 2011 2:11 PM > > > > > > To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); > > > > siprec@ietf.org > > > > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe > > Hildebrand > > > > > > (jhildebr) > > > > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > > > > Sent: 11 April 2011 08:35 > > > > > > > To: Elwell, John; Paul Kyzivat (pkyzivat); siprec@ietf.org > > > > > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe > > > Hildebrand > > > > > > > (jhildebr) > > > > > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > > > > > > > > > John, > > > > > > > > > > > > > > As I mentioned below, stream block will be unique > > > > within CS, (not > > > > > > > required to be unique across multiple CS) and so, xml:id or > > > > > > enhancing > > > > > > > the normative statement of RFC 4574 label attribute to be > > > unique > > > > > > > within CS will serve the purpose. I'm fine with any of the > > > above > > > > > > > mentioned id. > > > > > > > Please note that RFC 4574 "label" attribute is the nature > > > > > > data for RS > > > > > > > dialog. > > > > > > > > > > > > > > In case participant within CS, xml:id will serve the > purpose > > > but > > > > we > > > > > > > need to get more clarity about participants who are not > > > > > > part of CS but > > > > > > > > > > > > > within RS. > > > > > > [JRE] If I understand the figure in section 3 of metadata-04 > > > > > > correctly, a Participant can have a relationship with > > a CS, but > > > no > > > > > > direct relationship with an RS. > > > > > > > > > > > > Sorry, I mixed up my statement with the latest > update > > of > > > > > > making CSG optional. As per Sec 3 of metadata-04, participant > > has > > > > > > direct relationship with CSG in case CS is left completely > > > > > > unattached. In case CSG is optional, then participant > > will have > > > > > > direct relationship with RS in case there is no relationship > > > > > > between CS and participant. > > > > > > > > > > > > > > > > > > So a participant that does not have a relationship > > with a CS is > > > > left > > > > > > completely unattached, unless it has a relationship > > with a Media > > > > > > Stream (which always has a relationship with a CS). So to > > > > > > summarize: > > > > > > - a Participant can have a direct relationship with a CS; or > > > > > > - a Participant can have an indirect relationship > > with a CS (via > > > a > > > > > > Media Stream); agreed > > > > > > - a Participant can have no relationship with a CS, and > > > > therefore no > > > > > > relationship with an RS. > > > > > > Do we really need this last case? > > > > > > > > > > > > I'm happy if the last case is not required because > it > > > > > > simplify the solution and there is no need of unique id for > > > > > > participant. But SRS implementers may prefer to have > > relationship > > > > > > with participant and RS. I wish more opinion before taking > > > > > > decision whether to remove the last case > > > > > > > > > > > > > Because CS may span across different RS how about the > > > > > > participant who > > > > > > > are not part of CS? > > > > > > [JRE] I don't understand the words "Because CS may span > across > > > > > > different RS", because in the rest of the sentence you are > > > talking > > > > > > about a Participant that is not part of a CS. > > > > > > > > > > > > > Ex: One of the user in the conference acts as SRC, fetch > > > > > > participant > > > > > > > info using conferene package and new RS is created > > > > during initial > > > > > > > conference creation and hold&resume of a user within CS. > > > > > > [JRE] I am not sure what you are trying to say here. I would > > > > > > consider a user whose identity is obtained via a conference > > event > > > > > > package as being part of the CS. > > > > > > > > > > > > I'm trying to give the example where > > participant is not > > > > > > associated with CS directly but related to CSG (/RS). This > > > > > > scenario was considered as a blocking in -03 version of > > metadata. > > > > > > I'm not arguing to have this scenario but it is major concern > > for > > > > > > few folks. > > > > > > > > > > > > CS is between focus and UA, UA acts as SRC, UA receives the > > > > > > participant info via conference event package but those > > > > > > participants are not related in CS directly (and only focus > is > > > > > > related) but they contributed for the mixed stream. > > > > > > > > > > > > That user is sending/receiving Media Streams that > > are part of a > > > > > > CS, or if it isn't sending/receiving Media Streams, > > what is the > > > > > > relevance > > > > of > > > > > > that Participant? > > > > > > > > > > > > Mixed media stream from focus to UA belongs to the > > > > Conference > > > > > > event package participants. There participant are not > directly > > > > > > involved as part of CS. Why would we > > create a new RS > > > > > > for such a participant? > > > > > > RS is not created for participant. Multiple > > RS shall be > > > > > > created the same CS during the different time frame as shown > > > below > > > > > > > > > > > > <-------------------CS1-------------> > > > > > > <---RS1--> <---RS2------> > > > > > > > > > > > > CS1 is between UA (SRC) and focus whereas RS1, RS2 is > > between UA > > > > (SRC) > > > > > > and SRS. Here tangling (conference event package) participant > > has > > > > > > to be grouped together in RS1, RS2 by some means through > given > > > > > > metadata. > > > > The > > > > > > question whether this corner has to be solved ? > > > > > > > > > > > > John (as individual) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > Partha > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Elwell, John > > [mailto:john.elwell@siemens-enterprise.com] > > > > > > > Sent: Friday, April 08, 2011 9:36 PM > > > > > > > To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); > > > > > > siprec@ietf.org > > > > > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe > > > Hildebrand > > > > > > > (jhildebr) > > > > > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > > > > > > > > > Focusing just on participant and stream for the time being, > > > > > > do these > > > > > > > need to be unique across multiple CSs or not? > > > > > > > > > > > > > > John > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > > > > > Sent: 07 April 2011 10:51 > > > > > > > > To: Paul Kyzivat (pkyzivat); siprec@ietf.org; Elwell, > John > > > > > > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe > > > > Hildebrand > > > > > > > > (jhildebr) > > > > > > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > > > > > > > > > > > John, > > > > > > > > > > > > > > > > Sorry for the lengthy mail but it contains lot of > analysis > > > and > > > > > > > > reasoning for this id approach. > > > > > > > > > > > > > > > > Adding to Paul's point, I wish to give more background > and > > > > > > > reason for > > > > > > > > these globally unique id. Initially I had the impression > > that > > > > the > > > > > > > > single unique id (RS dialog-id) in the recording (session > > > > > > > level) and > > > > > > > > some relevant natural id for the rest of the element will > > > > > > serve the > > > > > > > > purpose. > > > > > > > > There are usecases where this assumption fails. > > Even I have > > > > > > > thought of > > > > > > > > > > > > > > > using "xml:id" instead of URN UUID to avoid long > > string but > > > > > > > xml:id may > > > > > > > > > > > > > > > not end up with unique value always. Our analysis for URN > > > > > > UUID for > > > > > > > > each level is as follows and please provide your input in > > > case > > > > id > > > > > > > > shall be > > > > > > > > tweaked: > > > > > > > > > > > > > > > > 1) Recording block: The reason for globally unique id is > > > > > > > that multiple > > > > > > > > > > > > > > > SRC with same id to single SRS. > > > > > > > > > > > > > > > > Topology: > > > > > > > > > > > > > > > > SRC1 SRC2 > > > > > > > > | | > > > > > > > > | ----(RS1-ID1)-----SRS1 > > > > > > > > | > > > > > > > > ---(RS2-ID1)------------------SRS1 > > > > > > > > > > > > > > > > In the above topology, it is possible for ID1 is > generated > > by > > > > both > > > > > > > > SRC1 and SRC2 at the same time. > > > > > > > > > > > > > > > > 2) group (CSG) block: Grouping mechanism (Hadriel > > > > > > session-id, Paul > > > > > > > > Jones > > > > > > > > Session-UUID) is outside the scope of SIPREC. URN UUID > > > > > > > abstracts the > > > > > > > > exact mechanism to SRS and provides the information only > > > > > > about the > > > > > > > > group of CS from SRC perspective. It possible > > that group may > > > > span > > > > > > > > across multiple RS and It is up to SRS to group and view > > > > > > as single > > > > > > > > recording. > > > > > > > > Here, the single level id in the top will fail. > > The counter > > > > > > > argument > > > > > > > > is to force the single RS having complete CSG but > > > > it*may not* be > > > > > > > > possible in SRC implementation. Here, xml:id will not > > > > serve the > > > > > > > > purpose > > > > > > > > > > > > > > > > 3) session (CS) block: At the immediate look, session > > > > > > falls exactly > > > > > > > > under recording block. Use case 3 of > > draft-ietf-siprec-req-09 > > > > > > > > illustrates where CS span across multiple RS. This > > > > > > > requirement calls > > > > > > > > for unique id in session by which these session shall be > > > > > > viewed as > > > > > > > > single CS even though there is no group exists among > > > > > > them. IMO, in > > > > > > > > case session should not have globally unique id, > > then it is > > > > > > > preferred > > > > > > > > to remove usecase 3 in the requirement. > > > > > > > > > > > > > > > > 4) participant block: It needs some id which may > > be AOR but > > > > > > > AOR is not > > > > > > > > > > > > > > > unique. IMO, xml:id may serve the purpose with session > > > > > > > unique id. The > > > > > > > > trick exists for participant who are not associated with > > > > > > > CS. We shall > > > > > > > > discuss and fine tune if required. > > > > > > > > > > > > > > > > 5) stream block: Label attribute shall be used as unique > > > > > > > value but RFC > > > > > > > > 4574 does not mandate label attribute has to be unique > > across > > > > the > > > > > > > > dialog or CS and so, it may possible to change within > > > > RS and no > > > > > > > > normative statement to stop this implementation. IMO, > > > > > > > xml:id may serve > > > > > > > > > > > > > > > the purpose with session unique id. Here as well, We > shall > > > > > > > discuss and > > > > > > > > > > > > > > > fine tune if required. > > > > > > > > > > > > > > > > 6) extensiondata block: This is tracked in the separate > > > > > > mail thread > > > > > > > > whether unique id is required or not. Let us close this > > > > > > as part of > > > > > > > > that mail thread. > > > > > > > > > > > > > > > > Including explicitly Hadriel, Peter, Joe in this mail > > > > > > > thread as they > > > > > > > > have different view on this ID mechanism. > > > > > > > > > > > > > > > > I had offline discussion with Hadriel in Prague after > > > > > > > SIPREC meeting > > > > > > > > and my understanding of his major concern is that how SRS > > > > > > > will be able > > > > > > > > > > > > > > > to design the database in case partial update > > does not have > > > > > > > recording > > > > > > > > (top) id information. I'll put more thought > > > > processing to close > > > > > > > > Hadriel concern of how top id has to be tracked in case > > > > > > > partial update > > > > > > > > > > > > > > > by which SRS implementation will be simplified in terms > of > > > > > > > aggregation > > > > > > > > > > > > > > > maintenance. > > > > > > > > > > > > > > > > Thanks > > > > > > > > Partha > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: siprec-bounces@ietf.org > > > > > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul > Kyzivat > > > > > > > (pkyzivat) > > > > > > > > Sent: Thursday, April 07, 2011 12:33 AM > > > > > > > > To: siprec@ietf.org > > > > > > > > Subject: Re: [siprec] Partial updates and identifiers > > > > > > > > > > > > > > > > John, > > > > > > > > > > > > > > > > For the moment we have proposed that the ids be > > conveyed in > > > > > > > the form > > > > > > > > of URIs that are globally unique, and specifically that > > > > > > > they be UUID > > > > > > > > URNs. > > > > > > > > There is no dependency on the particular form of the URI, > > but > > > > > > > > specifying they must be UUID URNs makes it possible to > > > > > > perform some > > > > > > > > internal optimizations for storage. > > > > > > > > > > > > > > > > The UUID URN is a pretty inefficient encoding. A UUID can > > > > > > > be expressed > > > > > > > > > > > > > > > in 32 bits, so we could consider retaining UUIDs but > alter > > > the > > > > > > > > encoding if its really an issue. However I am far from > > > > > > > convinced that > > > > > > > > the size of the IDs is going to be a major issue in the > > > > > > > overall size > > > > > > > > of messages, so I think its probably premature to worry > > about > > > > it. > > > > > > > > > > > > > > > > Because the ids can be expressed in 32 bits, the SRC and > > > > > > > SRS can store > > > > > > > > > > > > > > > them internally that way, thus reducing the > > runtime cost of > > > > > > > > maintaining the data. > > > > > > > > > > > > > > > > The use of unique ids is a significant part of the > overall > > > > > > > approach to > > > > > > > > > > > > > > > formatting updates. If somebody has a different concept > > > > > > in mind it > > > > > > > > could be useful to have an alternative proposal for the > > > > > > > format. If we > > > > > > > > had two worked out approaches we could compare the > > > > > > > tradeoffs in each. > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Paul > > > > > > > > > > > > > > > > On 4/6/2011 10:24 AM, Elwell, John wrote: > > > > > > > > > Much of the discussion on draft-ram-metadata-format > > > > in Prague > > > > > > > > concerned the mechanism for performing partial updates > and > > > > > > > the use of > > > > > > > > identifiers. The draft permits partial updates by > allowing > > > > > > > individual > > > > > > > > objects (e.g., CS, participant, media stream) to be sent > > > > > > > with updated > > > > > > > > content, without having to send again other objects that > > have > > > > not > > > > > > > > changed. So, for example, in a large conference, it would > > > > > > > be possible > > > > > > > > to add or modify an individual participant object without > > > > > > having to > > > > > > > > send all the other participant objects again. I do not > > recall > > > > any > > > > > > > > opposition to this basic principle. > > > > > > > > > > > > > > > > > > However, to achieve this, every object requires an > > > > > > > > identifier, and it > > > > > > > > was asserted that these identifiers need to be globally > > > > > > > unique for all > > > > > > > > > > > > > > > time. Although this might be efficient for updating an > > > > individual > > > > > > > > object, when sending many objects (e.g., at the start of > a > > > > > > > CS or when > > > > > > > > refreshing the entire metadata), this can make the > > > > metadata very > > > > > > > > bulky. > > > > > > > > It depends, of course, on the format of the identifiers, > > > > > > and it was > > > > > > > > stated that there could be alternatives to UUID. > > > > > > Nevertheless, some > > > > > > > > people had concerns. These concerns also extended to the > > > > > > > impact on the > > > > > > > > > > > > > > > database where metadata is stored, since it might not be > > > > > > > feasible to > > > > > > > > convert to a database-friendly mechanism for linking > > > > > > > objects together. > > > > > > > > > > > > > > > > > > One alternative proposal during the meeting was > > to have a > > > > single > > > > > > > > unique identifier at the top level (for the RS) and use > > local > > > > > > > > identifiers for other objects. Thus when updating a > single > > > > > > > object, it > > > > > > > > would be necessary to include the top level identifier as > > > > > > > well as one > > > > > > > > or more local identifiers. However, there were > > also concerns > > > > this > > > > > > > > might not fulfil actual or perceived future requirements. > > > > > > > > > > > > > > > > > > Please continue discussion on this. > > > > > > > > > > > > > > > > > > John (as chair) > > > > > > > > > _______________________________________________ > > > > > > > > > siprec mailing list > > > > > > > > > siprec@ietf.org > > > > > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > siprec mailing list > > > > > > > > siprec@ietf.org > > > > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > siprec mailing 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@cisco.com Fri Apr 15 08:19:45 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DB2DFE08CA for ; Fri, 15 Apr 2011 08:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.199 X-Spam-Level: X-Spam-Status: No, score=-110.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43xEP+48CrhO for ; Fri, 15 Apr 2011 08:19:41 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfc.amsl.com (Postfix) with ESMTP id CD8BBE08CD for ; Fri, 15 Apr 2011 08:19:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=14189; q=dns/txt; s=iport; t=1302880780; x=1304090380; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=RYVtFNe6zj+KAs+CNy4VvlHe9o42DX8QGtYW4FCT2mY=; b=TYkfS70jX/3CAKYmFRGqjCjtuq/hOPSybLYSInKW5Wo+6mFsHvj8L/EZ b0CoLqyB447FPNdpqT8khzWLvxIj0K9eeyvPJnn14sGMmILL6DiIIuyPl qb2XhWcqDlvp7PmM63tSWvoUfqX4I4F6e5SeRBvUNsyY0twxIUAwvUYyy s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjcBALZhqE2Q/khMgWdsb2JhbACYBI1/FAEBFiYliG+eLpx7giFdgnAEjXiDdA X-IronPort-AV: E=Sophos;i="4.64,219,1301875200"; d="scan'208";a="25894432" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 15 Apr 2011 15:19:37 +0000 Received: from [161.44.182.250] (dhcp-161-44-182-250.cisco.com [161.44.182.250]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3FFJbQ6025518 for ; Fri, 15 Apr 2011 15:19:37 GMT Message-ID: <4DA86208.4090107@cisco.com> Date: Fri, 15 Apr 2011 11:19:36 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: siprec@ietf.org References: <20110406125020.17538.70016.idtracker@localhost><1D062974A4845E4D8A343C65380492020533BB70@XMB-BGL-414.cisco.com><07465C1D981ABC41A344374066AE1A2C38AB73D00B@TLVMBX01.nice.com><07465C1D981ABC41A344374066AE1A2C38AB73D110@TLVMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD06009D00@XMB-BGL-417.cisco.com><1D062974A4845E4D8A343C65380492020533BD38@XMB-BGL-414.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] LastCall:(UseCases andRequirementsforSIP-basedMediaRecording (SIPREC)) toInformational RFC X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 15 Apr 2011 15:19:46 -0000 On 4/15/2011 10:55 AM, Charles Eckel (eckelcu) wrote: > I suppose the most common case of multiple CS from a single SRC is a > conference focus acting as SRC. In this case, the SRC could help > synchronization of the individual CSs as part of sending to RS. Perhaps > it is not required to do so, but it should if it can. > For the case of multiple SRCs which you say is out of scope, I do not > see anything in the requirements that says otherwise, but it was always > my assumption that you could have multiple SRCs. For example, a point to > point call and each sends its stream to RS. I will reread the > requirements more closely. In this case the SRC has the option to represent this as one CS with multiple participants, or multiple CS. Some cases that *need* multiple CS are for call centers - consider a call that starts out with an IVR, gets transferred to an agent, agent puts caller on hold and does consult call with supervisor, agent drops call with supervisor and goes back to caller, supervisor connects into call in coach mode to the agent, ... Thanks, Paul > Cheers, > Charles > >> -----Original Message----- >> From: Parthasarathi R (partr) >> Sent: Thursday, April 14, 2011 10:26 PM >> To: Charles Eckel (eckelcu); Muthu ArulMozhi Perumal (mperumal); Ram > Mohan R (rmohanr); Leon Portman; >> Elwell, John; ietf@ietf.org >> Cc: siprec@ietf.org >> Subject: RE: [siprec] LastCall:(UseCases > andRequirementsforSIP- >> basedMediaRecording (SIPREC)) toInformational RFC >> >> Charles, >> >> synchronize multiple CS from multiple SRCs to single SRS is outside > the scope of SIPREC. I'm not very >> clear about the requirement of media synchronization for multiple CS > from single SRC because each CS >> have its own media stream, is there any need to synchronize between > multiple CS? >> >> Muthu, >> >> I'm seeing two requirement here: >> >> 1) Timestamp synchronization between metadata and media stream. >> >> This is possible to be achieved by current metadata media stream > start& stop time wherein media packet >> shall be stored or played back with the reference to start time of > media stream block. Say Media >> stream start time as T0 and end time as T1, the first media packet is > received at T0+ t[i] wherein >> t[i] is the time interval between T0 and first media packet. Here > T0+t[i] is always less than T1. >> Playback shall use T0 as the reference value. Here there is no need of > extra time reference required. >> >> 2) Timestamp synchronization between multiple media stream (audio + > video) >> >> New requirement is to synchronize between media stream and there is > need to identify the detailed >> requirement. Infact, I'm still not very much clear which may be due to > my lack of specific details >> about audio+Video recording. >> >> Please correct in case I'm missing something. >> >> Thanks >> Partha >> >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Charles Eckel (eckelcu) >> Sent: Friday, April 15, 2011 4:59 AM >> To: Muthu ArulMozhi Perumal (mperumal); Ram Mohan R (rmohanr); Leon > Portman; Elwell, John; >> ietf@ietf.org >> Cc: siprec@ietf.org >> Subject: Re: [siprec] LastCall:(Use > Cases andRequirements forSIP- >> basedMediaRecording (SIPREC)) toInformational RFC >> >> I was thinking we needed a way to synchronize media from multiple CSs, > which may be received by the >> SRS from one or more SRCs. Is this not a requirement? >> >> Thanks, >> Charles >> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Muthu ArulMozhi Perumal >>> (mperumal) >>> Sent: Thursday, April 14, 2011 1:42 PM >>> To: Ram Mohan R (rmohanr); Leon Portman; Elwell, John; ietf@ietf.org >>> Cc: siprec@ietf.org >>> Subject: Re: [siprec] Last Call:(Use >> Cases andRequirements forSIP-based >>> MediaRecording (SIPREC)) toInformational RFC >>> >>> I agree with John that these seem more like part of a solution > rather >>> than actual requirements. In addition, sending the wallclock time at >>> media start/end alone may not suffice for achieving inter-media >>> synchronization and playback, instead we may need to send the >> wallclock >>> time periodically, like RTCP. For e.g, if there is a codec >> renegotiation >>> in CS the RTP timestamp can restart from a random value. If silence >>> suppression is enabled there would be gaps in the RTP timestamp. >>> >>> These are things that need to be discussed as part of the solution > -- >>> the requirement itself should be generic enough, like what I >> described. >>> REQ-022 and REQ-023 we have doesn't seem to clearly indicate the >>> purpose. >>> >>> Muthu >>> >>> |-----Original Message----- >>> |From: Ram Mohan R (rmohanr) >>> |Sent: Thursday, April 14, 2011 10:13 PM >>> |To: Leon Portman; Elwell, John; Muthu ArulMozhi Perumal (mperumal); >>> ietf@ietf.org >>> |Cc: siprec@ietf.org >>> |Subject: RE: [siprec] Last Call:(Use >>> Cases andRequirements for SIP- >>> |based MediaRecording (SIPREC)) toInformational RFC >>> | >>> |We already have attributes Start-Time / End-time in Media Stream >>> block. This is for the same purpose >>> |to indicate the wall clock time for start/end of media. >>> | >>> |Ram >>> | >>> |> -----Original Message----- >>> |> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>> |> Behalf Of Leon Portman >>> |> Sent: Thursday, April 14, 2011 9:57 PM >>> |> To: Elwell, John; Muthu ArulMozhi Perumal (mperumal); > ietf@ietf.org >>> |> Cc: siprec@ietf.org >>> |> Subject: Re: [siprec] Last Call: > (Use >>> |> Cases andRequirements for SIP-based MediaRecording (SIPREC)) >>> |> toInformational RFC >>> |> >>> |> I am not sure that having wall clock only for CS start is enough, >>> |> especially for partial metadata update. I will prefer to have on >>> media >>> |> level >>> |> >>> |> Leon >>> |> >>> |> -----Original Message----- >>> |> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>> |> Sent: Thursday, April 14, 2011 3:58 PM >>> |> To: Leon Portman; Muthu ArulMozhi Perumal (mperumal); > ietf@ietf.org >>> |> Cc: siprec@ietf.org >>> |> Subject: RE: [siprec] Last Call: >> (Use >>> |> Cases andRequirements for SIP-based Media Recording (SIPREC)) >>> |> toInformational RFC >>> |> >>> |> Understood, but if we have wall clock time for the start of a CS, >>> |> wouldn't that be sufficient? The new requirement would cover >>> |> synchronization of all media start/stops relative to that time. >>> |> >>> |> John (as individual) >>> |> >>> |> >>> |> > -----Original Message----- >>> |> > From: Leon Portman [mailto:Leon.Portman@nice.com] >>> |> > Sent: 14 April 2011 13:19 >>> |> > To: Elwell, John; Muthu ArulMozhi Perumal (mperumal); >> ietf@ietf.org >>> |> > Cc: siprec@ietf.org >>> |> > Subject: RE: [siprec] Last Call: >>> |> > (Use Cases andRequirements for >>> |> > SIP-based Media Recording (SIPREC)) toInformational RFC >>> |> > >>> |> > Actually REQ-022 and REQ-023 describing not only requirement to >>> |> > synchronize between different media streams but more > importantly >>> |> > ability to relate them to real world (wall) clock. It is not > only >>> |> > important to playback them correctly but also to know when it > was >>> |> > said. >>> |> > One example is continue trading after closing hour (even for > one >>> |> > second is not allowed) >>> |> > >>> |> > And if these media are synchronized to wall clock then they are >>> also >>> |> > synchronized between them thus I am not sure if we need this >>> |> > additional requirement. >>> |> > >>> |> > Thanks >>> |> > >>> |> > Leon >>> |> > >>> |> > -----Original Message----- >>> |> > From: siprec-bounces@ietf.org >>> |> > [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John >>> |> > Sent: Thursday, April 14, 2011 1:54 PM >>> |> > To: Muthu ArulMozhi Perumal (mperumal); ietf@ietf.org >>> |> > Cc: siprec@ietf.org >>> |> > Subject: Re: [siprec] Last Call: >>> |> > (Use Cases andRequirements for >>> |> > SIP-based Media Recording (SIPREC)) toInformational RFC >>> |> > >>> |> > >>> |> > >>> |> > >>> |> > > -----Original Message----- >>> |> > > From: siprec-bounces@ietf.org >>> |> > > [mailto:siprec-bounces@ietf.org] On Behalf Of Muthu >>> |> > ArulMozhi Perumal >>> |> > > (mperumal) >>> |> > > Sent: 14 April 2011 07:34 >>> |> > > To: ietf@ietf.org >>> |> > > Cc: siprec@ietf.org >>> |> > > Subject: Re: [siprec] Last Call: >>> |> > > (Use Cases andRequirements for >>> |> > > SIP-based Media Recording (SIPREC)) toInformational RFC >>> |> > > >>> |> > > I've one major comment. It draft discusses synchronization >>> |> > between the >>> |> > > recorded media streams and synchronized playback, which >>> |> > seem important >>> |> > > for certain applications: >>> |> > > >>> |> > > >>> |> > > Some applications require the recording of more than one >>> |> > media stream, >>> |> > > possibly of different types. Media are synchronized, either >>> |> > at storage >>> |> > > or at playback. >>> |> > > >>> |> > > >>> |> > > However, in the requirements section it doesn't seem REQ-022 >> and >>> |> > > REQ-023 are all that are need and sufficient to achieve this >> with >>> |> > > needed precision. So, I would suggest adding another >> requirement >>> as >>> |> > > follows: >>> |> > > The mechanism MUST provide means for facilitating >>> |> > synchronization of >>> |> > > the recorded media streams and metadata either at storage or > at >>> |> > > playback. >>> |> > > This includes, but not limited to, the information needed as >> per >>> |> > > REQ-022 and REQ-023. >>> |> > [JRE] This seems a reasonable addition. I wonder if the new >>> |> > requirement (first sentence only) is sufficient as a >>> |> > **replacement** for REQ-022 and REQ-023. On reading REQ-022 and >>> |> > REQ-023 again, it is not so clear what their purpose was, and >> they >>> |> > seem to be more like a solution than a requirement. >>> |> > One purpose would certainly be that covered by Muthu's new >>> |> > requirement. Was there any other purpose? >>> |> > >>> |> > John >>> |> > >>> |> > > >>> |> > > A nitpick: >>> |> > > Use Case 8 >>> |> > > In cases where calls inside or between branches must be >> recorded, >>> a >>> |> > > centralized recording system in data centers together with >>> |> > telephony >>> |> > > infrastructure (e.g. PBX) me deployed. >>> |> > > >>> |> > > s/me/may be >>> |> > > >>> |> > > Muthu >>> |> > > >>> |> > > |-----Original Message----- >>> |> > > |From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] >>> On >>> |> > > Behalf Of The IESG >>> |> > > |Sent: Wednesday, April 06, 2011 6:20 PM >>> |> > > |To: IETF-Announce >>> |> > > |Cc: siprec@ietf.org >>> |> > > |Subject: [siprec] Last Call: >>> |> > > (Use Cases >>> |> > > andRequirements for SIP-based >>> |> > > |Media Recording (SIPREC)) toInformational RFC >>> |> > > | >>> |> > > | >>> |> > > |The IESG has received a request from the SIP Recording WG >>> |> > (siprec) to >>> |> > > |consider the following document: >>> |> > > |- 'Use Cases and Requirements for SIP-based Media >>> |> > Recording (SIPREC)' >>> |> > > | as an Informational RFC >>> |> > > | >>> |> > > |The IESG plans to make a decision in the next few weeks, >>> |> > and solicits >>> |> > > |final comments on this action. Please send substantive >>> |> > > comments to the >>> |> > > |ietf@ietf.org mailing lists by 2011-04-20. Exceptionally, >>> |> > > comments may >>> |> > > be >>> |> > > |sent to iesg@ietf.org instead. In either case, please retain >> the >>> |> > > |beginning of the Subject line to allow automated sorting. >>> |> > > | >>> |> > > |The file can be obtained via >>> |> > > |http://datatracker.ietf.org/doc/draft-ietf-siprec-req/ >>> |> > > | >>> |> > > |IESG discussion can be tracked via >>> |> > > |http://datatracker.ietf.org/doc/draft-ietf-siprec-req/ >>> |> > > | >>> |> > > | >>> |> > > | >>> |> > > |No IPR declarations have been submitted directly on this > I-D. >>> |> > > |_______________________________________________ >>> |> > > |siprec mailing list >>> |> > > |siprec@ietf.org >>> |> > > |https://www.ietf.org/mailman/listinfo/siprec >>> |> > > _______________________________________________ >>> |> > > siprec mailing list >>> |> > > siprec@ietf.org >>> |> > > https://www.ietf.org/mailman/listinfo/siprec >>> |> > > >>> |> > _______________________________________________ >>> |> > siprec mailing list >>> |> > siprec@ietf.org >>> |> > https://www.ietf.org/mailman/listinfo/siprec >>> |> > >>> |> _______________________________________________ >>> |> siprec mailing list >>> |> siprec@ietf.org >>> |> https://www.ietf.org/mailman/listinfo/siprec >>> _______________________________________________ >>> siprec mailing list >>> siprec@ietf.org >>> https://www.ietf.org/mailman/listinfo/siprec >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From john.elwell@siemens-enterprise.com Fri Apr 15 08:26:57 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A5CD3E08D4 for ; Fri, 15 Apr 2011 08:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.751 X-Spam-Level: X-Spam-Status: No, score=-103.751 tagged_above=-999 required=5 tests=[AWL=0.448, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1dsFvvTZY614 for ; Fri, 15 Apr 2011 08:26:53 -0700 (PDT) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfc.amsl.com (Postfix) with SMTP id 549D8E08CA for ; Fri, 15 Apr 2011 08:26:52 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1302881207!37433002!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 27109 invoked from network); 15 Apr 2011 15:26:47 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-2.tower-27.messagelabs.com with SMTP; 15 Apr 2011 15:26:47 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id E94E423F03E7; Fri, 15 Apr 2011 17:26:50 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 15 Apr 2011 17:26:50 +0200 From: "Elwell, John" To: "Ram Mohan R (rmohanr)" , "Parthasarathi R (partr)" , "siprec@ietf.org" Date: Fri, 15 Apr 2011 17:26:49 +0200 Thread-Topic: [siprec] FW: Do we need to model participants not part ofCS butassociated with Media Stream block in the metadatamodel ? (was RE: Partial updates and identifiers) Thread-Index: Acv0jVXI4ji2YTo+SquJ6T6YR3i+lQAdOkDgAEETmvAAg54qsAADKDEgAADSn+AAEAO1UAANZylQABBzW2AABHtBwACZNyqAAAGC+nAAAd/QMAAHC/qgAADkBPA= Message-ID: References: <35BCE99A477D6A4986FB2216D8CF2CFD061331FF@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD061332DC@XMB-BGL-417.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD061332DC@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] FW: Do we need to model participants not part ofCS butassociated with Media Stream block in the metadatamodel ? (was RE: Partial updates and identifiers) X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 15 Apr 2011 15:26:57 -0000 > -----Original Message----- > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > Sent: 15 April 2011 16:04 > To: Parthasarathi R (partr); Elwell, John; siprec@ietf.org > Subject: RE: [siprec] FW: Do we need to model participants > not part ofCS butassociated with Media Stream block in the > metadatamodel ? (was RE: Partial updates and identifiers) > > I am ok with associating participants behind a UA [ for case > where UA is > capable of learning them] in CS as part of that CS in the > model/format. > One question I have is, Do we need to distinguish these participants > from the others by having some attributes as part of > participant block? > Or is it sufficient if we just treat them as any other participants of > CS. [JRE] We could treat them as other Participants, but if we don't have infor= mation about the media they are sending receiving and therefore all media i= s seen by the SRC as being sent/received by the conference UA, then I don't= really see it makes sense to treat them as separate Participant objects. > > There are three categories of participants: > Participants who contribute both signaling and media to CS > Participants who contribute only media in the CS [ like the > below case] > Participants who contribute only signaling to CS [e.g. 3pcc > controller] [JRE] I don't think this distinction is particularly relevant to what gets = sent to the SRS, stored, and subsequently played back. The information that= really needs to be captured is which participants send/receive which media= , and signalling. Signalling is just part of the CS mechanism that has no r= elevance to what gets recorded and played back. I don't see why a 3PCC cont= roller would be considered a Participant. John (as individual) > > Ram > > > -----Original Message----- > > From: Parthasarathi R (partr) > > Sent: Friday, April 15, 2011 5:28 PM > > To: Elwell, John; Ram Mohan R (rmohanr); siprec@ietf.org > > Subject: RE: [siprec] FW: Do we need to model participants not part > > ofCS butassociated with Media Stream block in the > metadatamodel ? (was > > RE: Partial updates and identifiers) > > > > John point of view looks reasonable to me because CS is not directly > > associated with dialogs but instead it represents session with the > list > > of participant involved in it. > > > > In case of participant list received through conference > package to SRC > > with UA, those multiple participants from focus shall be represented > as > > individual participant block who are pointed to single mixed media > > stream metadata block and all participant belongs within single > > conference CS in this scenario. The model is as follows > (part in the > > diagram represents participant): > > > > > > RS > > | > > CS------------------------------- > > | | > > ----------------------- part5(SRC) > > | | | | | > > | | | | media stream2 > > part1 part2 part3 part4 > > | | | | > > ------------------------- > > | > > Media stream1 > > > > Thanks > > Partha > > > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Elwell, John > > Sent: Friday, April 15, 2011 4:34 PM > > To: Ram Mohan R (rmohanr); siprec@ietf.org > > Subject: Re: [siprec] FW: Do we need to model participants not part > > ofCS butassociated with Media Stream block in the > metadatamodel ? (was > > RE: Partial updates and identifiers) > > > > As an individual, my opinion, which I have pretty much > stated before, > > is that a participant must always be part of a CS. A couple of > > situations have been mentioned where alternatives might be required, > > but I don't believe so. > > > > 1. Conferences. I think depending what view the SRC has of the CS, > > there are two situations: > > > > (a) The SRC sees all parties in the conference and has visibility of > > what Media Streams each party sends and receives. In this case, I > think > > the whole conference can be modelled as a CS and each party can be > > modelled as a Participant in that CS. Such a view will typically be > > feasible when the SRC is located at a conference > focus/mixer (e.g., an > > MCU). > > > > (b) The SRC sees the conference focus mixer as a party but > has limited > > information about parties behind the focus/mixer. In this > case I think > > the SRC can regard the CS as terminating at the conference > > (focus/mixer), with the conference a Participant in that CS. > > Information about parties behind the conference may or may not be > > available, in which case they can be additional attributes of the > > conference Participant object. One typical case will be > where the SRC > > is located at a UA of one of the conference parties, or at a B2BUA > > between the focus/mixer and a party UA. In that case the CS > would have > > two Participants: the party concerned and the conference. Am extreme > > case is where the conference is the sole Participant and > just records > > Media Streams sent by the conference to parties in the conference. > > > > Hybrid situations can occur, e.g., for cascaded conferences, where > > participants at one conference are modelled as Participants > but other > > conferences are just modelled each as a single Participant. > > > > 2. IVR and similar. I would model the Media Server as a > Participant in > > the CS, i.e., there is a CS between the Media Server and the caller. > > > > John > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Ram Mohan R > (rmohanr) > > > Sent: 15 April 2011 10:56 > > > To: siprec@ietf.org > > > Subject: [siprec] FW: Do we need to model participants not part of > CS > > > butassociated with Media Stream block in the metadata model ? (was > > RE: > > > Partial updates and identifiers) > > > > > > I request people to provide inputs on this and help to > take it to a > > > closure. This issue has been open for several months now. > > > > > > Ram > > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Ram Mohan R > (rmohanr) > > > Sent: Tuesday, April 12, 2011 3:04 PM > > > To: Elwell, John; Charles Eckel (eckelcu); Parthasarathi > R (partr); > > > Paul Kyzivat (pkyzivat); siprec@ietf.org > > > Cc: Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr) > > > Subject: [siprec] Do we need to model participants not part of CS > but > > > associated with Media Stream block in the metadata model > ? (was RE: > > > Partial updates and identifiers) > > > > > > Renaming the mail thread to discussion to this specific issue - > > > "Metadata for participants not part of CS" which we have been > > > discussing from several weeks. > > > > > > Please continue the other issues in original thread and lets use > this > > > thread to close this issue. I would request people to give inputs > for > > > this issue on this thread and take it to a conclusion. > > > > > > We(Authors of Metadata model) included participants that are not > part > > > of CS to imply: > > > - Participants that does NOT contribute to signaling in CS but > > > contributes to media The intent is to give more flexibility in the > > > metamodel to represent these types of participants. > > > > > > Following are some of use case where this can happen- > > > > > > Use-Case 1: A conference where one of the participants is > a SRC. In > > > these case the Focus which talks to this SRC becomes part of CS > > > contributing signaling as well as media. However the > media includes > > > media from other participants that are not part of CS. Please note > > SRC > > > has to subscribe to conf event packet to get this > information (which > > > may not be always feasible). > > > > > > Use-Case 2: one UA in CS works in 3pcc mode to acquire an > MoH media > > > stream, this might be reflected as unique source for media stream > > > without having a reported signaling relationship to it. E.g is > > given > > > here by Henry Lum > > > http://www.ietf.org/mail-archive/web/siprec/current/msg01372.html > > > > > > In some sense these participants are *still* part of CS as they > > > contribute to CS media. > > > > > > There are three approaches I can see- > > > Don't model the participants that does not contribute signaling in > CS > > > and only contribute Media Model these participants as not > part of CS > > > in the model but associated with Media Stream block ( current > > > approach) Model these participants to be associated with > CS but have > > > the association labeled as "indirect participant" > > > > > > Let me know your thoughts. > > > > > > Thanks, > > > Ram > > > > > > > -----Original Message----- > > > > From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On > > > > Behalf Of Elwell, John > > > > Sent: Tuesday, April 12, 2011 12:13 PM > > > > To: Charles Eckel (eckelcu); Parthasarathi R (partr); > Paul Kyzivat > > > > (pkyzivat); siprec@ietf.org > > > > Cc: Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr) > > > > Subject: Re: [siprec] Partial updates and identifiers > > > > > > > > I think the attached message was the last in that thread. So I > > don't > > > > really think we had closure. > > > > > > > > John > > > > > > > > > -----Original Message----- > > > > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > > > Sent: 11 April 2011 23:53 > > > > > To: Elwell, John; Parthasarathi R (partr); Paul Kyzivat > > > (pkyzivat); > > > > > siprec@ietf.org > > > > > Cc: Peter Saint-Andre (psaintan); Joe Hildebrand > > > (jhildebr); Hadriel > > > > > Kaplan > > > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > > > > > Hi John, > > > > > > > > > > I have attached the last e-mail I have from the > thread in which > I > > > > > first raised this issue. Unfortunately, I do not have > the e-mail > > > with > > > > > the ultimate agreement, but maybe someone else does > or this will > > > help > > > > > prompt some memories. > > > > > > > > > > Cheers, > > > > > Charles > > > > > > > > > > > -----Original Message----- > > > > > > From: siprec-bounces@ietf.org > > > [mailto:siprec-bounces@ietf.org] On > > > > > Behalf Of Elwell, John > > > > > > Sent: Monday, April 11, 2011 9:46 AM > > > > > > To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); > > > > > siprec@ietf.org > > > > > > Cc: Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr); > > > > Hadriel > > > > > Kaplan > > > > > > Subject: Re: [siprec] Partial updates and identifiers > > > > > > > > > > > > Partha, > > > > > > > > > > > > Thanks for reminding me - I now recall the discussion some > > > > > weeks/months ago about the participants > > > > > > obtained from the conference event package. I was never > > > > particularly > > > > > comfortable with the fact these > > > > > > were not considered part of the CS. While that might be > > > > > correct if we > > > > > consider the CS to be the SIP > > > > > > dialog between the SRC and the conference focus, taking a > > > > > broader view > > > > > of CS those participants behind > > > > > > the focus could be considered part of the CS. I don't > > > particularly > > > > > want to open up the old discussion > > > > > > if people are happy with what we have, but something > > > doesn't seem > > > > > quite right to me. > > > > > > > > > > > > For example, if these "participants" are not considered part > of > > > the > > > > > CS, and if we don't have specific > > > > > > information about their involvement in media > streams, do they > > > > really > > > > > merit being considered > > > > > > Participant objects? > > > > > > > > > > > > In other words, two possible approaches are: > > > > > > > > > > > > 1) The CS extends only as far as the focus / mixer. The > > > > > focus/mixer is > > > > > a "Participant" and the users > > > > > > behind the focus are not separate Participants but are just > > > > > additional > > > > > data associated with the > > > > > > focus/mixer Participant. The only Media Streams we are > > > > > concerned with > > > > > are between the mixer and the > > > > > > SRC. > > > > > > > > > > > > 2) The CS extends beyond the focus/mixer to users > > > learned via the > > > > > conference event package, each of > > > > > > those users is a separate Participant object, and we > > > are concerned > > > > > with Media Stream objects that > > > > > > those participants send and receive. I am not sure how > feasible > > > > this > > > > > approach is, because I am not > > > > > > sure that the SRC can obtain enough information about media > > > > > streams at > > > > > users behind the focus/mixer. > > > > > > > > > > > > It seems the present solution is somewhere between the > > > two, which > > > > is > > > > > why I am uncomfortable. > > > > > > > > > > > > Regards, > > > > > > > > > > > > John (as individual) > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > > > > Sent: 11 April 2011 10:29 > > > > > > > To: Elwell, John; Paul Kyzivat (pkyzivat); siprec@ietf.org > > > > > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe > > > Hildebrand > > > > > > > (jhildebr) > > > > > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > > > > > > > > > John, > > > > > > > > > > > > > > Please read inline. > > > > > > > > > > > > > > Thanks > > > > > > > Partha > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Elwell, John [mailto:john.elwell@siemens- > > enterprise.com] > > > > > > > Sent: Monday, April 11, 2011 2:11 PM > > > > > > > To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); > > > > > siprec@ietf.org > > > > > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe > > > Hildebrand > > > > > > > (jhildebr) > > > > > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > > > > > Sent: 11 April 2011 08:35 > > > > > > > > To: Elwell, John; Paul Kyzivat (pkyzivat); > siprec@ietf.org > > > > > > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe > > > > Hildebrand > > > > > > > > (jhildebr) > > > > > > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > > > > > > > > > > > John, > > > > > > > > > > > > > > > > As I mentioned below, stream block will be unique > > > > > within CS, (not > > > > > > > > required to be unique across multiple CS) and so, xml:id > or > > > > > > > enhancing > > > > > > > > the normative statement of RFC 4574 label > attribute to be > > > > unique > > > > > > > > within CS will serve the purpose. I'm fine with > any of the > > > > above > > > > > > > > mentioned id. > > > > > > > > Please note that RFC 4574 "label" attribute is > the nature > > > > > > > data for RS > > > > > > > > dialog. > > > > > > > > > > > > > > > > In case participant within CS, xml:id will serve the > > purpose > > > > but > > > > > we > > > > > > > > need to get more clarity about participants who are not > > > > > > > part of CS but > > > > > > > > > > > > > > > within RS. > > > > > > > [JRE] If I understand the figure in section 3 of > metadata-04 > > > > > > > correctly, a Participant can have a relationship with > > > a CS, but > > > > no > > > > > > > direct relationship with an RS. > > > > > > > > > > > > > > Sorry, I mixed up my statement with the latest > > update > > > of > > > > > > > making CSG optional. As per Sec 3 of metadata-04, > participant > > > has > > > > > > > direct relationship with CSG in case CS is left completely > > > > > > > unattached. In case CSG is optional, then participant > > > will have > > > > > > > direct relationship with RS in case there is no > relationship > > > > > > > between CS and participant. > > > > > > > > > > > > > > > > > > > > > So a participant that does not have a relationship > > > with a CS is > > > > > left > > > > > > > completely unattached, unless it has a relationship > > > with a Media > > > > > > > Stream (which always has a relationship with a CS). So to > > > > > > > summarize: > > > > > > > - a Participant can have a direct relationship > with a CS; or > > > > > > > - a Participant can have an indirect relationship > > > with a CS (via > > > > a > > > > > > > Media Stream); agreed > > > > > > > - a Participant can have no relationship with a CS, and > > > > > therefore no > > > > > > > relationship with an RS. > > > > > > > Do we really need this last case? > > > > > > > > > > > > > > I'm happy if the last case is not > required because > > it > > > > > > > simplify the solution and there is no need of > unique id for > > > > > > > participant. But SRS implementers may prefer to have > > > relationship > > > > > > > with participant and RS. I wish more opinion before taking > > > > > > > decision whether to remove the last case > > > > > > > > > > > > > > > Because CS may span across different RS how about the > > > > > > > participant who > > > > > > > > are not part of CS? > > > > > > > [JRE] I don't understand the words "Because CS may span > > across > > > > > > > different RS", because in the rest of the sentence you are > > > > talking > > > > > > > about a Participant that is not part of a CS. > > > > > > > > > > > > > > > Ex: One of the user in the conference acts as SRC, fetch > > > > > > > participant > > > > > > > > info using conferene package and new RS is created > > > > > during initial > > > > > > > > conference creation and hold&resume of a user within CS. > > > > > > > [JRE] I am not sure what you are trying to say > here. I would > > > > > > > consider a user whose identity is obtained via a > conference > > > event > > > > > > > package as being part of the CS. > > > > > > > > > > > > > > I'm trying to give the example where > > > participant is not > > > > > > > associated with CS directly but related to CSG (/RS). This > > > > > > > scenario was considered as a blocking in -03 version of > > > metadata. > > > > > > > I'm not arguing to have this scenario but it is major > concern > > > for > > > > > > > few folks. > > > > > > > > > > > > > > CS is between focus and UA, UA acts as SRC, UA > receives the > > > > > > > participant info via conference event package but those > > > > > > > participants are not related in CS directly (and > only focus > > is > > > > > > > related) but they contributed for the mixed stream. > > > > > > > > > > > > > > > That user is sending/receiving Media Streams that > > > are part of a > > > > > > > CS, or if it isn't sending/receiving Media Streams, > > > what is the > > > > > > > relevance > > > > > of > > > > > > > that Participant? > > > > > > > > > > > > > > Mixed media stream from focus to UA > belongs to the > > > > > Conference > > > > > > > event package participants. There participant are not > > directly > > > > > > > involved as part of CS. Why would we > > > create a new RS > > > > > > > for such a participant? > > > > > > > RS is not created for participant. Multiple > > > RS shall be > > > > > > > created the same CS during the different time > frame as shown > > > > below > > > > > > > > > > > > > > <-------------------CS1-------------> > > > > > > > <---RS1--> <---RS2------> > > > > > > > > > > > > > > CS1 is between UA (SRC) and focus whereas RS1, RS2 is > > > between UA > > > > > (SRC) > > > > > > > and SRS. Here tangling (conference event package) > participant > > > has > > > > > > > to be grouped together in RS1, RS2 by some means through > > given > > > > > > > metadata. > > > > > The > > > > > > > question whether this corner has to be solved ? > > > > > > > > > > > > > > John (as individual) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > Partha > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Elwell, John > > > [mailto:john.elwell@siemens-enterprise.com] > > > > > > > > Sent: Friday, April 08, 2011 9:36 PM > > > > > > > > To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); > > > > > > > siprec@ietf.org > > > > > > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe > > > > Hildebrand > > > > > > > > (jhildebr) > > > > > > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > > > > > > > > > > > Focusing just on participant and stream for the time > being, > > > > > > > do these > > > > > > > > need to be unique across multiple CSs or not? > > > > > > > > > > > > > > > > John > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > > > > > > Sent: 07 April 2011 10:51 > > > > > > > > > To: Paul Kyzivat (pkyzivat); siprec@ietf.org; Elwell, > > John > > > > > > > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe > > > > > Hildebrand > > > > > > > > > (jhildebr) > > > > > > > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > > > > > > > > > > > > > John, > > > > > > > > > > > > > > > > > > Sorry for the lengthy mail but it contains lot of > > analysis > > > > and > > > > > > > > > reasoning for this id approach. > > > > > > > > > > > > > > > > > > Adding to Paul's point, I wish to give more background > > and > > > > > > > > reason for > > > > > > > > > these globally unique id. Initially I had the > impression > > > that > > > > > the > > > > > > > > > single unique id (RS dialog-id) in the recording > (session > > > > > > > > level) and > > > > > > > > > some relevant natural id for the rest of the element > will > > > > > > > serve the > > > > > > > > > purpose. > > > > > > > > > There are usecases where this assumption fails. > > > Even I have > > > > > > > > thought of > > > > > > > > > > > > > > > > > using "xml:id" instead of URN UUID to avoid long > > > string but > > > > > > > > xml:id may > > > > > > > > > > > > > > > > > not end up with unique value always. Our analysis for > URN > > > > > > > UUID for > > > > > > > > > each level is as follows and please provide your input > in > > > > case > > > > > id > > > > > > > > > shall be > > > > > > > > > tweaked: > > > > > > > > > > > > > > > > > > 1) Recording block: The reason for globally > unique id is > > > > > > > > that multiple > > > > > > > > > > > > > > > > > SRC with same id to single SRS. > > > > > > > > > > > > > > > > > > Topology: > > > > > > > > > > > > > > > > > > SRC1 SRC2 > > > > > > > > > | | > > > > > > > > > | ----(RS1-ID1)-----SRS1 > > > > > > > > > | > > > > > > > > > ---(RS2-ID1)------------------SRS1 > > > > > > > > > > > > > > > > > > In the above topology, it is possible for ID1 is > > generated > > > by > > > > > both > > > > > > > > > SRC1 and SRC2 at the same time. > > > > > > > > > > > > > > > > > > 2) group (CSG) block: Grouping mechanism (Hadriel > > > > > > > session-id, Paul > > > > > > > > > Jones > > > > > > > > > Session-UUID) is outside the scope of SIPREC. URN UUID > > > > > > > > abstracts the > > > > > > > > > exact mechanism to SRS and provides the > information only > > > > > > > about the > > > > > > > > > group of CS from SRC perspective. It possible > > > that group may > > > > > span > > > > > > > > > across multiple RS and It is up to SRS to > group and view > > > > > > > as single > > > > > > > > > recording. > > > > > > > > > Here, the single level id in the top will fail. > > > The counter > > > > > > > > argument > > > > > > > > > is to force the single RS having complete CSG but > > > > > it*may not* be > > > > > > > > > possible in SRC implementation. Here, xml:id will not > > > > > serve the > > > > > > > > > purpose > > > > > > > > > > > > > > > > > > 3) session (CS) block: At the immediate look, session > > > > > > > falls exactly > > > > > > > > > under recording block. Use case 3 of > > > draft-ietf-siprec-req-09 > > > > > > > > > illustrates where CS span across multiple RS. This > > > > > > > > requirement calls > > > > > > > > > for unique id in session by which these > session shall be > > > > > > > viewed as > > > > > > > > > single CS even though there is no group exists among > > > > > > > them. IMO, in > > > > > > > > > case session should not have globally unique id, > > > then it is > > > > > > > > preferred > > > > > > > > > to remove usecase 3 in the requirement. > > > > > > > > > > > > > > > > > > 4) participant block: It needs some id which may > > > be AOR but > > > > > > > > AOR is not > > > > > > > > > > > > > > > > > unique. IMO, xml:id may serve the purpose with session > > > > > > > > unique id. The > > > > > > > > > trick exists for participant who are not > associated with > > > > > > > > CS. We shall > > > > > > > > > discuss and fine tune if required. > > > > > > > > > > > > > > > > > > 5) stream block: Label attribute shall be > used as unique > > > > > > > > value but RFC > > > > > > > > > 4574 does not mandate label attribute has to be unique > > > across > > > > > the > > > > > > > > > dialog or CS and so, it may possible to change within > > > > > RS and no > > > > > > > > > normative statement to stop this implementation. IMO, > > > > > > > > xml:id may serve > > > > > > > > > > > > > > > > > the purpose with session unique id. Here as well, We > > shall > > > > > > > > discuss and > > > > > > > > > > > > > > > > > fine tune if required. > > > > > > > > > > > > > > > > > > 6) extensiondata block: This is tracked in > the separate > > > > > > > mail thread > > > > > > > > > whether unique id is required or not. Let us > close this > > > > > > > as part of > > > > > > > > > that mail thread. > > > > > > > > > > > > > > > > > > Including explicitly Hadriel, Peter, Joe in this mail > > > > > > > > thread as they > > > > > > > > > have different view on this ID mechanism. > > > > > > > > > > > > > > > > > > I had offline discussion with Hadriel in Prague after > > > > > > > > SIPREC meeting > > > > > > > > > and my understanding of his major concern is that how > SRS > > > > > > > > will be able > > > > > > > > > > > > > > > > > to design the database in case partial update > > > does not have > > > > > > > > recording > > > > > > > > > (top) id information. I'll put more thought > > > > > processing to close > > > > > > > > > Hadriel concern of how top id has to be > tracked in case > > > > > > > > partial update > > > > > > > > > > > > > > > > > by which SRS implementation will be > simplified in terms > > of > > > > > > > > aggregation > > > > > > > > > > > > > > > > > maintenance. > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > Partha > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: siprec-bounces@ietf.org > > > > > > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul > > Kyzivat > > > > > > > > (pkyzivat) > > > > > > > > > Sent: Thursday, April 07, 2011 12:33 AM > > > > > > > > > To: siprec@ietf.org > > > > > > > > > Subject: Re: [siprec] Partial updates and identifiers > > > > > > > > > > > > > > > > > > John, > > > > > > > > > > > > > > > > > > For the moment we have proposed that the ids be > > > conveyed in > > > > > > > > the form > > > > > > > > > of URIs that are globally unique, and > specifically that > > > > > > > > they be UUID > > > > > > > > > URNs. > > > > > > > > > There is no dependency on the particular form of the > URI, > > > but > > > > > > > > > specifying they must be UUID URNs makes it possible to > > > > > > > perform some > > > > > > > > > internal optimizations for storage. > > > > > > > > > > > > > > > > > > The UUID URN is a pretty inefficient encoding. A UUID > can > > > > > > > > be expressed > > > > > > > > > > > > > > > > > in 32 bits, so we could consider retaining UUIDs but > > alter > > > > the > > > > > > > > > encoding if its really an issue. However I am far from > > > > > > > > convinced that > > > > > > > > > the size of the IDs is going to be a major > issue in the > > > > > > > > overall size > > > > > > > > > of messages, so I think its probably > premature to worry > > > about > > > > > it. > > > > > > > > > > > > > > > > > > Because the ids can be expressed in 32 bits, > the SRC and > > > > > > > > SRS can store > > > > > > > > > > > > > > > > > them internally that way, thus reducing the > > > runtime cost of > > > > > > > > > maintaining the data. > > > > > > > > > > > > > > > > > > The use of unique ids is a significant part of the > > overall > > > > > > > > approach to > > > > > > > > > > > > > > > > > formatting updates. If somebody has a > different concept > > > > > > > in mind it > > > > > > > > > could be useful to have an alternative > proposal for the > > > > > > > > format. If we > > > > > > > > > had two worked out approaches we could compare the > > > > > > > > tradeoffs in each. > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > Paul > > > > > > > > > > > > > > > > > > On 4/6/2011 10:24 AM, Elwell, John wrote: > > > > > > > > > > Much of the discussion on draft-ram-metadata-format > > > > > in Prague > > > > > > > > > concerned the mechanism for performing partial updates > > and > > > > > > > > the use of > > > > > > > > > identifiers. The draft permits partial updates by > > allowing > > > > > > > > individual > > > > > > > > > objects (e.g., CS, participant, media stream) > to be sent > > > > > > > > with updated > > > > > > > > > content, without having to send again other > objects that > > > have > > > > > not > > > > > > > > > changed. So, for example, in a large conference, it > would > > > > > > > > be possible > > > > > > > > > to add or modify an individual participant object > without > > > > > > > having to > > > > > > > > > send all the other participant objects again. I do not > > > recall > > > > > any > > > > > > > > > opposition to this basic principle. > > > > > > > > > > > > > > > > > > > > However, to achieve this, every object requires an > > > > > > > > > identifier, and it > > > > > > > > > was asserted that these identifiers need to > be globally > > > > > > > > unique for all > > > > > > > > > > > > > > > > > time. Although this might be efficient for updating an > > > > > individual > > > > > > > > > object, when sending many objects (e.g., at > the start of > > a > > > > > > > > CS or when > > > > > > > > > refreshing the entire metadata), this can make the > > > > > metadata very > > > > > > > > > bulky. > > > > > > > > > It depends, of course, on the format of the > identifiers, > > > > > > > and it was > > > > > > > > > stated that there could be alternatives to UUID. > > > > > > > Nevertheless, some > > > > > > > > > people had concerns. These concerns also > extended to the > > > > > > > > impact on the > > > > > > > > > > > > > > > > > database where metadata is stored, since it > might not be > > > > > > > > feasible to > > > > > > > > > convert to a database-friendly mechanism for linking > > > > > > > > objects together. > > > > > > > > > > > > > > > > > > > > One alternative proposal during the meeting was > > > to have a > > > > > single > > > > > > > > > unique identifier at the top level (for the > RS) and use > > > local > > > > > > > > > identifiers for other objects. Thus when updating a > > single > > > > > > > > object, it > > > > > > > > > would be necessary to include the top level identifier > as > > > > > > > > well as one > > > > > > > > > or more local identifiers. However, there were > > > also concerns > > > > > this > > > > > > > > > might not fulfil actual or perceived future > requirements. > > > > > > > > > > > > > > > > > > > > Please continue discussion on this. > > > > > > > > > > > > > > > > > > > > John (as chair) > > > > > > > > > > _______________________________________________ > > > > > > > > > > siprec mailing list > > > > > > > > > > siprec@ietf.org > > > > > > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > siprec mailing list > > > > > > > > > siprec@ietf.org > > > > > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > siprec mailing 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@cisco.com Fri Apr 15 08:48:05 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7FD1CE08F3 for ; Fri, 15 Apr 2011 08:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.287 X-Spam-Level: X-Spam-Status: No, score=-109.287 tagged_above=-999 required=5 tests=[AWL=-1.088, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 734uapAzan6H for ; Fri, 15 Apr 2011 08:48:00 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by ietfc.amsl.com (Postfix) with ESMTP id DC908E0754 for ; Fri, 15 Apr 2011 08:47:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=31935; q=dns/txt; s=iport; t=1302882479; x=1304092079; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=mf+v/EK9ZZc4iH8sA4zOor2bdvghaG+Df/iKycJYiAI=; b=bWLQ1Gi6VSFxBiJLjIay4CM4KiECYplGgJj1Yh3W+LRVpLlNxeoYX5Jt Xza+cVna5JxORCQaWS9We26Amu833ZquhP0xOpkfQj7BEGp4rdNMymyZO pgPRyJ9/ifK9NXt5RnE4EWByo8Ud3iPevp1OUzGPIETFabwpWFZwdp0Xf o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmwBABZoqE2tJXHB/2dsb2JhbACYBY1/d6c0nH6Cf4JvBI14g3Q X-IronPort-AV: E=Sophos;i="4.64,219,1301875200"; d="scan'208";a="354147002" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by sj-iport-5.cisco.com with ESMTP; 15 Apr 2011 15:47:57 +0000 Received: from [161.44.182.250] (dhcp-161-44-182-250.cisco.com [161.44.182.250]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p3FFlvaU018204 for ; Fri, 15 Apr 2011 15:47:57 GMT Message-ID: <4DA868AC.6070204@cisco.com> Date: Fri, 15 Apr 2011 11:47:56 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: siprec@ietf.org References: <35BCE99A477D6A4986FB2216D8CF2CFD061331FF@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD061332DC@XMB-BGL-417.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] FW: Do we need to model participants not part ofCS butassociated with Media Stream block in the metadatamodel ? (was RE: Partial updates and identifiers) X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 15 Apr 2011 15:48:05 -0000 My original thinking on this was that you can have a situation where you know you have a CS involving sip:foo.com, and you know (somehow) that the media coming from foo.com includes contributions from Bob and Carol and Ted and Alice. You might not even have signaling URIs for them, and you may not be able to distinguish which media is from which person, but it still seems like it would be good to have a way to represent what *is* known. But I'm ok with what what is now being discussed if that seems to meet people's needs. Thanks, Paul On 4/15/2011 11:26 AM, Elwell, John wrote: > > >> -----Original Message----- >> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] >> Sent: 15 April 2011 16:04 >> To: Parthasarathi R (partr); Elwell, John; siprec@ietf.org >> Subject: RE: [siprec] FW: Do we need to model participants >> not part ofCS butassociated with Media Stream block in the >> metadatamodel ? (was RE: Partial updates and identifiers) >> >> I am ok with associating participants behind a UA [ for case >> where UA is >> capable of learning them] in CS as part of that CS in the >> model/format. >> One question I have is, Do we need to distinguish these participants >> from the others by having some attributes as part of >> participant block? >> Or is it sufficient if we just treat them as any other participants of >> CS. > [JRE] We could treat them as other Participants, but if we don't have information about the media they are sending receiving and therefore all media is seen by the SRC as being sent/received by the conference UA, then I don't really see it makes sense to treat them as separate Participant objects. > >> >> There are three categories of participants: >> Participants who contribute both signaling and media to CS >> Participants who contribute only media in the CS [ like the >> below case] >> Participants who contribute only signaling to CS [e.g. 3pcc >> controller] > [JRE] I don't think this distinction is particularly relevant to what gets sent to the SRS, stored, and subsequently played back. The information that really needs to be captured is which participants send/receive which media, and signalling. Signalling is just part of the CS mechanism that has no relevance to what gets recorded and played back. I don't see why a 3PCC controller would be considered a Participant. > > John (as individual) > >> >> Ram >> >>> -----Original Message----- >>> From: Parthasarathi R (partr) >>> Sent: Friday, April 15, 2011 5:28 PM >>> To: Elwell, John; Ram Mohan R (rmohanr); siprec@ietf.org >>> Subject: RE: [siprec] FW: Do we need to model participants not part >>> ofCS butassociated with Media Stream block in the >> metadatamodel ? (was >>> RE: Partial updates and identifiers) >>> >>> John point of view looks reasonable to me because CS is not directly >>> associated with dialogs but instead it represents session with the >> list >>> of participant involved in it. >>> >>> In case of participant list received through conference >> package to SRC >>> with UA, those multiple participants from focus shall be represented >> as >>> individual participant block who are pointed to single mixed media >>> stream metadata block and all participant belongs within single >>> conference CS in this scenario. The model is as follows >> (part in the >>> diagram represents participant): >>> >>> >>> RS >>> | >>> CS------------------------------- >>> | | >>> ----------------------- part5(SRC) >>> | | | | | >>> | | | | media stream2 >>> part1 part2 part3 part4 >>> | | | | >>> ------------------------- >>> | >>> Media stream1 >>> >>> Thanks >>> Partha >>> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>> Behalf Of Elwell, John >>> Sent: Friday, April 15, 2011 4:34 PM >>> To: Ram Mohan R (rmohanr); siprec@ietf.org >>> Subject: Re: [siprec] FW: Do we need to model participants not part >>> ofCS butassociated with Media Stream block in the >> metadatamodel ? (was >>> RE: Partial updates and identifiers) >>> >>> As an individual, my opinion, which I have pretty much >> stated before, >>> is that a participant must always be part of a CS. A couple of >>> situations have been mentioned where alternatives might be required, >>> but I don't believe so. >>> >>> 1. Conferences. I think depending what view the SRC has of the CS, >>> there are two situations: >>> >>> (a) The SRC sees all parties in the conference and has visibility of >>> what Media Streams each party sends and receives. In this case, I >> think >>> the whole conference can be modelled as a CS and each party can be >>> modelled as a Participant in that CS. Such a view will typically be >>> feasible when the SRC is located at a conference >> focus/mixer (e.g., an >>> MCU). >>> >>> (b) The SRC sees the conference focus mixer as a party but >> has limited >>> information about parties behind the focus/mixer. In this >> case I think >>> the SRC can regard the CS as terminating at the conference >>> (focus/mixer), with the conference a Participant in that CS. >>> Information about parties behind the conference may or may not be >>> available, in which case they can be additional attributes of the >>> conference Participant object. One typical case will be >> where the SRC >>> is located at a UA of one of the conference parties, or at a B2BUA >>> between the focus/mixer and a party UA. In that case the CS >> would have >>> two Participants: the party concerned and the conference. Am extreme >>> case is where the conference is the sole Participant and >> just records >>> Media Streams sent by the conference to parties in the conference. >>> >>> Hybrid situations can occur, e.g., for cascaded conferences, where >>> participants at one conference are modelled as Participants >> but other >>> conferences are just modelled each as a single Participant. >>> >>> 2. IVR and similar. I would model the Media Server as a >> Participant in >>> the CS, i.e., there is a CS between the Media Server and the caller. >>> >>> John >>> >>>> -----Original Message----- >>>> From: siprec-bounces@ietf.org >>>> [mailto:siprec-bounces@ietf.org] On Behalf Of Ram Mohan R >> (rmohanr) >>>> Sent: 15 April 2011 10:56 >>>> To: siprec@ietf.org >>>> Subject: [siprec] FW: Do we need to model participants not part of >> CS >>>> butassociated with Media Stream block in the metadata model ? (was >>> RE: >>>> Partial updates and identifiers) >>>> >>>> I request people to provide inputs on this and help to >> take it to a >>>> closure. This issue has been open for several months now. >>>> >>>> Ram >>>> >>>> -----Original Message----- >>>> From: siprec-bounces@ietf.org >>>> [mailto:siprec-bounces@ietf.org] On Behalf Of Ram Mohan R >> (rmohanr) >>>> Sent: Tuesday, April 12, 2011 3:04 PM >>>> To: Elwell, John; Charles Eckel (eckelcu); Parthasarathi >> R (partr); >>>> Paul Kyzivat (pkyzivat); siprec@ietf.org >>>> Cc: Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr) >>>> Subject: [siprec] Do we need to model participants not part of CS >> but >>>> associated with Media Stream block in the metadata model >> ? (was RE: >>>> Partial updates and identifiers) >>>> >>>> Renaming the mail thread to discussion to this specific issue - >>>> "Metadata for participants not part of CS" which we have been >>>> discussing from several weeks. >>>> >>>> Please continue the other issues in original thread and lets use >> this >>>> thread to close this issue. I would request people to give inputs >> for >>>> this issue on this thread and take it to a conclusion. >>>> >>>> We(Authors of Metadata model) included participants that are not >> part >>>> of CS to imply: >>>> - Participants that does NOT contribute to signaling in CS but >>>> contributes to media The intent is to give more flexibility in the >>>> metamodel to represent these types of participants. >>>> >>>> Following are some of use case where this can happen- >>>> >>>> Use-Case 1: A conference where one of the participants is >> a SRC. In >>>> these case the Focus which talks to this SRC becomes part of CS >>>> contributing signaling as well as media. However the >> media includes >>>> media from other participants that are not part of CS. Please note >>> SRC >>>> has to subscribe to conf event packet to get this >> information (which >>>> may not be always feasible). >>>> >>>> Use-Case 2: one UA in CS works in 3pcc mode to acquire an >> MoH media >>>> stream, this might be reflected as unique source for media stream >>>> without having a reported signaling relationship to it. E.g is >>> given >>>> here by Henry Lum >>>> http://www.ietf.org/mail-archive/web/siprec/current/msg01372.html >>>> >>>> In some sense these participants are *still* part of CS as they >>>> contribute to CS media. >>>> >>>> There are three approaches I can see- >>>> Don't model the participants that does not contribute signaling in >> CS >>>> and only contribute Media Model these participants as not >> part of CS >>>> in the model but associated with Media Stream block ( current >>>> approach) Model these participants to be associated with >> CS but have >>>> the association labeled as "indirect participant" >>>> >>>> Let me know your thoughts. >>>> >>>> Thanks, >>>> Ram >>>> >>>>> -----Original Message----- >>>>> From: siprec-bounces@ietf.org >> [mailto:siprec-bounces@ietf.org] On >>>>> Behalf Of Elwell, John >>>>> Sent: Tuesday, April 12, 2011 12:13 PM >>>>> To: Charles Eckel (eckelcu); Parthasarathi R (partr); >> Paul Kyzivat >>>>> (pkyzivat); siprec@ietf.org >>>>> Cc: Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr) >>>>> Subject: Re: [siprec] Partial updates and identifiers >>>>> >>>>> I think the attached message was the last in that thread. So I >>> don't >>>>> really think we had closure. >>>>> >>>>> John >>>>> >>>>>> -----Original Message----- >>>>>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] >>>>>> Sent: 11 April 2011 23:53 >>>>>> To: Elwell, John; Parthasarathi R (partr); Paul Kyzivat >>>> (pkyzivat); >>>>>> siprec@ietf.org >>>>>> Cc: Peter Saint-Andre (psaintan); Joe Hildebrand >>>> (jhildebr); Hadriel >>>>>> Kaplan >>>>>> Subject: RE: [siprec] Partial updates and identifiers >>>>>> >>>>>> Hi John, >>>>>> >>>>>> I have attached the last e-mail I have from the >> thread in which >> I >>>>>> first raised this issue. Unfortunately, I do not have >> the e-mail >>>> with >>>>>> the ultimate agreement, but maybe someone else does >> or this will >>>> help >>>>>> prompt some memories. >>>>>> >>>>>> Cheers, >>>>>> Charles >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: siprec-bounces@ietf.org >>>> [mailto:siprec-bounces@ietf.org] On >>>>>> Behalf Of Elwell, John >>>>>>> Sent: Monday, April 11, 2011 9:46 AM >>>>>>> To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); >>>>>> siprec@ietf.org >>>>>>> Cc: Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr); >>>>> Hadriel >>>>>> Kaplan >>>>>>> Subject: Re: [siprec] Partial updates and identifiers >>>>>>> >>>>>>> Partha, >>>>>>> >>>>>>> Thanks for reminding me - I now recall the discussion some >>>>>> weeks/months ago about the participants >>>>>>> obtained from the conference event package. I was never >>>>> particularly >>>>>> comfortable with the fact these >>>>>>> were not considered part of the CS. While that might be >>>>>> correct if we >>>>>> consider the CS to be the SIP >>>>>>> dialog between the SRC and the conference focus, taking a >>>>>> broader view >>>>>> of CS those participants behind >>>>>>> the focus could be considered part of the CS. I don't >>>> particularly >>>>>> want to open up the old discussion >>>>>>> if people are happy with what we have, but something >>>> doesn't seem >>>>>> quite right to me. >>>>>>> >>>>>>> For example, if these "participants" are not considered part >> of >>>> the >>>>>> CS, and if we don't have specific >>>>>>> information about their involvement in media >> streams, do they >>>>> really >>>>>> merit being considered >>>>>>> Participant objects? >>>>>>> >>>>>>> In other words, two possible approaches are: >>>>>>> >>>>>>> 1) The CS extends only as far as the focus / mixer. The >>>>>> focus/mixer is >>>>>> a "Participant" and the users >>>>>>> behind the focus are not separate Participants but are just >>>>>> additional >>>>>> data associated with the >>>>>>> focus/mixer Participant. The only Media Streams we are >>>>>> concerned with >>>>>> are between the mixer and the >>>>>>> SRC. >>>>>>> >>>>>>> 2) The CS extends beyond the focus/mixer to users >>>> learned via the >>>>>> conference event package, each of >>>>>>> those users is a separate Participant object, and we >>>> are concerned >>>>>> with Media Stream objects that >>>>>>> those participants send and receive. I am not sure how >> feasible >>>>> this >>>>>> approach is, because I am not >>>>>>> sure that the SRC can obtain enough information about media >>>>>> streams at >>>>>> users behind the focus/mixer. >>>>>>> >>>>>>> It seems the present solution is somewhere between the >>>> two, which >>>>> is >>>>>> why I am uncomfortable. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> John (as individual) >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] >>>>>>>> Sent: 11 April 2011 10:29 >>>>>>>> To: Elwell, John; Paul Kyzivat (pkyzivat); siprec@ietf.org >>>>>>>> Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe >>>> Hildebrand >>>>>>>> (jhildebr) >>>>>>>> Subject: RE: [siprec] Partial updates and identifiers >>>>>>>> >>>>>>>> John, >>>>>>>> >>>>>>>> Please read inline. >>>>>>>> >>>>>>>> Thanks >>>>>>>> Partha >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Elwell, John [mailto:john.elwell@siemens- >>> enterprise.com] >>>>>>>> Sent: Monday, April 11, 2011 2:11 PM >>>>>>>> To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); >>>>>> siprec@ietf.org >>>>>>>> Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe >>>> Hildebrand >>>>>>>> (jhildebr) >>>>>>>> Subject: RE: [siprec] Partial updates and identifiers >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] >>>>>>>>> Sent: 11 April 2011 08:35 >>>>>>>>> To: Elwell, John; Paul Kyzivat (pkyzivat); >> siprec@ietf.org >>>>>>>>> Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe >>>>> Hildebrand >>>>>>>>> (jhildebr) >>>>>>>>> Subject: RE: [siprec] Partial updates and identifiers >>>>>>>>> >>>>>>>>> John, >>>>>>>>> >>>>>>>>> As I mentioned below, stream block will be unique >>>>>> within CS, (not >>>>>>>>> required to be unique across multiple CS) and so, xml:id >> or >>>>>>>> enhancing >>>>>>>>> the normative statement of RFC 4574 label >> attribute to be >>>>> unique >>>>>>>>> within CS will serve the purpose. I'm fine with >> any of the >>>>> above >>>>>>>>> mentioned id. >>>>>>>>> Please note that RFC 4574 "label" attribute is >> the nature >>>>>>>> data for RS >>>>>>>>> dialog. >>>>>>>>> >>>>>>>>> In case participant within CS, xml:id will serve the >>> purpose >>>>> but >>>>>> we >>>>>>>>> need to get more clarity about participants who are not >>>>>>>> part of CS but >>>>>>>> >>>>>>>>> within RS. >>>>>>>> [JRE] If I understand the figure in section 3 of >> metadata-04 >>>>>>>> correctly, a Participant can have a relationship with >>>> a CS, but >>>>> no >>>>>>>> direct relationship with an RS. >>>>>>>> >>>>>>>> Sorry, I mixed up my statement with the latest >>> update >>>> of >>>>>>>> making CSG optional. As per Sec 3 of metadata-04, >> participant >>>> has >>>>>>>> direct relationship with CSG in case CS is left completely >>>>>>>> unattached. In case CSG is optional, then participant >>>> will have >>>>>>>> direct relationship with RS in case there is no >> relationship >>>>>>>> between CS and participant. >>>>>>>> >>>>>>>> >>>>>>>> So a participant that does not have a relationship >>>> with a CS is >>>>>> left >>>>>>>> completely unattached, unless it has a relationship >>>> with a Media >>>>>>>> Stream (which always has a relationship with a CS). So to >>>>>>>> summarize: >>>>>>>> - a Participant can have a direct relationship >> with a CS; or >>>>>>>> - a Participant can have an indirect relationship >>>> with a CS (via >>>>> a >>>>>>>> Media Stream); agreed >>>>>>>> - a Participant can have no relationship with a CS, and >>>>>> therefore no >>>>>>>> relationship with an RS. >>>>>>>> Do we really need this last case? >>>>>>>> >>>>>>>> I'm happy if the last case is not >> required because >>> it >>>>>>>> simplify the solution and there is no need of >> unique id for >>>>>>>> participant. But SRS implementers may prefer to have >>>> relationship >>>>>>>> with participant and RS. I wish more opinion before taking >>>>>>>> decision whether to remove the last case >>>>>>>> >>>>>>>>> Because CS may span across different RS how about the >>>>>>>> participant who >>>>>>>>> are not part of CS? >>>>>>>> [JRE] I don't understand the words "Because CS may span >>> across >>>>>>>> different RS", because in the rest of the sentence you are >>>>> talking >>>>>>>> about a Participant that is not part of a CS. >>>>>>>> >>>>>>>>> Ex: One of the user in the conference acts as SRC, fetch >>>>>>>> participant >>>>>>>>> info using conferene package and new RS is created >>>>>> during initial >>>>>>>>> conference creation and hold&resume of a user within CS. >>>>>>>> [JRE] I am not sure what you are trying to say >> here. I would >>>>>>>> consider a user whose identity is obtained via a >> conference >>>> event >>>>>>>> package as being part of the CS. >>>>>>>> >>>>>>>> I'm trying to give the example where >>>> participant is not >>>>>>>> associated with CS directly but related to CSG (/RS). This >>>>>>>> scenario was considered as a blocking in -03 version of >>>> metadata. >>>>>>>> I'm not arguing to have this scenario but it is major >> concern >>>> for >>>>>>>> few folks. >>>>>>>> >>>>>>>> CS is between focus and UA, UA acts as SRC, UA >> receives the >>>>>>>> participant info via conference event package but those >>>>>>>> participants are not related in CS directly (and >> only focus >>> is >>>>>>>> related) but they contributed for the mixed stream. >> >>>>>>>> >>>>>>>> That user is sending/receiving Media Streams that >>>> are part of a >>>>>>>> CS, or if it isn't sending/receiving Media Streams, >>>> what is the >>>>>>>> relevance >>>>>> of >>>>>>>> that Participant? >>>>>>>> >>>>>>>> Mixed media stream from focus to UA >> belongs to the >>>>>> Conference >>>>>>>> event package participants. There participant are not >>> directly >>>>>>>> involved as part of CS. Why would we >>>> create a new RS >>>>>>>> for such a participant? >>>>>>>> RS is not created for participant. Multiple >>>> RS shall be >>>>>>>> created the same CS during the different time >> frame as shown >>>>> below >>>>>>>> >>>>>>>> <-------------------CS1-------------> >>>>>>>> <---RS1--> <---RS2------> >>>>>>>> >>>>>>>> CS1 is between UA (SRC) and focus whereas RS1, RS2 is >>>> between UA >>>>>> (SRC) >>>>>>>> and SRS. Here tangling (conference event package) >> participant >>>> has >>>>>>>> to be grouped together in RS1, RS2 by some means through >>> given >>>>>>>> metadata. >>>>>> The >>>>>>>> question whether this corner has to be solved ? >>>>>>>> >>>>>>>> John (as individual) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Partha >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Elwell, John >>>> [mailto:john.elwell@siemens-enterprise.com] >>>>>>>>> Sent: Friday, April 08, 2011 9:36 PM >>>>>>>>> To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); >>>>>>>> siprec@ietf.org >>>>>>>>> Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe >>>>> Hildebrand >>>>>>>>> (jhildebr) >>>>>>>>> Subject: RE: [siprec] Partial updates and identifiers >>>>>>>>> >>>>>>>>> Focusing just on participant and stream for the time >> being, >>>>>>>> do these >>>>>>>>> need to be unique across multiple CSs or not? >>>>>>>>> >>>>>>>>> John >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] >>>>>>>>>> Sent: 07 April 2011 10:51 >>>>>>>>>> To: Paul Kyzivat (pkyzivat); siprec@ietf.org; Elwell, >>> John >>>>>>>>>> Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe >>>>>> Hildebrand >>>>>>>>>> (jhildebr) >>>>>>>>>> Subject: RE: [siprec] Partial updates and identifiers >>>>>>>>>> >>>>>>>>>> John, >>>>>>>>>> >>>>>>>>>> Sorry for the lengthy mail but it contains lot of >>> analysis >>>>> and >>>>>>>>>> reasoning for this id approach. >>>>>>>>>> >>>>>>>>>> Adding to Paul's point, I wish to give more background >>> and >>>>>>>>> reason for >>>>>>>>>> these globally unique id. Initially I had the >> impression >>>> that >>>>>> the >>>>>>>>>> single unique id (RS dialog-id) in the recording >> (session >>>>>>>>> level) and >>>>>>>>>> some relevant natural id for the rest of the element >> will >>>>>>>> serve the >>>>>>>>>> purpose. >>>>>>>>>> There are usecases where this assumption fails. >>>> Even I have >>>>>>>>> thought of >>>>>>>>> >>>>>>>>>> using "xml:id" instead of URN UUID to avoid long >>>> string but >>>>>>>>> xml:id may >>>>>>>>> >>>>>>>>>> not end up with unique value always. Our analysis for >> URN >>>>>>>> UUID for >>>>>>>>>> each level is as follows and please provide your input >> in >>>>> case >>>>>> id >>>>>>>>>> shall be >>>>>>>>>> tweaked: >>>>>>>>>> >>>>>>>>>> 1) Recording block: The reason for globally >> unique id is >>>>>>>>> that multiple >>>>>>>>> >>>>>>>>>> SRC with same id to single SRS. >>>>>>>>>> >>>>>>>>>> Topology: >>>>>>>>>> >>>>>>>>>> SRC1 SRC2 >>>>>>>>>> | | >>>>>>>>>> | ----(RS1-ID1)-----SRS1 >>>>>>>>>> | >>>>>>>>>> ---(RS2-ID1)------------------SRS1 >>>>>>>>>> >>>>>>>>>> In the above topology, it is possible for ID1 is >>> generated >>>> by >>>>>> both >>>>>>>>>> SRC1 and SRC2 at the same time. >>>>>>>>>> >>>>>>>>>> 2) group (CSG) block: Grouping mechanism (Hadriel >>>>>>>> session-id, Paul >>>>>>>>>> Jones >>>>>>>>>> Session-UUID) is outside the scope of SIPREC. URN UUID >>>>>>>>> abstracts the >>>>>>>>>> exact mechanism to SRS and provides the >> information only >>>>>>>> about the >>>>>>>>>> group of CS from SRC perspective. It possible >>>> that group may >>>>>> span >>>>>>>>>> across multiple RS and It is up to SRS to >> group and view >>>>>>>> as single >>>>>>>>>> recording. >>>>>>>>>> Here, the single level id in the top will fail. >>>> The counter >>>>>>>>> argument >>>>>>>>>> is to force the single RS having complete CSG but >>>>>> it*may not* be >>>>>>>>>> possible in SRC implementation. Here, xml:id will not >>>>>> serve the >>>>>>>>>> purpose >>>>>>>>>> >>>>>>>>>> 3) session (CS) block: At the immediate look, session >>>>>>>> falls exactly >>>>>>>>>> under recording block. Use case 3 of >>>> draft-ietf-siprec-req-09 >>>>>>>>>> illustrates where CS span across multiple RS. This >>>>>>>>> requirement calls >>>>>>>>>> for unique id in session by which these >> session shall be >>>>>>>> viewed as >>>>>>>>>> single CS even though there is no group exists among >>>>>>>> them. IMO, in >>>>>>>>>> case session should not have globally unique id, >>>> then it is >>>>>>>>> preferred >>>>>>>>>> to remove usecase 3 in the requirement. >>>>>>>>>> >>>>>>>>>> 4) participant block: It needs some id which may >>>> be AOR but >>>>>>>>> AOR is not >>>>>>>>> >>>>>>>>>> unique. IMO, xml:id may serve the purpose with session >>>>>>>>> unique id. The >>>>>>>>>> trick exists for participant who are not >> associated with >>>>>>>>> CS. We shall >>>>>>>>>> discuss and fine tune if required. >>>>>>>>>> >>>>>>>>>> 5) stream block: Label attribute shall be >> used as unique >>>>>>>>> value but RFC >>>>>>>>>> 4574 does not mandate label attribute has to be unique >>>> across >>>>>> the >>>>>>>>>> dialog or CS and so, it may possible to change within >>>>>> RS and no >>>>>>>>>> normative statement to stop this implementation. IMO, >>>>>>>>> xml:id may serve >>>>>>>>> >>>>>>>>>> the purpose with session unique id. Here as well, We >>> shall >>>>>>>>> discuss and >>>>>>>>> >>>>>>>>>> fine tune if required. >>>>>>>>>> >>>>>>>>>> 6) extensiondata block: This is tracked in >> the separate >>>>>>>> mail thread >>>>>>>>>> whether unique id is required or not. Let us >> close this >>>>>>>> as part of >>>>>>>>>> that mail thread. >>>>>>>>>> >>>>>>>>>> Including explicitly Hadriel, Peter, Joe in this mail >>>>>>>>> thread as they >>>>>>>>>> have different view on this ID mechanism. >>>>>>>>>> >>>>>>>>>> I had offline discussion with Hadriel in Prague after >>>>>>>>> SIPREC meeting >>>>>>>>>> and my understanding of his major concern is that how >> SRS >>>>>>>>> will be able >>>>>>>>> >>>>>>>>>> to design the database in case partial update >>>> does not have >>>>>>>>> recording >>>>>>>>>> (top) id information. I'll put more thought >>>>>> processing to close >>>>>>>>>> Hadriel concern of how top id has to be >> tracked in case >>>>>>>>> partial update >>>>>>>>> >>>>>>>>>> by which SRS implementation will be >> simplified in terms >>> of >>>>>>>>> aggregation >>>>>>>>> >>>>>>>>>> maintenance. >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Partha >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: siprec-bounces@ietf.org >>>>>>>>>> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul >>> Kyzivat >>>>>>>>> (pkyzivat) >>>>>>>>>> Sent: Thursday, April 07, 2011 12:33 AM >>>>>>>>>> To: siprec@ietf.org >>>>>>>>>> Subject: Re: [siprec] Partial updates and identifiers >>>>>>>>>> >>>>>>>>>> John, >>>>>>>>>> >>>>>>>>>> For the moment we have proposed that the ids be >>>> conveyed in >>>>>>>>> the form >>>>>>>>>> of URIs that are globally unique, and >> specifically that >>>>>>>>> they be UUID >>>>>>>>>> URNs. >>>>>>>>>> There is no dependency on the particular form of the >> URI, >>>> but >>>>>>>>>> specifying they must be UUID URNs makes it possible to >>>>>>>> perform some >>>>>>>>>> internal optimizations for storage. >>>>>>>>>> >>>>>>>>>> The UUID URN is a pretty inefficient encoding. A UUID >> can >>>>>>>>> be expressed >>>>>>>>> >>>>>>>>>> in 32 bits, so we could consider retaining UUIDs but >>> alter >>>>> the >>>>>>>>>> encoding if its really an issue. However I am far from >>>>>>>>> convinced that >>>>>>>>>> the size of the IDs is going to be a major >> issue in the >>>>>>>>> overall size >>>>>>>>>> of messages, so I think its probably >> premature to worry >>>> about >>>>>> it. >>>>>>>>>> >>>>>>>>>> Because the ids can be expressed in 32 bits, >> the SRC and >>>>>>>>> SRS can store >>>>>>>>> >>>>>>>>>> them internally that way, thus reducing the >>>> runtime cost of >>>>>>>>>> maintaining the data. >>>>>>>>>> >>>>>>>>>> The use of unique ids is a significant part of the >>> overall >>>>>>>>> approach to >>>>>>>>> >>>>>>>>>> formatting updates. If somebody has a >> different concept >>>>>>>> in mind it >>>>>>>>>> could be useful to have an alternative >> proposal for the >>>>>>>>> format. If we >>>>>>>>>> had two worked out approaches we could compare the >>>>>>>>> tradeoffs in each. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Paul >>>>>>>>>> >>>>>>>>>> On 4/6/2011 10:24 AM, Elwell, John wrote: >>>>>>>>>>> Much of the discussion on draft-ram-metadata-format >>>>>> in Prague >>>>>>>>>> concerned the mechanism for performing partial updates >>> and >>>>>>>>> the use of >>>>>>>>>> identifiers. The draft permits partial updates by >>> allowing >>>>>>>>> individual >>>>>>>>>> objects (e.g., CS, participant, media stream) >> to be sent >>>>>>>>> with updated >>>>>>>>>> content, without having to send again other >> objects that >>>> have >>>>>> not >>>>>>>>>> changed. So, for example, in a large conference, it >> would >>>>>>>>> be possible >>>>>>>>>> to add or modify an individual participant object >> without >>>>>>>> having to >>>>>>>>>> send all the other participant objects again. I do not >>>> recall >>>>>> any >>>>>>>>>> opposition to this basic principle. >>>>>>>>>>> >>>>>>>>>>> However, to achieve this, every object requires an >>>>>>>>>> identifier, and it >>>>>>>>>> was asserted that these identifiers need to >> be globally >>>>>>>>> unique for all >>>>>>>>> >>>>>>>>>> time. Although this might be efficient for updating an >>>>>> individual >>>>>>>>>> object, when sending many objects (e.g., at >> the start of >>> a >>>>>>>>> CS or when >>>>>>>>>> refreshing the entire metadata), this can make the >>>>>> metadata very >>>>>>>>>> bulky. >>>>>>>>>> It depends, of course, on the format of the >> identifiers, >>>>>>>> and it was >>>>>>>>>> stated that there could be alternatives to UUID. >>>>>>>> Nevertheless, some >>>>>>>>>> people had concerns. These concerns also >> extended to the >>>>>>>>> impact on the >>>>>>>>> >>>>>>>>>> database where metadata is stored, since it >> might not be >>>>>>>>> feasible to >>>>>>>>>> convert to a database-friendly mechanism for linking >>>>>>>>> objects together. >>>>>>>>>>> >>>>>>>>>>> One alternative proposal during the meeting was >>>> to have a >>>>>> single >>>>>>>>>> unique identifier at the top level (for the >> RS) and use >>>> local >>>>>>>>>> identifiers for other objects. Thus when updating a >>> single >>>>>>>>> object, it >>>>>>>>>> would be necessary to include the top level identifier >> as >>>>>>>>> well as one >>>>>>>>>> or more local identifiers. However, there were >>>> also concerns >>>>>> this >>>>>>>>>> might not fulfil actual or perceived future >> requirements. >>>>>>>>>>> >>>>>>>>>>> Please continue discussion on this. >>>>>>>>>>> >>>>>>>>>>> John (as chair) >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> siprec mailing list >>>>>>>>>>> siprec@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> siprec mailing list >>>>>>>>>> siprec@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> siprec mailing list >>>>>>> siprec@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>> >>>> _______________________________________________ >>>> siprec mailing list >>>> siprec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/siprec >>>> _______________________________________________ >>>> siprec mailing list >>>> siprec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/siprec >>>> >>> _______________________________________________ >>> siprec mailing list >>> siprec@ietf.org >>> https://www.ietf.org/mailman/listinfo/siprec >> > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From rmohanr@cisco.com Fri Apr 15 09:54:29 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id F34E5130043 for ; Fri, 15 Apr 2011 09:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.185 X-Spam-Level: X-Spam-Status: No, score=-9.185 tagged_above=-999 required=5 tests=[AWL=-0.986, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKMgutqpL-lI for ; Fri, 15 Apr 2011 09:54:24 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfc.amsl.com (Postfix) with ESMTP id 2714213001A for ; Fri, 15 Apr 2011 09:54:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=37088; q=dns/txt; s=iport; t=1302886463; x=1304096063; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=6zdH8GfI1YKCd5t55LS65ZEdkoQH65EUHz08K9SDnN0=; b=knexjBCvxhkh+2WxEupgrDHve23fOYjpzlP+zD2WqfDOZdSKFOWc7Hqa qRost9yeoGTpc/ao9K8ugGjb0Uo9ayC08z05IBdhsa0hERx2rgtqWI1Cg E1F6EYMsOZojR5mTnEMIKBJwaQzItkuLTL4D8y6r/v4iRJQwd6wxhR12a 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjcBAE13qE2Q/khMgWdsb2JhbACYBY1/FAEBFiYliG+fF50Bgn+CbwSFXowV X-IronPort-AV: E=Sophos;i="4.64,220,1301875200"; d="scan'208";a="83792458" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 15 Apr 2011 16:54:21 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3FGs1TS017228; Fri, 15 Apr 2011 16:54: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); Fri, 15 Apr 2011 22:24:16 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-hashedpuzzle: BOMq D4A3 F+ux HGOD HGnr HtiE L4Il MKdC OAbF OuGd O/yP QQcR SLGl Sbhg TCeE WXL/; 2; agBvAGgAbgAuAGUAbAB3AGUAbABsAEAAcwBpAGUAbQBlAG4AcwAtAGUAbgB0AGUAcgBwAHIAaQBzAGUALgBjAG8AbQA7AHMAaQBwAHIAZQBjAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {8CE7BE02-D724-4573-A3AB-EF24E57B8A6F}; cgBtAG8AaABhAG4AcgBAAGMAaQBzAGMAbwAuAGMAbwBtAA==; Fri, 15 Apr 2011 16:53:58 GMT; UgBFADoAIABbAHMAaQBwAHIAZQBjAF0AIABGAFcAOgAgAEQAbwAgAHcAZQAgAG4AZQBlAGQAIAB0AG8AIABtAG8AZABlAGwAIABwAGEAcgB0AGkAYwBpAHAAYQBuAHQAcwAgAG4AbwB0ACAAcABhAHIAdAAgAG8AZgBDAFMAIABiAHUAdABhAHMAcwBvAGMAaQBhAHQAZQBkACAAdwBpAHQAaAAgAE0AZQBkAGkAYQAgAFMAdAByAGUAYQBtACAAYgBsAG8AYwBrACAAaQBuACAAdABoAGUAIABtAGUAdABhAGQAYQB0AGEAbQBvAGQAZQBsACAAPwAJACgAdwBhAHMAIABSAEUAOgAgAFAAYQByAHQAaQBhAGwAIAB1AHAAZABhAHQAZQBzACAAYQBuAGQAIABpAGQAZQBuAHQAaQBmAGkAZQByAHMAKQA= x-cr-puzzleid: {8CE7BE02-D724-4573-A3AB-EF24E57B8A6F} Content-class: urn:content-classes:message Date: Fri, 15 Apr 2011 22:23:58 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD0613330A@XMB-BGL-417.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] FW: Do we need to model participants not part ofCS butassociated with Media Stream block in the metadatamodel ? (was RE: Partial updates and identifiers) Thread-Index: Acv0jVXI4ji2YTo+SquJ6T6YR3i+lQAdOkDgAEETmvAAg54qsAADKDEgAADSn+AAEAO1UAANZylQABBzW2AABHtBwACZNyqAAAGC+nAAAd/QMAAHC/qgAADkBPAAAwwR4A== References: <35BCE99A477D6A4986FB2216D8CF2CFD061331FF@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD061332DC@XMB-BGL-417.cisco.com> From: "Ram Mohan R (rmohanr)" To: "Elwell, John" , "Parthasarathi R (partr)" , X-OriginalArrivalTime: 15 Apr 2011 16:54:16.0655 (UTC) FILETIME=[C18F5DF0:01CBFB8D] Subject: Re: [siprec] FW: Do we need to model participants not part ofCS butassociated with Media Stream block in the metadatamodel ? (was RE: Partial updates and identifiers) X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 15 Apr 2011 16:54:29 -0000 Hi John, Please see inline > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Friday, April 15, 2011 8:57 PM > To: Ram Mohan R (rmohanr); Parthasarathi R (partr); siprec@ietf.org > Subject: RE: [siprec] FW: Do we need to model participants not part > ofCS butassociated with Media Stream block in the metadatamodel ? (was > RE: Partial updates and identifiers) >=20 >=20 >=20 > > -----Original Message----- > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > Sent: 15 April 2011 16:04 > > To: Parthasarathi R (partr); Elwell, John; siprec@ietf.org > > Subject: RE: [siprec] FW: Do we need to model participants > > not part ofCS butassociated with Media Stream block in the > > metadatamodel ? (was RE: Partial updates and identifiers) > > > > I am ok with associating participants behind a UA [ for case > > where UA is > > capable of learning them] in CS as part of that CS in the > > model/format. > > One question I have is, Do we need to distinguish these participants > > from the others by having some attributes as part of > > participant block? > > Or is it sufficient if we just treat them as any other participants > of > > CS. > [JRE] We could treat them as other Participants, but if we don't have > information about the media they are sending receiving and therefore > all media is seen by the SRC as being sent/received by the conference > UA, then I don't really see it makes sense to treat them as separate > Participant objects. Yes I agree with you. My thought here is for cases where the conference UA can learn the other participants, we can convey them as separate participant objects in the model, of course all of them will be associated ("sends" association) with the same mixed stream. For cases where conference UA cannot determine, we will have only one participant object ( i.e. conference UA) conveyed in the model I hope this would be sufficient for most use cases. >=20 > > > > There are three categories of participants: > > Participants who contribute both signaling and media to CS > > Participants who contribute only media in the CS [ like the > > below case] > > Participants who contribute only signaling to CS [e.g. 3pcc > > controller] > [JRE] I don't think this distinction is particularly relevant to what > gets sent to the SRS, stored, and subsequently played back. The > information that really needs to be captured is which participants > send/receive which media, and signalling. Signalling is just part of > the CS mechanism that has no relevance to what gets recorded and played > back. I don't see why a 3PCC controller would be considered a > Participant. I am ok to NOT have this distinction. If there is anyone who sees a need for this/have a use case that needs this distinction we can consider otherwise we can ignore this aspect. Regards, Ram >=20 > John (as individual) >=20 > > > > Ram > > > > > -----Original Message----- > > > From: Parthasarathi R (partr) > > > Sent: Friday, April 15, 2011 5:28 PM > > > To: Elwell, John; Ram Mohan R (rmohanr); siprec@ietf.org > > > Subject: RE: [siprec] FW: Do we need to model participants not part > > > ofCS butassociated with Media Stream block in the > > metadatamodel ? (was > > > RE: Partial updates and identifiers) > > > > > > John point of view looks reasonable to me because CS is not > directly > > > associated with dialogs but instead it represents session with the > > list > > > of participant involved in it. > > > > > > In case of participant list received through conference > > package to SRC > > > with UA, those multiple participants from focus shall be > represented > > as > > > individual participant block who are pointed to single mixed media > > > stream metadata block and all participant belongs within single > > > conference CS in this scenario. The model is as follows > > (part in the > > > diagram represents participant): > > > > > > > > > RS > > > | > > > CS------------------------------- > > > | | > > > ----------------------- part5(SRC) > > > | | | | | > > > | | | | media stream2 > > > part1 part2 part3 part4 > > > | | | | > > > ------------------------- > > > | > > > Media stream1 > > > > > > Thanks > > > Partha > > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > > Behalf Of Elwell, John > > > Sent: Friday, April 15, 2011 4:34 PM > > > To: Ram Mohan R (rmohanr); siprec@ietf.org > > > Subject: Re: [siprec] FW: Do we need to model participants not part > > > ofCS butassociated with Media Stream block in the > > metadatamodel ? (was > > > RE: Partial updates and identifiers) > > > > > > As an individual, my opinion, which I have pretty much > > stated before, > > > is that a participant must always be part of a CS. A couple of > > > situations have been mentioned where alternatives might be > required, > > > but I don't believe so. > > > > > > 1. Conferences. I think depending what view the SRC has of the CS, > > > there are two situations: > > > > > > (a) The SRC sees all parties in the conference and has visibility > of > > > what Media Streams each party sends and receives. In this case, I > > think > > > the whole conference can be modelled as a CS and each party can be > > > modelled as a Participant in that CS. Such a view will typically be > > > feasible when the SRC is located at a conference > > focus/mixer (e.g., an > > > MCU). > > > > > > (b) The SRC sees the conference focus mixer as a party but > > has limited > > > information about parties behind the focus/mixer. In this > > case I think > > > the SRC can regard the CS as terminating at the conference > > > (focus/mixer), with the conference a Participant in that CS. > > > Information about parties behind the conference may or may not be > > > available, in which case they can be additional attributes of the > > > conference Participant object. One typical case will be > > where the SRC > > > is located at a UA of one of the conference parties, or at a B2BUA > > > between the focus/mixer and a party UA. In that case the CS > > would have > > > two Participants: the party concerned and the conference. Am > extreme > > > case is where the conference is the sole Participant and > > just records > > > Media Streams sent by the conference to parties in the conference. > > > > > > Hybrid situations can occur, e.g., for cascaded conferences, where > > > participants at one conference are modelled as Participants > > but other > > > conferences are just modelled each as a single Participant. > > > > > > 2. IVR and similar. I would model the Media Server as a > > Participant in > > > the CS, i.e., there is a CS between the Media Server and the > caller. > > > > > > John > > > > > > > -----Original Message----- > > > > From: siprec-bounces@ietf.org > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Ram Mohan R > > (rmohanr) > > > > Sent: 15 April 2011 10:56 > > > > To: siprec@ietf.org > > > > Subject: [siprec] FW: Do we need to model participants not part > of > > CS > > > > butassociated with Media Stream block in the metadata model ? > (was > > > RE: > > > > Partial updates and identifiers) > > > > > > > > I request people to provide inputs on this and help to > > take it to a > > > > closure. This issue has been open for several months now. > > > > > > > > Ram > > > > > > > > -----Original Message----- > > > > From: siprec-bounces@ietf.org > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Ram Mohan R > > (rmohanr) > > > > Sent: Tuesday, April 12, 2011 3:04 PM > > > > To: Elwell, John; Charles Eckel (eckelcu); Parthasarathi > > R (partr); > > > > Paul Kyzivat (pkyzivat); siprec@ietf.org > > > > Cc: Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr) > > > > Subject: [siprec] Do we need to model participants not part of CS > > but > > > > associated with Media Stream block in the metadata model > > ? (was RE: > > > > Partial updates and identifiers) > > > > > > > > Renaming the mail thread to discussion to this specific issue - > > > > "Metadata for participants not part of CS" which we have been > > > > discussing from several weeks. > > > > > > > > Please continue the other issues in original thread and lets use > > this > > > > thread to close this issue. I would request people to give inputs > > for > > > > this issue on this thread and take it to a conclusion. > > > > > > > > We(Authors of Metadata model) included participants that are not > > part > > > > of CS to imply: > > > > - Participants that does NOT contribute to signaling in CS but > > > > contributes to media The intent is to give more flexibility in > the > > > > metamodel to represent these types of participants. > > > > > > > > Following are some of use case where this can happen- > > > > > > > > Use-Case 1: A conference where one of the participants is > > a SRC. In > > > > these case the Focus which talks to this SRC becomes part of CS > > > > contributing signaling as well as media. However the > > media includes > > > > media from other participants that are not part of CS. Please > note > > > SRC > > > > has to subscribe to conf event packet to get this > > information (which > > > > may not be always feasible). > > > > > > > > Use-Case 2: one UA in CS works in 3pcc mode to acquire an > > MoH media > > > > stream, this might be reflected as unique source for media > stream > > > > without having a reported signaling relationship to it. E.g is > > > given > > > > here by Henry Lum > > > > http://www.ietf.org/mail-archive/web/siprec/current/msg01372.html > > > > > > > > In some sense these participants are *still* part of CS as they > > > > contribute to CS media. > > > > > > > > There are three approaches I can see- > > > > Don't model the participants that does not contribute signaling > in > > CS > > > > and only contribute Media Model these participants as not > > part of CS > > > > in the model but associated with Media Stream block ( current > > > > approach) Model these participants to be associated with > > CS but have > > > > the association labeled as "indirect participant" > > > > > > > > Let me know your thoughts. > > > > > > > > Thanks, > > > > Ram > > > > > > > > > -----Original Message----- > > > > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On > > > > > Behalf Of Elwell, John > > > > > Sent: Tuesday, April 12, 2011 12:13 PM > > > > > To: Charles Eckel (eckelcu); Parthasarathi R (partr); > > Paul Kyzivat > > > > > (pkyzivat); siprec@ietf.org > > > > > Cc: Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr) > > > > > Subject: Re: [siprec] Partial updates and identifiers > > > > > > > > > > I think the attached message was the last in that thread. So I > > > don't > > > > > really think we had closure. > > > > > > > > > > John > > > > > > > > > > > -----Original Message----- > > > > > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > > > > Sent: 11 April 2011 23:53 > > > > > > To: Elwell, John; Parthasarathi R (partr); Paul Kyzivat > > > > (pkyzivat); > > > > > > siprec@ietf.org > > > > > > Cc: Peter Saint-Andre (psaintan); Joe Hildebrand > > > > (jhildebr); Hadriel > > > > > > Kaplan > > > > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > > > > > > > Hi John, > > > > > > > > > > > > I have attached the last e-mail I have from the > > thread in which > > I > > > > > > first raised this issue. Unfortunately, I do not have > > the e-mail > > > > with > > > > > > the ultimate agreement, but maybe someone else does > > or this will > > > > help > > > > > > prompt some memories. > > > > > > > > > > > > Cheers, > > > > > > Charles > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: siprec-bounces@ietf.org > > > > [mailto:siprec-bounces@ietf.org] On > > > > > > Behalf Of Elwell, John > > > > > > > Sent: Monday, April 11, 2011 9:46 AM > > > > > > > To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); > > > > > > siprec@ietf.org > > > > > > > Cc: Peter Saint-Andre (psaintan); Joe Hildebrand > (jhildebr); > > > > > Hadriel > > > > > > Kaplan > > > > > > > Subject: Re: [siprec] Partial updates and identifiers > > > > > > > > > > > > > > Partha, > > > > > > > > > > > > > > Thanks for reminding me - I now recall the discussion some > > > > > > weeks/months ago about the participants > > > > > > > obtained from the conference event package. I was never > > > > > particularly > > > > > > comfortable with the fact these > > > > > > > were not considered part of the CS. While that might be > > > > > > correct if we > > > > > > consider the CS to be the SIP > > > > > > > dialog between the SRC and the conference focus, taking a > > > > > > broader view > > > > > > of CS those participants behind > > > > > > > the focus could be considered part of the CS. I don't > > > > particularly > > > > > > want to open up the old discussion > > > > > > > if people are happy with what we have, but something > > > > doesn't seem > > > > > > quite right to me. > > > > > > > > > > > > > > For example, if these "participants" are not considered > part > > of > > > > the > > > > > > CS, and if we don't have specific > > > > > > > information about their involvement in media > > streams, do they > > > > > really > > > > > > merit being considered > > > > > > > Participant objects? > > > > > > > > > > > > > > In other words, two possible approaches are: > > > > > > > > > > > > > > 1) The CS extends only as far as the focus / mixer. The > > > > > > focus/mixer is > > > > > > a "Participant" and the users > > > > > > > behind the focus are not separate Participants but are just > > > > > > additional > > > > > > data associated with the > > > > > > > focus/mixer Participant. The only Media Streams we are > > > > > > concerned with > > > > > > are between the mixer and the > > > > > > > SRC. > > > > > > > > > > > > > > 2) The CS extends beyond the focus/mixer to users > > > > learned via the > > > > > > conference event package, each of > > > > > > > those users is a separate Participant object, and we > > > > are concerned > > > > > > with Media Stream objects that > > > > > > > those participants send and receive. I am not sure how > > feasible > > > > > this > > > > > > approach is, because I am not > > > > > > > sure that the SRC can obtain enough information about media > > > > > > streams at > > > > > > users behind the focus/mixer. > > > > > > > > > > > > > > It seems the present solution is somewhere between the > > > > two, which > > > > > is > > > > > > why I am uncomfortable. > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > John (as individual) > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > > > > > Sent: 11 April 2011 10:29 > > > > > > > > To: Elwell, John; Paul Kyzivat (pkyzivat); > siprec@ietf.org > > > > > > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe > > > > Hildebrand > > > > > > > > (jhildebr) > > > > > > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > > > > > > > > > > > John, > > > > > > > > > > > > > > > > Please read inline. > > > > > > > > > > > > > > > > Thanks > > > > > > > > Partha > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Elwell, John [mailto:john.elwell@siemens- > > > enterprise.com] > > > > > > > > Sent: Monday, April 11, 2011 2:11 PM > > > > > > > > To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); > > > > > > siprec@ietf.org > > > > > > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe > > > > Hildebrand > > > > > > > > (jhildebr) > > > > > > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > > > > > > Sent: 11 April 2011 08:35 > > > > > > > > > To: Elwell, John; Paul Kyzivat (pkyzivat); > > siprec@ietf.org > > > > > > > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe > > > > > Hildebrand > > > > > > > > > (jhildebr) > > > > > > > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > > > > > > > > > > > > > John, > > > > > > > > > > > > > > > > > > As I mentioned below, stream block will be unique > > > > > > within CS, (not > > > > > > > > > required to be unique across multiple CS) and so, > xml:id > > or > > > > > > > > enhancing > > > > > > > > > the normative statement of RFC 4574 label > > attribute to be > > > > > unique > > > > > > > > > within CS will serve the purpose. I'm fine with > > any of the > > > > > above > > > > > > > > > mentioned id. > > > > > > > > > Please note that RFC 4574 "label" attribute is > > the nature > > > > > > > > data for RS > > > > > > > > > dialog. > > > > > > > > > > > > > > > > > > In case participant within CS, xml:id will serve the > > > purpose > > > > > but > > > > > > we > > > > > > > > > need to get more clarity about participants who are not > > > > > > > > part of CS but > > > > > > > > > > > > > > > > > within RS. > > > > > > > > [JRE] If I understand the figure in section 3 of > > metadata-04 > > > > > > > > correctly, a Participant can have a relationship with > > > > a CS, but > > > > > no > > > > > > > > direct relationship with an RS. > > > > > > > > > > > > > > > > Sorry, I mixed up my statement with the latest > > > update > > > > of > > > > > > > > making CSG optional. As per Sec 3 of metadata-04, > > participant > > > > has > > > > > > > > direct relationship with CSG in case CS is left > completely > > > > > > > > unattached. In case CSG is optional, then participant > > > > will have > > > > > > > > direct relationship with RS in case there is no > > relationship > > > > > > > > between CS and participant. > > > > > > > > > > > > > > > > > > > > > > > > So a participant that does not have a relationship > > > > with a CS is > > > > > > left > > > > > > > > completely unattached, unless it has a relationship > > > > with a Media > > > > > > > > Stream (which always has a relationship with a CS). So to > > > > > > > > summarize: > > > > > > > > - a Participant can have a direct relationship > > with a CS; or > > > > > > > > - a Participant can have an indirect relationship > > > > with a CS (via > > > > > a > > > > > > > > Media Stream); agreed > > > > > > > > - a Participant can have no relationship with a CS, and > > > > > > therefore no > > > > > > > > relationship with an RS. > > > > > > > > Do we really need this last case? > > > > > > > > > > > > > > > > I'm happy if the last case is not > > required because > > > it > > > > > > > > simplify the solution and there is no need of > > unique id for > > > > > > > > participant. But SRS implementers may prefer to have > > > > relationship > > > > > > > > with participant and RS. I wish more opinion before > taking > > > > > > > > decision whether to remove the last case > > > > > > > > > > > > > > > > > Because CS may span across different RS how about the > > > > > > > > participant who > > > > > > > > > are not part of CS? > > > > > > > > [JRE] I don't understand the words "Because CS may span > > > across > > > > > > > > different RS", because in the rest of the sentence you > are > > > > > talking > > > > > > > > about a Participant that is not part of a CS. > > > > > > > > > > > > > > > > > Ex: One of the user in the conference acts as SRC, > fetch > > > > > > > > participant > > > > > > > > > info using conferene package and new RS is created > > > > > > during initial > > > > > > > > > conference creation and hold&resume of a user within > CS. > > > > > > > > [JRE] I am not sure what you are trying to say > > here. I would > > > > > > > > consider a user whose identity is obtained via a > > conference > > > > event > > > > > > > > package as being part of the CS. > > > > > > > > > > > > > > > > I'm trying to give the example where > > > > participant is not > > > > > > > > associated with CS directly but related to CSG (/RS). > This > > > > > > > > scenario was considered as a blocking in -03 version of > > > > metadata. > > > > > > > > I'm not arguing to have this scenario but it is major > > concern > > > > for > > > > > > > > few folks. > > > > > > > > > > > > > > > > CS is between focus and UA, UA acts as SRC, UA > > receives the > > > > > > > > participant info via conference event package but those > > > > > > > > participants are not related in CS directly (and > > only focus > > > is > > > > > > > > related) but they contributed for the mixed stream. > > > > > > > > > > > > > > > > > > That user is sending/receiving Media Streams that > > > > are part of a > > > > > > > > CS, or if it isn't sending/receiving Media Streams, > > > > what is the > > > > > > > > relevance > > > > > > of > > > > > > > > that Participant? > > > > > > > > > > > > > > > > Mixed media stream from focus to UA > > belongs to the > > > > > > Conference > > > > > > > > event package participants. There participant are not > > > directly > > > > > > > > involved as part of CS. Why would we > > > > create a new RS > > > > > > > > for such a participant? > > > > > > > > RS is not created for participant. Multiple > > > > RS shall be > > > > > > > > created the same CS during the different time > > frame as shown > > > > > below > > > > > > > > > > > > > > > > <-------------------CS1-------------> > > > > > > > > <---RS1--> <---RS2------> > > > > > > > > > > > > > > > > CS1 is between UA (SRC) and focus whereas RS1, RS2 is > > > > between UA > > > > > > (SRC) > > > > > > > > and SRS. Here tangling (conference event package) > > participant > > > > has > > > > > > > > to be grouped together in RS1, RS2 by some means through > > > given > > > > > > > > metadata. > > > > > > The > > > > > > > > question whether this corner has to be solved ? > > > > > > > > > > > > > > > > John (as individual) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > Partha > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Elwell, John > > > > [mailto:john.elwell@siemens-enterprise.com] > > > > > > > > > Sent: Friday, April 08, 2011 9:36 PM > > > > > > > > > To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); > > > > > > > > siprec@ietf.org > > > > > > > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe > > > > > Hildebrand > > > > > > > > > (jhildebr) > > > > > > > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > > > > > > > > > > > > > Focusing just on participant and stream for the time > > being, > > > > > > > > do these > > > > > > > > > need to be unique across multiple CSs or not? > > > > > > > > > > > > > > > > > > John > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Parthasarathi R (partr) > [mailto:partr@cisco.com] > > > > > > > > > > Sent: 07 April 2011 10:51 > > > > > > > > > > To: Paul Kyzivat (pkyzivat); siprec@ietf.org; Elwell, > > > John > > > > > > > > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe > > > > > > Hildebrand > > > > > > > > > > (jhildebr) > > > > > > > > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > > > > > > > > > > > > > > > John, > > > > > > > > > > > > > > > > > > > > Sorry for the lengthy mail but it contains lot of > > > analysis > > > > > and > > > > > > > > > > reasoning for this id approach. > > > > > > > > > > > > > > > > > > > > Adding to Paul's point, I wish to give more > background > > > and > > > > > > > > > reason for > > > > > > > > > > these globally unique id. Initially I had the > > impression > > > > that > > > > > > the > > > > > > > > > > single unique id (RS dialog-id) in the recording > > (session > > > > > > > > > level) and > > > > > > > > > > some relevant natural id for the rest of the element > > will > > > > > > > > serve the > > > > > > > > > > purpose. > > > > > > > > > > There are usecases where this assumption fails. > > > > Even I have > > > > > > > > > thought of > > > > > > > > > > > > > > > > > > > using "xml:id" instead of URN UUID to avoid long > > > > string but > > > > > > > > > xml:id may > > > > > > > > > > > > > > > > > > > not end up with unique value always. Our analysis for > > URN > > > > > > > > UUID for > > > > > > > > > > each level is as follows and please provide your > input > > in > > > > > case > > > > > > id > > > > > > > > > > shall be > > > > > > > > > > tweaked: > > > > > > > > > > > > > > > > > > > > 1) Recording block: The reason for globally > > unique id is > > > > > > > > > that multiple > > > > > > > > > > > > > > > > > > > SRC with same id to single SRS. > > > > > > > > > > > > > > > > > > > > Topology: > > > > > > > > > > > > > > > > > > > > SRC1 SRC2 > > > > > > > > > > | | > > > > > > > > > > | ----(RS1-ID1)-----SRS1 > > > > > > > > > > | > > > > > > > > > > ---(RS2-ID1)------------------SRS1 > > > > > > > > > > > > > > > > > > > > In the above topology, it is possible for ID1 is > > > generated > > > > by > > > > > > both > > > > > > > > > > SRC1 and SRC2 at the same time. > > > > > > > > > > > > > > > > > > > > 2) group (CSG) block: Grouping mechanism (Hadriel > > > > > > > > session-id, Paul > > > > > > > > > > Jones > > > > > > > > > > Session-UUID) is outside the scope of SIPREC. URN > UUID > > > > > > > > > abstracts the > > > > > > > > > > exact mechanism to SRS and provides the > > information only > > > > > > > > about the > > > > > > > > > > group of CS from SRC perspective. It possible > > > > that group may > > > > > > span > > > > > > > > > > across multiple RS and It is up to SRS to > > group and view > > > > > > > > as single > > > > > > > > > > recording. > > > > > > > > > > Here, the single level id in the top will fail. > > > > The counter > > > > > > > > > argument > > > > > > > > > > is to force the single RS having complete CSG but > > > > > > it*may not* be > > > > > > > > > > possible in SRC implementation. Here, xml:id will not > > > > > > serve the > > > > > > > > > > purpose > > > > > > > > > > > > > > > > > > > > 3) session (CS) block: At the immediate look, session > > > > > > > > falls exactly > > > > > > > > > > under recording block. Use case 3 of > > > > draft-ietf-siprec-req-09 > > > > > > > > > > illustrates where CS span across multiple RS. This > > > > > > > > > requirement calls > > > > > > > > > > for unique id in session by which these > > session shall be > > > > > > > > viewed as > > > > > > > > > > single CS even though there is no group exists among > > > > > > > > them. IMO, in > > > > > > > > > > case session should not have globally unique id, > > > > then it is > > > > > > > > > preferred > > > > > > > > > > to remove usecase 3 in the requirement. > > > > > > > > > > > > > > > > > > > > 4) participant block: It needs some id which may > > > > be AOR but > > > > > > > > > AOR is not > > > > > > > > > > > > > > > > > > > unique. IMO, xml:id may serve the purpose with > session > > > > > > > > > unique id. The > > > > > > > > > > trick exists for participant who are not > > associated with > > > > > > > > > CS. We shall > > > > > > > > > > discuss and fine tune if required. > > > > > > > > > > > > > > > > > > > > 5) stream block: Label attribute shall be > > used as unique > > > > > > > > > value but RFC > > > > > > > > > > 4574 does not mandate label attribute has to be > unique > > > > across > > > > > > the > > > > > > > > > > dialog or CS and so, it may possible to change within > > > > > > RS and no > > > > > > > > > > normative statement to stop this implementation. IMO, > > > > > > > > > xml:id may serve > > > > > > > > > > > > > > > > > > > the purpose with session unique id. Here as well, We > > > shall > > > > > > > > > discuss and > > > > > > > > > > > > > > > > > > > fine tune if required. > > > > > > > > > > > > > > > > > > > > 6) extensiondata block: This is tracked in > > the separate > > > > > > > > mail thread > > > > > > > > > > whether unique id is required or not. Let us > > close this > > > > > > > > as part of > > > > > > > > > > that mail thread. > > > > > > > > > > > > > > > > > > > > Including explicitly Hadriel, Peter, Joe in this mail > > > > > > > > > thread as they > > > > > > > > > > have different view on this ID mechanism. > > > > > > > > > > > > > > > > > > > > I had offline discussion with Hadriel in Prague after > > > > > > > > > SIPREC meeting > > > > > > > > > > and my understanding of his major concern is that how > > SRS > > > > > > > > > will be able > > > > > > > > > > > > > > > > > > > to design the database in case partial update > > > > does not have > > > > > > > > > recording > > > > > > > > > > (top) id information. I'll put more thought > > > > > > processing to close > > > > > > > > > > Hadriel concern of how top id has to be > > tracked in case > > > > > > > > > partial update > > > > > > > > > > > > > > > > > > > by which SRS implementation will be > > simplified in terms > > > of > > > > > > > > > aggregation > > > > > > > > > > > > > > > > > > > maintenance. > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > Partha > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: siprec-bounces@ietf.org > > > > > > > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul > > > Kyzivat > > > > > > > > > (pkyzivat) > > > > > > > > > > Sent: Thursday, April 07, 2011 12:33 AM > > > > > > > > > > To: siprec@ietf.org > > > > > > > > > > Subject: Re: [siprec] Partial updates and identifiers > > > > > > > > > > > > > > > > > > > > John, > > > > > > > > > > > > > > > > > > > > For the moment we have proposed that the ids be > > > > conveyed in > > > > > > > > > the form > > > > > > > > > > of URIs that are globally unique, and > > specifically that > > > > > > > > > they be UUID > > > > > > > > > > URNs. > > > > > > > > > > There is no dependency on the particular form of the > > URI, > > > > but > > > > > > > > > > specifying they must be UUID URNs makes it possible > to > > > > > > > > perform some > > > > > > > > > > internal optimizations for storage. > > > > > > > > > > > > > > > > > > > > The UUID URN is a pretty inefficient encoding. A UUID > > can > > > > > > > > > be expressed > > > > > > > > > > > > > > > > > > > in 32 bits, so we could consider retaining UUIDs but > > > alter > > > > > the > > > > > > > > > > encoding if its really an issue. However I am far > from > > > > > > > > > convinced that > > > > > > > > > > the size of the IDs is going to be a major > > issue in the > > > > > > > > > overall size > > > > > > > > > > of messages, so I think its probably > > premature to worry > > > > about > > > > > > it. > > > > > > > > > > > > > > > > > > > > Because the ids can be expressed in 32 bits, > > the SRC and > > > > > > > > > SRS can store > > > > > > > > > > > > > > > > > > > them internally that way, thus reducing the > > > > runtime cost of > > > > > > > > > > maintaining the data. > > > > > > > > > > > > > > > > > > > > The use of unique ids is a significant part of the > > > overall > > > > > > > > > approach to > > > > > > > > > > > > > > > > > > > formatting updates. If somebody has a > > different concept > > > > > > > > in mind it > > > > > > > > > > could be useful to have an alternative > > proposal for the > > > > > > > > > format. If we > > > > > > > > > > had two worked out approaches we could compare the > > > > > > > > > tradeoffs in each. > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > Paul > > > > > > > > > > > > > > > > > > > > On 4/6/2011 10:24 AM, Elwell, John wrote: > > > > > > > > > > > Much of the discussion on draft-ram-metadata-format > > > > > > in Prague > > > > > > > > > > concerned the mechanism for performing partial > updates > > > and > > > > > > > > > the use of > > > > > > > > > > identifiers. The draft permits partial updates by > > > allowing > > > > > > > > > individual > > > > > > > > > > objects (e.g., CS, participant, media stream) > > to be sent > > > > > > > > > with updated > > > > > > > > > > content, without having to send again other > > objects that > > > > have > > > > > > not > > > > > > > > > > changed. So, for example, in a large conference, it > > would > > > > > > > > > be possible > > > > > > > > > > to add or modify an individual participant object > > without > > > > > > > > having to > > > > > > > > > > send all the other participant objects again. I do > not > > > > recall > > > > > > any > > > > > > > > > > opposition to this basic principle. > > > > > > > > > > > > > > > > > > > > > > However, to achieve this, every object requires an > > > > > > > > > > identifier, and it > > > > > > > > > > was asserted that these identifiers need to > > be globally > > > > > > > > > unique for all > > > > > > > > > > > > > > > > > > > time. Although this might be efficient for updating > an > > > > > > individual > > > > > > > > > > object, when sending many objects (e.g., at > > the start of > > > a > > > > > > > > > CS or when > > > > > > > > > > refreshing the entire metadata), this can make the > > > > > > metadata very > > > > > > > > > > bulky. > > > > > > > > > > It depends, of course, on the format of the > > identifiers, > > > > > > > > and it was > > > > > > > > > > stated that there could be alternatives to UUID. > > > > > > > > Nevertheless, some > > > > > > > > > > people had concerns. These concerns also > > extended to the > > > > > > > > > impact on the > > > > > > > > > > > > > > > > > > > database where metadata is stored, since it > > might not be > > > > > > > > > feasible to > > > > > > > > > > convert to a database-friendly mechanism for linking > > > > > > > > > objects together. > > > > > > > > > > > > > > > > > > > > > > One alternative proposal during the meeting was > > > > to have a > > > > > > single > > > > > > > > > > unique identifier at the top level (for the > > RS) and use > > > > local > > > > > > > > > > identifiers for other objects. Thus when updating a > > > single > > > > > > > > > object, it > > > > > > > > > > would be necessary to include the top level > identifier > > as > > > > > > > > > well as one > > > > > > > > > > or more local identifiers. However, there were > > > > also concerns > > > > > > this > > > > > > > > > > might not fulfil actual or perceived future > > requirements. > > > > > > > > > > > > > > > > > > > > > > Please continue discussion on this. > > > > > > > > > > > > > > > > > > > > > > John (as chair) > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > siprec mailing list > > > > > > > > > > > siprec@ietf.org > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > siprec mailing list > > > > > > > > > > siprec@ietf.org > > > > > > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > siprec mailing list > > > > > > > siprec@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > > > _______________________________________________ > > > > siprec mailing list > > > > siprec@ietf.org > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > _______________________________________________ > > > > siprec mailing list > > > > siprec@ietf.org > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > _______________________________________________ > > > siprec mailing list > > > siprec@ietf.org > > > https://www.ietf.org/mailman/listinfo/siprec > > From eckelcu@cisco.com Fri Apr 15 12:38:45 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 51851E0713 for ; Fri, 15 Apr 2011 12:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.199 X-Spam-Level: X-Spam-Status: No, score=-9.199 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 724p+DG9L330 for ; Fri, 15 Apr 2011 12:38:40 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfc.amsl.com (Postfix) with ESMTP id 0C3C1E0682 for ; Fri, 15 Apr 2011 12:38:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=37056; q=dns/txt; s=iport; t=1302896320; x=1304105920; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=Vv/frxwmCIoWWSX//sacweGSojoSKmpl5kZ8Sme2chM=; b=DuYxj1/YRtt/1oezQDaveLapz3P0LhqL8fM4hwrxhUQ3lQFxFMy3RJES zLy3pw4bt+R+R3yk35BDyn3S73W8DYp1s0srNf6026Jf3x46zn5xCP7jC Sz4Lj4GYBWFAFb4FpqvkcIbdiFbh2QdwAVvIffaf+pUZAc0ovYkfZwz4O 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIBAL+dqE2rRDoJ/2dsb2JhbACYCo1/d6dqnQ+Cf4JvBIVgjBM X-IronPort-AV: E=Sophos;i="4.64,220,1301875200"; d="scan'208";a="682441803" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-6.cisco.com with ESMTP; 15 Apr 2011 19:38:39 +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 p3FJcdlF030482; Fri, 15 Apr 2011 19:38:39 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, 15 Apr 2011 12:38:39 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: AWs6 B+OU ECQa EowH FUye GaF1 Geei GjQt Gpqj HuIf KzFc K3/V LAf6 NHlk RYnp Sx1B; 2; agBvAGgAbgAuAGUAbAB3AGUAbABsAEAAcwBpAGUAbQBlAG4AcwAtAGUAbgB0AGUAcgBwAHIAaQBzAGUALgBjAG8AbQA7AHMAaQBwAHIAZQBjAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {5B5804F5-7DB3-4190-9269-344135EB609F}; ZQBjAGsAZQBsAGMAdQBAAGMAaQBzAGMAbwAuAGMAbwBtAA==; Fri, 15 Apr 2011 19:38:29 GMT; UgBFADoAIABbAHMAaQBwAHIAZQBjAF0AIABGAFcAOgAgAEQAbwAgAHcAZQAgAG4AZQBlAGQAIAB0AG8AIABtAG8AZABlAGwAIABwAGEAcgB0AGkAYwBpAHAAYQBuAHQAcwAgAG4AbwB0ACAAcABhAHIAdAAgAG8AZgBDAFMAIABiAHUAdABhAHMAcwBvAGMAaQBhAHQAZQBkACAAdwBpAHQAaAAgAE0AZQBkAGkAYQAgAFMAdAByAGUAYQBtACAAYgBsAG8AYwBrACAAaQBuACAAdABoAGUAIABtAGUAdABhAGQAYQB0AGEAbQBvAGQAZQBsACAAPwAJACgAdwBhAHMAIABSAEUAOgAgAFAAYQByAHQAaQBhAGwAIAB1AHAAZABhAHQAZQBzACAAYQBuAGQAIABpAGQAZQBuAHQAaQBmAGkAZQByAHMAKQA= MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {5B5804F5-7DB3-4190-9269-344135EB609F} Content-class: urn:content-classes:message Date: Fri, 15 Apr 2011 12:38:29 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] FW: Do we need to model participants not part ofCS butassociated with Media Stream block in the metadatamodel ? (was RE: Partial updates and identifiers) Thread-Index: Acv0jVXI4ji2YTo+SquJ6T6YR3i+lQAdOkDgAEETmvAAg54qsAADKDEgAADSn+AAEAO1UAANZylQABBzW2AABHtBwACZNyqAAAGC+nAAAd/QMAAHC/qgAADkBPAACObIgA== References: <35BCE99A477D6A4986FB2216D8CF2CFD061331FF@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD061332DC@XMB-BGL-417.cisco.com> From: "Charles Eckel (eckelcu)" To: "Elwell, John" , "Ram Mohan R (rmohanr)" , "Parthasarathi R (partr)" , X-OriginalArrivalTime: 15 Apr 2011 19:38:39.0110 (UTC) FILETIME=[B80A9260:01CBFBA4] Subject: Re: [siprec] FW: Do we need to model participants not part ofCS butassociated with Media Stream block in the metadatamodel ? (was RE: Partial updates and identifiers) X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 15 Apr 2011 19:38:45 -0000 I do not see a need to distinguish participant "types". Whether or not a 3pcc participant is considered a participant is, I think, an implementation preference. If the SRS knows something is a 3pcc, it might choose to not tell the SRS about it. But then again, it may not know, so it may well the SRS in that case. Also, a participant my initially not send an media, and my start sending media later, or vice versa. I think this is all fine and should not require any modification of the participant information conveyed by the SRS to the SRS. Cheers, Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > Sent: Friday, April 15, 2011 8:27 AM > To: Ram Mohan R (rmohanr); Parthasarathi R (partr); siprec@ietf.org > Subject: Re: [siprec] FW: Do we need to model participants not part ofCS butassociated with Media > Stream block in the metadatamodel ? (was RE: Partial updates and identifiers) >=20 >=20 >=20 > > -----Original Message----- > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > Sent: 15 April 2011 16:04 > > To: Parthasarathi R (partr); Elwell, John; siprec@ietf.org > > Subject: RE: [siprec] FW: Do we need to model participants > > not part ofCS butassociated with Media Stream block in the > > metadatamodel ? (was RE: Partial updates and identifiers) > > > > I am ok with associating participants behind a UA [ for case > > where UA is > > capable of learning them] in CS as part of that CS in the > > model/format. > > One question I have is, Do we need to distinguish these participants > > from the others by having some attributes as part of > > participant block? > > Or is it sufficient if we just treat them as any other participants of > > CS. > [JRE] We could treat them as other Participants, but if we don't have information about the media they > are sending receiving and therefore all media is seen by the SRC as being sent/received by the > conference UA, then I don't really see it makes sense to treat them as separate Participant objects. >=20 > > > > There are three categories of participants: > > Participants who contribute both signaling and media to CS > > Participants who contribute only media in the CS [ like the > > below case] > > Participants who contribute only signaling to CS [e.g. 3pcc > > controller] > [JRE] I don't think this distinction is particularly relevant to what gets sent to the SRS, stored, > and subsequently played back. The information that really needs to be captured is which participants > send/receive which media, and signalling. Signalling is just part of the CS mechanism that has no > relevance to what gets recorded and played back. I don't see why a 3PCC controller would be considered > a Participant. >=20 > John (as individual) >=20 > > > > Ram > > > > > -----Original Message----- > > > From: Parthasarathi R (partr) > > > Sent: Friday, April 15, 2011 5:28 PM > > > To: Elwell, John; Ram Mohan R (rmohanr); siprec@ietf.org > > > Subject: RE: [siprec] FW: Do we need to model participants not part > > > ofCS butassociated with Media Stream block in the > > metadatamodel ? (was > > > RE: Partial updates and identifiers) > > > > > > John point of view looks reasonable to me because CS is not directly > > > associated with dialogs but instead it represents session with the > > list > > > of participant involved in it. > > > > > > In case of participant list received through conference > > package to SRC > > > with UA, those multiple participants from focus shall be represented > > as > > > individual participant block who are pointed to single mixed media > > > stream metadata block and all participant belongs within single > > > conference CS in this scenario. The model is as follows > > (part in the > > > diagram represents participant): > > > > > > > > > RS > > > | > > > CS------------------------------- > > > | | > > > ----------------------- part5(SRC) > > > | | | | | > > > | | | | media stream2 > > > part1 part2 part3 part4 > > > | | | | > > > ------------------------- > > > | > > > Media stream1 > > > > > > Thanks > > > Partha > > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > > Behalf Of Elwell, John > > > Sent: Friday, April 15, 2011 4:34 PM > > > To: Ram Mohan R (rmohanr); siprec@ietf.org > > > Subject: Re: [siprec] FW: Do we need to model participants not part > > > ofCS butassociated with Media Stream block in the > > metadatamodel ? (was > > > RE: Partial updates and identifiers) > > > > > > As an individual, my opinion, which I have pretty much > > stated before, > > > is that a participant must always be part of a CS. A couple of > > > situations have been mentioned where alternatives might be required, > > > but I don't believe so. > > > > > > 1. Conferences. I think depending what view the SRC has of the CS, > > > there are two situations: > > > > > > (a) The SRC sees all parties in the conference and has visibility of > > > what Media Streams each party sends and receives. In this case, I > > think > > > the whole conference can be modelled as a CS and each party can be > > > modelled as a Participant in that CS. Such a view will typically be > > > feasible when the SRC is located at a conference > > focus/mixer (e.g., an > > > MCU). > > > > > > (b) The SRC sees the conference focus mixer as a party but > > has limited > > > information about parties behind the focus/mixer. In this > > case I think > > > the SRC can regard the CS as terminating at the conference > > > (focus/mixer), with the conference a Participant in that CS. > > > Information about parties behind the conference may or may not be > > > available, in which case they can be additional attributes of the > > > conference Participant object. One typical case will be > > where the SRC > > > is located at a UA of one of the conference parties, or at a B2BUA > > > between the focus/mixer and a party UA. In that case the CS > > would have > > > two Participants: the party concerned and the conference. Am extreme > > > case is where the conference is the sole Participant and > > just records > > > Media Streams sent by the conference to parties in the conference. > > > > > > Hybrid situations can occur, e.g., for cascaded conferences, where > > > participants at one conference are modelled as Participants > > but other > > > conferences are just modelled each as a single Participant. > > > > > > 2. IVR and similar. I would model the Media Server as a > > Participant in > > > the CS, i.e., there is a CS between the Media Server and the caller. > > > > > > John > > > > > > > -----Original Message----- > > > > From: siprec-bounces@ietf.org > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Ram Mohan R > > (rmohanr) > > > > Sent: 15 April 2011 10:56 > > > > To: siprec@ietf.org > > > > Subject: [siprec] FW: Do we need to model participants not part of > > CS > > > > butassociated with Media Stream block in the metadata model ? (was > > > RE: > > > > Partial updates and identifiers) > > > > > > > > I request people to provide inputs on this and help to > > take it to a > > > > closure. This issue has been open for several months now. > > > > > > > > Ram > > > > > > > > -----Original Message----- > > > > From: siprec-bounces@ietf.org > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Ram Mohan R > > (rmohanr) > > > > Sent: Tuesday, April 12, 2011 3:04 PM > > > > To: Elwell, John; Charles Eckel (eckelcu); Parthasarathi > > R (partr); > > > > Paul Kyzivat (pkyzivat); siprec@ietf.org > > > > Cc: Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr) > > > > Subject: [siprec] Do we need to model participants not part of CS > > but > > > > associated with Media Stream block in the metadata model > > ? (was RE: > > > > Partial updates and identifiers) > > > > > > > > Renaming the mail thread to discussion to this specific issue - > > > > "Metadata for participants not part of CS" which we have been > > > > discussing from several weeks. > > > > > > > > Please continue the other issues in original thread and lets use > > this > > > > thread to close this issue. I would request people to give inputs > > for > > > > this issue on this thread and take it to a conclusion. > > > > > > > > We(Authors of Metadata model) included participants that are not > > part > > > > of CS to imply: > > > > - Participants that does NOT contribute to signaling in CS but > > > > contributes to media The intent is to give more flexibility in the > > > > metamodel to represent these types of participants. > > > > > > > > Following are some of use case where this can happen- > > > > > > > > Use-Case 1: A conference where one of the participants is > > a SRC. In > > > > these case the Focus which talks to this SRC becomes part of CS > > > > contributing signaling as well as media. However the > > media includes > > > > media from other participants that are not part of CS. Please note > > > SRC > > > > has to subscribe to conf event packet to get this > > information (which > > > > may not be always feasible). > > > > > > > > Use-Case 2: one UA in CS works in 3pcc mode to acquire an > > MoH media > > > > stream, this might be reflected as unique source for media stream > > > > without having a reported signaling relationship to it. E.g is > > > given > > > > here by Henry Lum > > > > http://www.ietf.org/mail-archive/web/siprec/current/msg01372.html > > > > > > > > In some sense these participants are *still* part of CS as they > > > > contribute to CS media. > > > > > > > > There are three approaches I can see- > > > > Don't model the participants that does not contribute signaling in > > CS > > > > and only contribute Media Model these participants as not > > part of CS > > > > in the model but associated with Media Stream block ( current > > > > approach) Model these participants to be associated with > > CS but have > > > > the association labeled as "indirect participant" > > > > > > > > Let me know your thoughts. > > > > > > > > Thanks, > > > > Ram > > > > > > > > > -----Original Message----- > > > > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On > > > > > Behalf Of Elwell, John > > > > > Sent: Tuesday, April 12, 2011 12:13 PM > > > > > To: Charles Eckel (eckelcu); Parthasarathi R (partr); > > Paul Kyzivat > > > > > (pkyzivat); siprec@ietf.org > > > > > Cc: Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr) > > > > > Subject: Re: [siprec] Partial updates and identifiers > > > > > > > > > > I think the attached message was the last in that thread. So I > > > don't > > > > > really think we had closure. > > > > > > > > > > John > > > > > > > > > > > -----Original Message----- > > > > > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > > > > Sent: 11 April 2011 23:53 > > > > > > To: Elwell, John; Parthasarathi R (partr); Paul Kyzivat > > > > (pkyzivat); > > > > > > siprec@ietf.org > > > > > > Cc: Peter Saint-Andre (psaintan); Joe Hildebrand > > > > (jhildebr); Hadriel > > > > > > Kaplan > > > > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > > > > > > > Hi John, > > > > > > > > > > > > I have attached the last e-mail I have from the > > thread in which > > I > > > > > > first raised this issue. Unfortunately, I do not have > > the e-mail > > > > with > > > > > > the ultimate agreement, but maybe someone else does > > or this will > > > > help > > > > > > prompt some memories. > > > > > > > > > > > > Cheers, > > > > > > Charles > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: siprec-bounces@ietf.org > > > > [mailto:siprec-bounces@ietf.org] On > > > > > > Behalf Of Elwell, John > > > > > > > Sent: Monday, April 11, 2011 9:46 AM > > > > > > > To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); > > > > > > siprec@ietf.org > > > > > > > Cc: Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr); > > > > > Hadriel > > > > > > Kaplan > > > > > > > Subject: Re: [siprec] Partial updates and identifiers > > > > > > > > > > > > > > Partha, > > > > > > > > > > > > > > Thanks for reminding me - I now recall the discussion some > > > > > > weeks/months ago about the participants > > > > > > > obtained from the conference event package. I was never > > > > > particularly > > > > > > comfortable with the fact these > > > > > > > were not considered part of the CS. While that might be > > > > > > correct if we > > > > > > consider the CS to be the SIP > > > > > > > dialog between the SRC and the conference focus, taking a > > > > > > broader view > > > > > > of CS those participants behind > > > > > > > the focus could be considered part of the CS. I don't > > > > particularly > > > > > > want to open up the old discussion > > > > > > > if people are happy with what we have, but something > > > > doesn't seem > > > > > > quite right to me. > > > > > > > > > > > > > > For example, if these "participants" are not considered part > > of > > > > the > > > > > > CS, and if we don't have specific > > > > > > > information about their involvement in media > > streams, do they > > > > > really > > > > > > merit being considered > > > > > > > Participant objects? > > > > > > > > > > > > > > In other words, two possible approaches are: > > > > > > > > > > > > > > 1) The CS extends only as far as the focus / mixer. The > > > > > > focus/mixer is > > > > > > a "Participant" and the users > > > > > > > behind the focus are not separate Participants but are just > > > > > > additional > > > > > > data associated with the > > > > > > > focus/mixer Participant. The only Media Streams we are > > > > > > concerned with > > > > > > are between the mixer and the > > > > > > > SRC. > > > > > > > > > > > > > > 2) The CS extends beyond the focus/mixer to users > > > > learned via the > > > > > > conference event package, each of > > > > > > > those users is a separate Participant object, and we > > > > are concerned > > > > > > with Media Stream objects that > > > > > > > those participants send and receive. I am not sure how > > feasible > > > > > this > > > > > > approach is, because I am not > > > > > > > sure that the SRC can obtain enough information about media > > > > > > streams at > > > > > > users behind the focus/mixer. > > > > > > > > > > > > > > It seems the present solution is somewhere between the > > > > two, which > > > > > is > > > > > > why I am uncomfortable. > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > John (as individual) > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > > > > > Sent: 11 April 2011 10:29 > > > > > > > > To: Elwell, John; Paul Kyzivat (pkyzivat); siprec@ietf.org > > > > > > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe > > > > Hildebrand > > > > > > > > (jhildebr) > > > > > > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > > > > > > > > > > > John, > > > > > > > > > > > > > > > > Please read inline. > > > > > > > > > > > > > > > > Thanks > > > > > > > > Partha > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Elwell, John [mailto:john.elwell@siemens- > > > enterprise.com] > > > > > > > > Sent: Monday, April 11, 2011 2:11 PM > > > > > > > > To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); > > > > > > siprec@ietf.org > > > > > > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe > > > > Hildebrand > > > > > > > > (jhildebr) > > > > > > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > > > > > > Sent: 11 April 2011 08:35 > > > > > > > > > To: Elwell, John; Paul Kyzivat (pkyzivat); > > siprec@ietf.org > > > > > > > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe > > > > > Hildebrand > > > > > > > > > (jhildebr) > > > > > > > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > > > > > > > > > > > > > John, > > > > > > > > > > > > > > > > > > As I mentioned below, stream block will be unique > > > > > > within CS, (not > > > > > > > > > required to be unique across multiple CS) and so, xml:id > > or > > > > > > > > enhancing > > > > > > > > > the normative statement of RFC 4574 label > > attribute to be > > > > > unique > > > > > > > > > within CS will serve the purpose. I'm fine with > > any of the > > > > > above > > > > > > > > > mentioned id. > > > > > > > > > Please note that RFC 4574 "label" attribute is > > the nature > > > > > > > > data for RS > > > > > > > > > dialog. > > > > > > > > > > > > > > > > > > In case participant within CS, xml:id will serve the > > > purpose > > > > > but > > > > > > we > > > > > > > > > need to get more clarity about participants who are not > > > > > > > > part of CS but > > > > > > > > > > > > > > > > > within RS. > > > > > > > > [JRE] If I understand the figure in section 3 of > > metadata-04 > > > > > > > > correctly, a Participant can have a relationship with > > > > a CS, but > > > > > no > > > > > > > > direct relationship with an RS. > > > > > > > > > > > > > > > > Sorry, I mixed up my statement with the latest > > > update > > > > of > > > > > > > > making CSG optional. As per Sec 3 of metadata-04, > > participant > > > > has > > > > > > > > direct relationship with CSG in case CS is left completely > > > > > > > > unattached. In case CSG is optional, then participant > > > > will have > > > > > > > > direct relationship with RS in case there is no > > relationship > > > > > > > > between CS and participant. > > > > > > > > > > > > > > > > > > > > > > > > So a participant that does not have a relationship > > > > with a CS is > > > > > > left > > > > > > > > completely unattached, unless it has a relationship > > > > with a Media > > > > > > > > Stream (which always has a relationship with a CS). So to > > > > > > > > summarize: > > > > > > > > - a Participant can have a direct relationship > > with a CS; or > > > > > > > > - a Participant can have an indirect relationship > > > > with a CS (via > > > > > a > > > > > > > > Media Stream); agreed > > > > > > > > - a Participant can have no relationship with a CS, and > > > > > > therefore no > > > > > > > > relationship with an RS. > > > > > > > > Do we really need this last case? > > > > > > > > > > > > > > > > I'm happy if the last case is not > > required because > > > it > > > > > > > > simplify the solution and there is no need of > > unique id for > > > > > > > > participant. But SRS implementers may prefer to have > > > > relationship > > > > > > > > with participant and RS. I wish more opinion before taking > > > > > > > > decision whether to remove the last case > > > > > > > > > > > > > > > > > Because CS may span across different RS how about the > > > > > > > > participant who > > > > > > > > > are not part of CS? > > > > > > > > [JRE] I don't understand the words "Because CS may span > > > across > > > > > > > > different RS", because in the rest of the sentence you are > > > > > talking > > > > > > > > about a Participant that is not part of a CS. > > > > > > > > > > > > > > > > > Ex: One of the user in the conference acts as SRC, fetch > > > > > > > > participant > > > > > > > > > info using conferene package and new RS is created > > > > > > during initial > > > > > > > > > conference creation and hold&resume of a user within CS. > > > > > > > > [JRE] I am not sure what you are trying to say > > here. I would > > > > > > > > consider a user whose identity is obtained via a > > conference > > > > event > > > > > > > > package as being part of the CS. > > > > > > > > > > > > > > > > I'm trying to give the example where > > > > participant is not > > > > > > > > associated with CS directly but related to CSG (/RS). This > > > > > > > > scenario was considered as a blocking in -03 version of > > > > metadata. > > > > > > > > I'm not arguing to have this scenario but it is major > > concern > > > > for > > > > > > > > few folks. > > > > > > > > > > > > > > > > CS is between focus and UA, UA acts as SRC, UA > > receives the > > > > > > > > participant info via conference event package but those > > > > > > > > participants are not related in CS directly (and > > only focus > > > is > > > > > > > > related) but they contributed for the mixed stream. > > > > > > > > > > > > > > > > > > That user is sending/receiving Media Streams that > > > > are part of a > > > > > > > > CS, or if it isn't sending/receiving Media Streams, > > > > what is the > > > > > > > > relevance > > > > > > of > > > > > > > > that Participant? > > > > > > > > > > > > > > > > Mixed media stream from focus to UA > > belongs to the > > > > > > Conference > > > > > > > > event package participants. There participant are not > > > directly > > > > > > > > involved as part of CS. Why would we > > > > create a new RS > > > > > > > > for such a participant? > > > > > > > > RS is not created for participant. Multiple > > > > RS shall be > > > > > > > > created the same CS during the different time > > frame as shown > > > > > below > > > > > > > > > > > > > > > > <-------------------CS1-------------> > > > > > > > > <---RS1--> <---RS2------> > > > > > > > > > > > > > > > > CS1 is between UA (SRC) and focus whereas RS1, RS2 is > > > > between UA > > > > > > (SRC) > > > > > > > > and SRS. Here tangling (conference event package) > > participant > > > > has > > > > > > > > to be grouped together in RS1, RS2 by some means through > > > given > > > > > > > > metadata. > > > > > > The > > > > > > > > question whether this corner has to be solved ? > > > > > > > > > > > > > > > > John (as individual) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > Partha > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Elwell, John > > > > [mailto:john.elwell@siemens-enterprise.com] > > > > > > > > > Sent: Friday, April 08, 2011 9:36 PM > > > > > > > > > To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); > > > > > > > > siprec@ietf.org > > > > > > > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe > > > > > Hildebrand > > > > > > > > > (jhildebr) > > > > > > > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > > > > > > > > > > > > > Focusing just on participant and stream for the time > > being, > > > > > > > > do these > > > > > > > > > need to be unique across multiple CSs or not? > > > > > > > > > > > > > > > > > > John > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > > > > > > > Sent: 07 April 2011 10:51 > > > > > > > > > > To: Paul Kyzivat (pkyzivat); siprec@ietf.org; Elwell, > > > John > > > > > > > > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe > > > > > > Hildebrand > > > > > > > > > > (jhildebr) > > > > > > > > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > > > > > > > > > > > > > > > John, > > > > > > > > > > > > > > > > > > > > Sorry for the lengthy mail but it contains lot of > > > analysis > > > > > and > > > > > > > > > > reasoning for this id approach. > > > > > > > > > > > > > > > > > > > > Adding to Paul's point, I wish to give more background > > > and > > > > > > > > > reason for > > > > > > > > > > these globally unique id. Initially I had the > > impression > > > > that > > > > > > the > > > > > > > > > > single unique id (RS dialog-id) in the recording > > (session > > > > > > > > > level) and > > > > > > > > > > some relevant natural id for the rest of the element > > will > > > > > > > > serve the > > > > > > > > > > purpose. > > > > > > > > > > There are usecases where this assumption fails. > > > > Even I have > > > > > > > > > thought of > > > > > > > > > > > > > > > > > > > using "xml:id" instead of URN UUID to avoid long > > > > string but > > > > > > > > > xml:id may > > > > > > > > > > > > > > > > > > > not end up with unique value always. Our analysis for > > URN > > > > > > > > UUID for > > > > > > > > > > each level is as follows and please provide your input > > in > > > > > case > > > > > > id > > > > > > > > > > shall be > > > > > > > > > > tweaked: > > > > > > > > > > > > > > > > > > > > 1) Recording block: The reason for globally > > unique id is > > > > > > > > > that multiple > > > > > > > > > > > > > > > > > > > SRC with same id to single SRS. > > > > > > > > > > > > > > > > > > > > Topology: > > > > > > > > > > > > > > > > > > > > SRC1 SRC2 > > > > > > > > > > | | > > > > > > > > > > | ----(RS1-ID1)-----SRS1 > > > > > > > > > > | > > > > > > > > > > ---(RS2-ID1)------------------SRS1 > > > > > > > > > > > > > > > > > > > > In the above topology, it is possible for ID1 is > > > generated > > > > by > > > > > > both > > > > > > > > > > SRC1 and SRC2 at the same time. > > > > > > > > > > > > > > > > > > > > 2) group (CSG) block: Grouping mechanism (Hadriel > > > > > > > > session-id, Paul > > > > > > > > > > Jones > > > > > > > > > > Session-UUID) is outside the scope of SIPREC. URN UUID > > > > > > > > > abstracts the > > > > > > > > > > exact mechanism to SRS and provides the > > information only > > > > > > > > about the > > > > > > > > > > group of CS from SRC perspective. It possible > > > > that group may > > > > > > span > > > > > > > > > > across multiple RS and It is up to SRS to > > group and view > > > > > > > > as single > > > > > > > > > > recording. > > > > > > > > > > Here, the single level id in the top will fail. > > > > The counter > > > > > > > > > argument > > > > > > > > > > is to force the single RS having complete CSG but > > > > > > it*may not* be > > > > > > > > > > possible in SRC implementation. Here, xml:id will not > > > > > > serve the > > > > > > > > > > purpose > > > > > > > > > > > > > > > > > > > > 3) session (CS) block: At the immediate look, session > > > > > > > > falls exactly > > > > > > > > > > under recording block. Use case 3 of > > > > draft-ietf-siprec-req-09 > > > > > > > > > > illustrates where CS span across multiple RS. This > > > > > > > > > requirement calls > > > > > > > > > > for unique id in session by which these > > session shall be > > > > > > > > viewed as > > > > > > > > > > single CS even though there is no group exists among > > > > > > > > them. IMO, in > > > > > > > > > > case session should not have globally unique id, > > > > then it is > > > > > > > > > preferred > > > > > > > > > > to remove usecase 3 in the requirement. > > > > > > > > > > > > > > > > > > > > 4) participant block: It needs some id which may > > > > be AOR but > > > > > > > > > AOR is not > > > > > > > > > > > > > > > > > > > unique. IMO, xml:id may serve the purpose with session > > > > > > > > > unique id. The > > > > > > > > > > trick exists for participant who are not > > associated with > > > > > > > > > CS. We shall > > > > > > > > > > discuss and fine tune if required. > > > > > > > > > > > > > > > > > > > > 5) stream block: Label attribute shall be > > used as unique > > > > > > > > > value but RFC > > > > > > > > > > 4574 does not mandate label attribute has to be unique > > > > across > > > > > > the > > > > > > > > > > dialog or CS and so, it may possible to change within > > > > > > RS and no > > > > > > > > > > normative statement to stop this implementation. IMO, > > > > > > > > > xml:id may serve > > > > > > > > > > > > > > > > > > > the purpose with session unique id. Here as well, We > > > shall > > > > > > > > > discuss and > > > > > > > > > > > > > > > > > > > fine tune if required. > > > > > > > > > > > > > > > > > > > > 6) extensiondata block: This is tracked in > > the separate > > > > > > > > mail thread > > > > > > > > > > whether unique id is required or not. Let us > > close this > > > > > > > > as part of > > > > > > > > > > that mail thread. > > > > > > > > > > > > > > > > > > > > Including explicitly Hadriel, Peter, Joe in this mail > > > > > > > > > thread as they > > > > > > > > > > have different view on this ID mechanism. > > > > > > > > > > > > > > > > > > > > I had offline discussion with Hadriel in Prague after > > > > > > > > > SIPREC meeting > > > > > > > > > > and my understanding of his major concern is that how > > SRS > > > > > > > > > will be able > > > > > > > > > > > > > > > > > > > to design the database in case partial update > > > > does not have > > > > > > > > > recording > > > > > > > > > > (top) id information. I'll put more thought > > > > > > processing to close > > > > > > > > > > Hadriel concern of how top id has to be > > tracked in case > > > > > > > > > partial update > > > > > > > > > > > > > > > > > > > by which SRS implementation will be > > simplified in terms > > > of > > > > > > > > > aggregation > > > > > > > > > > > > > > > > > > > maintenance. > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > Partha > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: siprec-bounces@ietf.org > > > > > > > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul > > > Kyzivat > > > > > > > > > (pkyzivat) > > > > > > > > > > Sent: Thursday, April 07, 2011 12:33 AM > > > > > > > > > > To: siprec@ietf.org > > > > > > > > > > Subject: Re: [siprec] Partial updates and identifiers > > > > > > > > > > > > > > > > > > > > John, > > > > > > > > > > > > > > > > > > > > For the moment we have proposed that the ids be > > > > conveyed in > > > > > > > > > the form > > > > > > > > > > of URIs that are globally unique, and > > specifically that > > > > > > > > > they be UUID > > > > > > > > > > URNs. > > > > > > > > > > There is no dependency on the particular form of the > > URI, > > > > but > > > > > > > > > > specifying they must be UUID URNs makes it possible to > > > > > > > > perform some > > > > > > > > > > internal optimizations for storage. > > > > > > > > > > > > > > > > > > > > The UUID URN is a pretty inefficient encoding. A UUID > > can > > > > > > > > > be expressed > > > > > > > > > > > > > > > > > > > in 32 bits, so we could consider retaining UUIDs but > > > alter > > > > > the > > > > > > > > > > encoding if its really an issue. However I am far from > > > > > > > > > convinced that > > > > > > > > > > the size of the IDs is going to be a major > > issue in the > > > > > > > > > overall size > > > > > > > > > > of messages, so I think its probably > > premature to worry > > > > about > > > > > > it. > > > > > > > > > > > > > > > > > > > > Because the ids can be expressed in 32 bits, > > the SRC and > > > > > > > > > SRS can store > > > > > > > > > > > > > > > > > > > them internally that way, thus reducing the > > > > runtime cost of > > > > > > > > > > maintaining the data. > > > > > > > > > > > > > > > > > > > > The use of unique ids is a significant part of the > > > overall > > > > > > > > > approach to > > > > > > > > > > > > > > > > > > > formatting updates. If somebody has a > > different concept > > > > > > > > in mind it > > > > > > > > > > could be useful to have an alternative > > proposal for the > > > > > > > > > format. If we > > > > > > > > > > had two worked out approaches we could compare the > > > > > > > > > tradeoffs in each. > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > Paul > > > > > > > > > > > > > > > > > > > > On 4/6/2011 10:24 AM, Elwell, John wrote: > > > > > > > > > > > Much of the discussion on draft-ram-metadata-format > > > > > > in Prague > > > > > > > > > > concerned the mechanism for performing partial updates > > > and > > > > > > > > > the use of > > > > > > > > > > identifiers. The draft permits partial updates by > > > allowing > > > > > > > > > individual > > > > > > > > > > objects (e.g., CS, participant, media stream) > > to be sent > > > > > > > > > with updated > > > > > > > > > > content, without having to send again other > > objects that > > > > have > > > > > > not > > > > > > > > > > changed. So, for example, in a large conference, it > > would > > > > > > > > > be possible > > > > > > > > > > to add or modify an individual participant object > > without > > > > > > > > having to > > > > > > > > > > send all the other participant objects again. I do not > > > > recall > > > > > > any > > > > > > > > > > opposition to this basic principle. > > > > > > > > > > > > > > > > > > > > > > However, to achieve this, every object requires an > > > > > > > > > > identifier, and it > > > > > > > > > > was asserted that these identifiers need to > > be globally > > > > > > > > > unique for all > > > > > > > > > > > > > > > > > > > time. Although this might be efficient for updating an > > > > > > individual > > > > > > > > > > object, when sending many objects (e.g., at > > the start of > > > a > > > > > > > > > CS or when > > > > > > > > > > refreshing the entire metadata), this can make the > > > > > > metadata very > > > > > > > > > > bulky. > > > > > > > > > > It depends, of course, on the format of the > > identifiers, > > > > > > > > and it was > > > > > > > > > > stated that there could be alternatives to UUID. > > > > > > > > Nevertheless, some > > > > > > > > > > people had concerns. These concerns also > > extended to the > > > > > > > > > impact on the > > > > > > > > > > > > > > > > > > > database where metadata is stored, since it > > might not be > > > > > > > > > feasible to > > > > > > > > > > convert to a database-friendly mechanism for linking > > > > > > > > > objects together. > > > > > > > > > > > > > > > > > > > > > > One alternative proposal during the meeting was > > > > to have a > > > > > > single > > > > > > > > > > unique identifier at the top level (for the > > RS) and use > > > > local > > > > > > > > > > identifiers for other objects. Thus when updating a > > > single > > > > > > > > > object, it > > > > > > > > > > would be necessary to include the top level identifier > > as > > > > > > > > > well as one > > > > > > > > > > or more local identifiers. However, there were > > > > also concerns > > > > > > this > > > > > > > > > > might not fulfil actual or perceived future > > requirements. > > > > > > > > > > > > > > > > > > > > > > Please continue discussion on this. > > > > > > > > > > > > > > > > > > > > > > John (as chair) > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > siprec mailing list > > > > > > > > > > > siprec@ietf.org > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > siprec mailing list > > > > > > > > > > siprec@ietf.org > > > > > > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > siprec mailing 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 Sun Apr 17 23:46:28 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E177DE0758 for ; Sun, 17 Apr 2011 23:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.953 X-Spam-Level: X-Spam-Status: No, score=-104.953 tagged_above=-999 required=5 tests=[AWL=1.646, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yzUe9n06pv-v for ; Sun, 17 Apr 2011 23:46:28 -0700 (PDT) Received: from mail182.messagelabs.com (mail182.messagelabs.com [85.158.139.83]) by ietfc.amsl.com (Postfix) with SMTP id CE50BE06C4 for ; Sun, 17 Apr 2011 23:46:27 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-12.tower-182.messagelabs.com!1303109186!5062965!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 27359 invoked from network); 18 Apr 2011 06:46:26 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-12.tower-182.messagelabs.com with SMTP; 18 Apr 2011 06:46:26 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 854E723F037F; Mon, 18 Apr 2011 08:46:26 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Mon, 18 Apr 2011 08:46:26 +0200 From: "Elwell, John" To: "Ram Mohan R (rmohanr)" , "Parthasarathi R (partr)" , "siprec@ietf.org" Date: Mon, 18 Apr 2011 08:46:25 +0200 Thread-Topic: [siprec] FW: Do we need to model participants not part ofCS butassociated with Media Stream block in the metadatamodel ? Thread-Index: Acv0jVXI4ji2YTo+SquJ6T6YR3i+lQAdOkDgAEETmvAAg54qsAADKDEgAADSn+AAEAO1UAANZylQABBzW2AABHtBwACZNyqAAAGC+nAAAd/QMAAHC/qgAADkBPAAAwwR4ACBrXAA Message-ID: References: <35BCE99A477D6A4986FB2216D8CF2CFD061331FF@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD061332DC@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD0613330A@XMB-BGL-417.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD0613330A@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] FW: Do we need to model participants not part ofCS butassociated with Media Stream block in the metadatamodel ? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 06:46:29 -0000 =20 > -----Original Message----- > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com]=20 > Sent: 15 April 2011 17:54 > To: Elwell, John; Parthasarathi R (partr); siprec@ietf.org > Subject: RE: [siprec] FW: Do we need to model participants=20 > not part ofCS butassociated with Media Stream block in the=20 > metadatamodel ? (was RE: Partial updates and identifiers) >=20 > Hi John, Please see inline >=20 > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Friday, April 15, 2011 8:57 PM > > To: Ram Mohan R (rmohanr); Parthasarathi R (partr); siprec@ietf.org > > Subject: RE: [siprec] FW: Do we need to model participants not part > > ofCS butassociated with Media Stream block in the=20 > metadatamodel ? (was > > RE: Partial updates and identifiers) > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > > Sent: 15 April 2011 16:04 > > > To: Parthasarathi R (partr); Elwell, John; siprec@ietf.org > > > Subject: RE: [siprec] FW: Do we need to model participants > > > not part ofCS butassociated with Media Stream block in the > > > metadatamodel ? (was RE: Partial updates and identifiers) > > > > > > I am ok with associating participants behind a UA [ for case > > > where UA is > > > capable of learning them] in CS as part of that CS in the > > > model/format. > > > One question I have is, Do we need to distinguish these=20 > participants > > > from the others by having some attributes as part of > > > participant block? > > > Or is it sufficient if we just treat them as any other=20 > participants > > of > > > CS. > > [JRE] We could treat them as other Participants, but if we=20 > don't have > > information about the media they are sending receiving and therefore > > all media is seen by the SRC as being sent/received by the=20 > conference > > UA, then I don't really see it makes sense to treat them as separate > > Participant objects. >=20 > Yes I agree with you. My thought here is for cases where the=20 > conference > UA can learn the other participants, we can convey them as separate > participant objects in the model, of course all of them will be > associated ("sends" association) with the same mixed stream. > For cases where conference UA cannot determine, we will have only one > participant object ( i.e. conference UA) conveyed in the model >=20 > I hope this would be sufficient for most use cases. [JRE] But in this case, even though the UA has learned the identities of ot= her parties behind the conference focus, it doesn't know which of these par= ties are really contributing to media received by the UA and which of these= parties actually receive media sent by the UA. Also the UA does not know w= hat media is exchanged between those other parties. Therefore treating them= as Participants is, I think, misleading. I agree we should try to include = the identities of these other parties, but it seems to make more sense to i= nclude them as attributes of the Participant representing the conference. John (as individual) From john.elwell@siemens-enterprise.com Sun Apr 17 23:49:33 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1F47EE0655 for ; Sun, 17 Apr 2011 23:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.977 X-Spam-Level: X-Spam-Status: No, score=-104.977 tagged_above=-999 required=5 tests=[AWL=1.622, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YLGxGK+8CuVZ for ; Sun, 17 Apr 2011 23:49:28 -0700 (PDT) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfc.amsl.com (Postfix) with SMTP id 94EA4E0766 for ; Sun, 17 Apr 2011 23:49:28 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1303109365!20041948!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 27410 invoked from network); 18 Apr 2011 06:49:25 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-11.tower-27.messagelabs.com with SMTP; 18 Apr 2011 06:49:25 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 844791EB83F0; Mon, 18 Apr 2011 08:49:27 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 18 Apr 2011 08:49:27 +0200 From: "Elwell, John" To: Paul Kyzivat , "siprec@ietf.org" Date: Mon, 18 Apr 2011 08:49:26 +0200 Thread-Topic: [siprec] FW: Do we need to model participants not part ofCS butassociated with Media Stream block in the metadatamodel ? (was RE: Partial updates and identifiers) Thread-Index: Acv7hIWImXnuQ0xMQ420yoaCaNBpNQCD+Vfw Message-ID: References: <35BCE99A477D6A4986FB2216D8CF2CFD061331FF@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD061332DC@XMB-BGL-417.cisco.com> <4DA868AC.6070204@cisco.com> In-Reply-To: <4DA868AC.6070204@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] FW: Do we need to model participants not part ofCS butassociated with Media Stream block in the metadatamodel ? (was RE: Partial updates and identifiers) X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2011 06:49:33 -0000 =20 > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 15 April 2011 16:48 > To: siprec@ietf.org > Subject: Re: [siprec] FW: Do we need to model participants=20 > not part ofCS butassociated with Media Stream block in the=20 > metadatamodel ? (was RE: Partial updates and identifiers) >=20 > My original thinking on this was that you can have a=20 > situation where you=20 > know you have a CS involving sip:foo.com, and you know (somehow) that=20 > the media coming from foo.com includes contributions from Bob=20 > and Carol=20 > and Ted and Alice. You might not even have signaling URIs for=20 > them, and=20 > you may not be able to distinguish which media is from which=20 > person, but=20 > it still seems like it would be good to have a way to represent what=20 > *is* known. [JRE] Exactly, but this can be achieved by including the identities of thes= e parties (e.g., URIs, if known) as attributes of the Participant represent= ing the conference. I think it would be misleading to treat them as Partici= pants, since so little is known about them. John >=20 > But I'm ok with what what is now being discussed if that=20 > seems to meet=20 > people's needs. >=20 > Thanks, > Paul From rmohanr@cisco.com Sun Apr 17 23:58:49 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 50EA4E0782 for ; Sun, 17 Apr 2011 23:58:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.119 X-Spam-Level: X-Spam-Status: No, score=-9.119 tagged_above=-999 required=5 tests=[AWL=-0.920, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oal+gVcUG9Dt for ; Sun, 17 Apr 2011 23:58:44 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfc.amsl.com (Postfix) with ESMTP id 71E61E0783 for ; Sun, 17 Apr 2011 23:58:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=39712; q=dns/txt; s=iport; t=1303109923; x=1304319523; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=sH95jFK/weQ3A7g68fgWaL6CSRfYdLvvFxOvFa/IEAg=; b=SE2foC8dRMUyHxbMtLCDxjj1NWQ8W7Dbxm7UISJiYKZpuQT8wviFwit8 FRQ/G3LBxwXs6TkXUeHRWNjHo3ccUScVym+WE0WZHAxyOKohavlbSOQzI fs67mQjymbHk0sPCQAllkgDhWUbFzf9rWFGHGuDxUEeP7pk7z+aToznKn A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4AAFzgq02Q/khRgWdsb2JhbACXWI4AFAEBFiYliG+de5s6gwCCcQSFYIwe X-IronPort-AV: E=Sophos;i="4.64,231,1301875200"; d="scan'208";a="83958169" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 18 Apr 2011 06:58:42 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3I6wbIS005255; Mon, 18 Apr 2011 06:58:41 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); Mon, 18 Apr 2011 12:28:41 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-hashedpuzzle: XWs= CI12 JOn9 JfNa J3pe K3Cu ML8a M/he NApK NKaK NqbU OiVW Onqb Or6J OwUi TouD; 2; agBvAGgAbgAuAGUAbAB3AGUAbABsAEAAcwBpAGUAbQBlAG4AcwAtAGUAbgB0AGUAcgBwAHIAaQBzAGUALgBjAG8AbQA7AHMAaQBwAHIAZQBjAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {8A9FDB04-300C-44E6-A7F6-6CFAA53EC3E2}; cgBtAG8AaABhAG4AcgBAAGMAaQBzAGMAbwAuAGMAbwBtAA==; Mon, 18 Apr 2011 06:58:35 GMT; UgBFADoAIABbAHMAaQBwAHIAZQBjAF0AIABGAFcAOgAgAEQAbwAgAHcAZQAgAG4AZQBlAGQAIAB0AG8AIABtAG8AZABlAGwAIABwAGEAcgB0AGkAYwBpAHAAYQBuAHQAcwAgAG4AbwB0ACAAcABhAHIAdAAgAG8AZgBDAFMAIABiAHUAdABhAHMAcwBvAGMAaQBhAHQAZQBkACAAdwBpAHQAaAAgAE0AZQBkAGkAYQAgAFMAdAByAGUAYQBtACAAYgBsAG8AYwBrACAAaQBuACAAdABoAGUAIABtAGUAdABhAGQAYQB0AGEAbQBvAGQAZQBsACAAPwAJACgAdwBhAHMAIABSAEUAOgAgAFAAYQByAHQAaQBhAGwAIAB1AHAAZABhAHQAZQBzACAAYQBuAGQAIABpAGQAZQBuAHQAaQBmAGkAZQByAHMAKQA= x-cr-puzzleid: {8A9FDB04-300C-44E6-A7F6-6CFAA53EC3E2} Content-class: urn:content-classes:message Date: Mon, 18 Apr 2011 12:28:35 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD061334F0@XMB-BGL-417.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] FW: Do we need to model participants not part ofCS butassociated with Media Stream block in the metadatamodel ? (was RE: Partial updates and identifiers) Thread-Index: Acv0jVXI4ji2YTo+SquJ6T6YR3i+lQAdOkDgAEETmvAAg54qsAADKDEgAADSn+AAEAO1UAANZylQABBzW2AABHtBwACZNyqAAAGC+nAAAd/QMAAHC/qgAADkBPAACObIgAB8ZkYA References: <35BCE99A477D6A4986FB2216D8CF2CFD061331FF@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD061332DC@XMB-BGL-417.cisco.com> From: "Ram Mohan R (rmohanr)" To: "Charles Eckel (eckelcu)" , "Elwell, John" , "Parthasarathi R (partr)" , X-OriginalArrivalTime: 18 Apr 2011 06:58:41.0188 (UTC) FILETIME=[0CCD1640:01CBFD96] Subject: Re: [siprec] FW: Do we need to model participants not part ofCS butassociated with Media Stream block in the metadatamodel ? (was RE: Partial updates and identifiers) X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2011 06:58:49 -0000 Thanks Charles for your feedback. Since there is no need to distinguish participant types, I will not add anything for that in the model/format Regards, Ram > -----Original Message----- > From: Charles Eckel (eckelcu) > Sent: Saturday, April 16, 2011 1:08 AM > To: Elwell, John; Ram Mohan R (rmohanr); Parthasarathi R (partr); > siprec@ietf.org > Subject: RE: [siprec] FW: Do we need to model participants not part > ofCS butassociated with Media Stream block in the metadatamodel ? (was > RE: Partial updates and identifiers) >=20 > I do not see a need to distinguish participant "types". Whether or not > a 3pcc participant is considered a participant is, I think, an > implementation preference. If the SRS knows something is a 3pcc, it > might choose to not tell the SRS about it. But then again, it may not > know, so it may well the SRS in that case. Also, a participant my > initially not send an media, and my start sending media later, or vice > versa. I think this is all fine and should not require any modification > of the participant information conveyed by the SRS to the SRS. >=20 > Cheers, > Charles >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Elwell, John > > Sent: Friday, April 15, 2011 8:27 AM > > To: Ram Mohan R (rmohanr); Parthasarathi R (partr); siprec@ietf.org > > Subject: Re: [siprec] FW: Do we need to model participants not part > ofCS butassociated with Media > > Stream block in the metadatamodel ? (was RE: Partial updates and > identifiers) > > > > > > > > > -----Original Message----- > > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > > Sent: 15 April 2011 16:04 > > > To: Parthasarathi R (partr); Elwell, John; siprec@ietf.org > > > Subject: RE: [siprec] FW: Do we need to model participants > > > not part ofCS butassociated with Media Stream block in the > > > metadatamodel ? (was RE: Partial updates and identifiers) > > > > > > I am ok with associating participants behind a UA [ for case > > > where UA is > > > capable of learning them] in CS as part of that CS in the > > > model/format. > > > One question I have is, Do we need to distinguish these > participants > > > from the others by having some attributes as part of > > > participant block? > > > Or is it sufficient if we just treat them as any other participants > of > > > CS. > > [JRE] We could treat them as other Participants, but if we don't have > information about the media they > > are sending receiving and therefore all media is seen by the SRC as > being sent/received by the > > conference UA, then I don't really see it makes sense to treat them > as separate Participant objects. > > > > > > > > There are three categories of participants: > > > Participants who contribute both signaling and media to CS > > > Participants who contribute only media in the CS [ like the > > > below case] > > > Participants who contribute only signaling to CS [e.g. 3pcc > > > controller] > > [JRE] I don't think this distinction is particularly relevant to what > gets sent to the SRS, stored, > > and subsequently played back. The information that really needs to be > captured is which participants > > send/receive which media, and signalling. Signalling is just part of > the CS mechanism that has no > > relevance to what gets recorded and played back. I don't see why a > 3PCC controller would be considered > > a Participant. > > > > John (as individual) > > > > > > > > Ram > > > > > > > -----Original Message----- > > > > From: Parthasarathi R (partr) > > > > Sent: Friday, April 15, 2011 5:28 PM > > > > To: Elwell, John; Ram Mohan R (rmohanr); siprec@ietf.org > > > > Subject: RE: [siprec] FW: Do we need to model participants not > part > > > > ofCS butassociated with Media Stream block in the > > > metadatamodel ? (was > > > > RE: Partial updates and identifiers) > > > > > > > > John point of view looks reasonable to me because CS is not > directly > > > > associated with dialogs but instead it represents session with > the > > > list > > > > of participant involved in it. > > > > > > > > In case of participant list received through conference > > > package to SRC > > > > with UA, those multiple participants from focus shall be > represented > > > as > > > > individual participant block who are pointed to single mixed > media > > > > stream metadata block and all participant belongs within single > > > > conference CS in this scenario. The model is as follows > > > (part in the > > > > diagram represents participant): > > > > > > > > > > > > RS > > > > | > > > > CS------------------------------- > > > > | | > > > > ----------------------- part5(SRC) > > > > | | | | | > > > > | | | | media stream2 > > > > part1 part2 part3 part4 > > > > | | | | > > > > ------------------------- > > > > | > > > > Media stream1 > > > > > > > > Thanks > > > > Partha > > > > > > > > -----Original Message----- > > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > > > Behalf Of Elwell, John > > > > Sent: Friday, April 15, 2011 4:34 PM > > > > To: Ram Mohan R (rmohanr); siprec@ietf.org > > > > Subject: Re: [siprec] FW: Do we need to model participants not > part > > > > ofCS butassociated with Media Stream block in the > > > metadatamodel ? (was > > > > RE: Partial updates and identifiers) > > > > > > > > As an individual, my opinion, which I have pretty much > > > stated before, > > > > is that a participant must always be part of a CS. A couple of > > > > situations have been mentioned where alternatives might be > required, > > > > but I don't believe so. > > > > > > > > 1. Conferences. I think depending what view the SRC has of the > CS, > > > > there are two situations: > > > > > > > > (a) The SRC sees all parties in the conference and has visibility > of > > > > what Media Streams each party sends and receives. In this case, I > > > think > > > > the whole conference can be modelled as a CS and each party can > be > > > > modelled as a Participant in that CS. Such a view will typically > be > > > > feasible when the SRC is located at a conference > > > focus/mixer (e.g., an > > > > MCU). > > > > > > > > (b) The SRC sees the conference focus mixer as a party but > > > has limited > > > > information about parties behind the focus/mixer. In this > > > case I think > > > > the SRC can regard the CS as terminating at the conference > > > > (focus/mixer), with the conference a Participant in that CS. > > > > Information about parties behind the conference may or may not be > > > > available, in which case they can be additional attributes of the > > > > conference Participant object. One typical case will be > > > where the SRC > > > > is located at a UA of one of the conference parties, or at a > B2BUA > > > > between the focus/mixer and a party UA. In that case the CS > > > would have > > > > two Participants: the party concerned and the conference. Am > extreme > > > > case is where the conference is the sole Participant and > > > just records > > > > Media Streams sent by the conference to parties in the > conference. > > > > > > > > Hybrid situations can occur, e.g., for cascaded conferences, > where > > > > participants at one conference are modelled as Participants > > > but other > > > > conferences are just modelled each as a single Participant. > > > > > > > > 2. IVR and similar. I would model the Media Server as a > > > Participant in > > > > the CS, i.e., there is a CS between the Media Server and the > caller. > > > > > > > > John > > > > > > > > > -----Original Message----- > > > > > From: siprec-bounces@ietf.org > > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Ram Mohan R > > > (rmohanr) > > > > > Sent: 15 April 2011 10:56 > > > > > To: siprec@ietf.org > > > > > Subject: [siprec] FW: Do we need to model participants not part > of > > > CS > > > > > butassociated with Media Stream block in the metadata model ? > (was > > > > RE: > > > > > Partial updates and identifiers) > > > > > > > > > > I request people to provide inputs on this and help to > > > take it to a > > > > > closure. This issue has been open for several months now. > > > > > > > > > > Ram > > > > > > > > > > -----Original Message----- > > > > > From: siprec-bounces@ietf.org > > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Ram Mohan R > > > (rmohanr) > > > > > Sent: Tuesday, April 12, 2011 3:04 PM > > > > > To: Elwell, John; Charles Eckel (eckelcu); Parthasarathi > > > R (partr); > > > > > Paul Kyzivat (pkyzivat); siprec@ietf.org > > > > > Cc: Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr) > > > > > Subject: [siprec] Do we need to model participants not part of > CS > > > but > > > > > associated with Media Stream block in the metadata model > > > ? (was RE: > > > > > Partial updates and identifiers) > > > > > > > > > > Renaming the mail thread to discussion to this specific issue - > > > > > "Metadata for participants not part of CS" which we have been > > > > > discussing from several weeks. > > > > > > > > > > Please continue the other issues in original thread and lets > use > > > this > > > > > thread to close this issue. I would request people to give > inputs > > > for > > > > > this issue on this thread and take it to a conclusion. > > > > > > > > > > We(Authors of Metadata model) included participants that are > not > > > part > > > > > of CS to imply: > > > > > - Participants that does NOT contribute to signaling in CS but > > > > > contributes to media The intent is to give more flexibility in > the > > > > > metamodel to represent these types of participants. > > > > > > > > > > Following are some of use case where this can happen- > > > > > > > > > > Use-Case 1: A conference where one of the participants is > > > a SRC. In > > > > > these case the Focus which talks to this SRC becomes part of CS > > > > > contributing signaling as well as media. However the > > > media includes > > > > > media from other participants that are not part of CS. Please > note > > > > SRC > > > > > has to subscribe to conf event packet to get this > > > information (which > > > > > may not be always feasible). > > > > > > > > > > Use-Case 2: one UA in CS works in 3pcc mode to acquire an > > > MoH media > > > > > stream, this might be reflected as unique source for media > stream > > > > > without having a reported signaling relationship to it. E.g > is > > > > given > > > > > here by Henry Lum > > > > > http://www.ietf.org/mail- > archive/web/siprec/current/msg01372.html > > > > > > > > > > In some sense these participants are *still* part of CS as they > > > > > contribute to CS media. > > > > > > > > > > There are three approaches I can see- > > > > > Don't model the participants that does not contribute signaling > in > > > CS > > > > > and only contribute Media Model these participants as not > > > part of CS > > > > > in the model but associated with Media Stream block ( current > > > > > approach) Model these participants to be associated with > > > CS but have > > > > > the association labeled as "indirect participant" > > > > > > > > > > Let me know your thoughts. > > > > > > > > > > Thanks, > > > > > Ram > > > > > > > > > > > -----Original Message----- > > > > > > From: siprec-bounces@ietf.org > > > [mailto:siprec-bounces@ietf.org] On > > > > > > Behalf Of Elwell, John > > > > > > Sent: Tuesday, April 12, 2011 12:13 PM > > > > > > To: Charles Eckel (eckelcu); Parthasarathi R (partr); > > > Paul Kyzivat > > > > > > (pkyzivat); siprec@ietf.org > > > > > > Cc: Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr) > > > > > > Subject: Re: [siprec] Partial updates and identifiers > > > > > > > > > > > > I think the attached message was the last in that thread. So > I > > > > don't > > > > > > really think we had closure. > > > > > > > > > > > > John > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > > > > > Sent: 11 April 2011 23:53 > > > > > > > To: Elwell, John; Parthasarathi R (partr); Paul Kyzivat > > > > > (pkyzivat); > > > > > > > siprec@ietf.org > > > > > > > Cc: Peter Saint-Andre (psaintan); Joe Hildebrand > > > > > (jhildebr); Hadriel > > > > > > > Kaplan > > > > > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > > > > > > > > > Hi John, > > > > > > > > > > > > > > I have attached the last e-mail I have from the > > > thread in which > > > I > > > > > > > first raised this issue. Unfortunately, I do not have > > > the e-mail > > > > > with > > > > > > > the ultimate agreement, but maybe someone else does > > > or this will > > > > > help > > > > > > > prompt some memories. > > > > > > > > > > > > > > Cheers, > > > > > > > Charles > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: siprec-bounces@ietf.org > > > > > [mailto:siprec-bounces@ietf.org] On > > > > > > > Behalf Of Elwell, John > > > > > > > > Sent: Monday, April 11, 2011 9:46 AM > > > > > > > > To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); > > > > > > > siprec@ietf.org > > > > > > > > Cc: Peter Saint-Andre (psaintan); Joe Hildebrand > (jhildebr); > > > > > > Hadriel > > > > > > > Kaplan > > > > > > > > Subject: Re: [siprec] Partial updates and identifiers > > > > > > > > > > > > > > > > Partha, > > > > > > > > > > > > > > > > Thanks for reminding me - I now recall the discussion > some > > > > > > > weeks/months ago about the participants > > > > > > > > obtained from the conference event package. I was never > > > > > > particularly > > > > > > > comfortable with the fact these > > > > > > > > were not considered part of the CS. While that might be > > > > > > > correct if we > > > > > > > consider the CS to be the SIP > > > > > > > > dialog between the SRC and the conference focus, taking a > > > > > > > broader view > > > > > > > of CS those participants behind > > > > > > > > the focus could be considered part of the CS. I don't > > > > > particularly > > > > > > > want to open up the old discussion > > > > > > > > if people are happy with what we have, but something > > > > > doesn't seem > > > > > > > quite right to me. > > > > > > > > > > > > > > > > For example, if these "participants" are not considered > part > > > of > > > > > the > > > > > > > CS, and if we don't have specific > > > > > > > > information about their involvement in media > > > streams, do they > > > > > > really > > > > > > > merit being considered > > > > > > > > Participant objects? > > > > > > > > > > > > > > > > In other words, two possible approaches are: > > > > > > > > > > > > > > > > 1) The CS extends only as far as the focus / mixer. The > > > > > > > focus/mixer is > > > > > > > a "Participant" and the users > > > > > > > > behind the focus are not separate Participants but are > just > > > > > > > additional > > > > > > > data associated with the > > > > > > > > focus/mixer Participant. The only Media Streams we are > > > > > > > concerned with > > > > > > > are between the mixer and the > > > > > > > > SRC. > > > > > > > > > > > > > > > > 2) The CS extends beyond the focus/mixer to users > > > > > learned via the > > > > > > > conference event package, each of > > > > > > > > those users is a separate Participant object, and we > > > > > are concerned > > > > > > > with Media Stream objects that > > > > > > > > those participants send and receive. I am not sure how > > > feasible > > > > > > this > > > > > > > approach is, because I am not > > > > > > > > sure that the SRC can obtain enough information about > media > > > > > > > streams at > > > > > > > users behind the focus/mixer. > > > > > > > > > > > > > > > > It seems the present solution is somewhere between the > > > > > two, which > > > > > > is > > > > > > > why I am uncomfortable. > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > John (as individual) > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > > > > > > Sent: 11 April 2011 10:29 > > > > > > > > > To: Elwell, John; Paul Kyzivat (pkyzivat); > siprec@ietf.org > > > > > > > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe > > > > > Hildebrand > > > > > > > > > (jhildebr) > > > > > > > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > > > > > > > > > > > > > John, > > > > > > > > > > > > > > > > > > Please read inline. > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > Partha > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Elwell, John [mailto:john.elwell@siemens- > > > > enterprise.com] > > > > > > > > > Sent: Monday, April 11, 2011 2:11 PM > > > > > > > > > To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); > > > > > > > siprec@ietf.org > > > > > > > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe > > > > > Hildebrand > > > > > > > > > (jhildebr) > > > > > > > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Parthasarathi R (partr) > [mailto:partr@cisco.com] > > > > > > > > > > Sent: 11 April 2011 08:35 > > > > > > > > > > To: Elwell, John; Paul Kyzivat (pkyzivat); > > > siprec@ietf.org > > > > > > > > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe > > > > > > Hildebrand > > > > > > > > > > (jhildebr) > > > > > > > > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > > > > > > > > > > > > > > > John, > > > > > > > > > > > > > > > > > > > > As I mentioned below, stream block will be unique > > > > > > > within CS, (not > > > > > > > > > > required to be unique across multiple CS) and so, > xml:id > > > or > > > > > > > > > enhancing > > > > > > > > > > the normative statement of RFC 4574 label > > > attribute to be > > > > > > unique > > > > > > > > > > within CS will serve the purpose. I'm fine with > > > any of the > > > > > > above > > > > > > > > > > mentioned id. > > > > > > > > > > Please note that RFC 4574 "label" attribute is > > > the nature > > > > > > > > > data for RS > > > > > > > > > > dialog. > > > > > > > > > > > > > > > > > > > > In case participant within CS, xml:id will serve the > > > > purpose > > > > > > but > > > > > > > we > > > > > > > > > > need to get more clarity about participants who are > not > > > > > > > > > part of CS but > > > > > > > > > > > > > > > > > > > within RS. > > > > > > > > > [JRE] If I understand the figure in section 3 of > > > metadata-04 > > > > > > > > > correctly, a Participant can have a relationship with > > > > > a CS, but > > > > > > no > > > > > > > > > direct relationship with an RS. > > > > > > > > > > > > > > > > > > Sorry, I mixed up my statement with the latest > > > > update > > > > > of > > > > > > > > > making CSG optional. As per Sec 3 of metadata-04, > > > participant > > > > > has > > > > > > > > > direct relationship with CSG in case CS is left > completely > > > > > > > > > unattached. In case CSG is optional, then participant > > > > > will have > > > > > > > > > direct relationship with RS in case there is no > > > relationship > > > > > > > > > between CS and participant. > > > > > > > > > > > > > > > > > > > > > > > > > > > So a participant that does not have a relationship > > > > > with a CS is > > > > > > > left > > > > > > > > > completely unattached, unless it has a relationship > > > > > with a Media > > > > > > > > > Stream (which always has a relationship with a CS). So > to > > > > > > > > > summarize: > > > > > > > > > - a Participant can have a direct relationship > > > with a CS; or > > > > > > > > > - a Participant can have an indirect relationship > > > > > with a CS (via > > > > > > a > > > > > > > > > Media Stream); agreed > > > > > > > > > - a Participant can have no relationship with a CS, and > > > > > > > therefore no > > > > > > > > > relationship with an RS. > > > > > > > > > Do we really need this last case? > > > > > > > > > > > > > > > > > > I'm happy if the last case is not > > > required because > > > > it > > > > > > > > > simplify the solution and there is no need of > > > unique id for > > > > > > > > > participant. But SRS implementers may prefer to have > > > > > relationship > > > > > > > > > with participant and RS. I wish more opinion before > taking > > > > > > > > > decision whether to remove the last case > > > > > > > > > > > > > > > > > > > Because CS may span across different RS how about the > > > > > > > > > participant who > > > > > > > > > > are not part of CS? > > > > > > > > > [JRE] I don't understand the words "Because CS may span > > > > across > > > > > > > > > different RS", because in the rest of the sentence you > are > > > > > > talking > > > > > > > > > about a Participant that is not part of a CS. > > > > > > > > > > > > > > > > > > > Ex: One of the user in the conference acts as SRC, > fetch > > > > > > > > > participant > > > > > > > > > > info using conferene package and new RS is created > > > > > > > during initial > > > > > > > > > > conference creation and hold&resume of a user within > CS. > > > > > > > > > [JRE] I am not sure what you are trying to say > > > here. I would > > > > > > > > > consider a user whose identity is obtained via a > > > conference > > > > > event > > > > > > > > > package as being part of the CS. > > > > > > > > > > > > > > > > > > I'm trying to give the example where > > > > > participant is not > > > > > > > > > associated with CS directly but related to CSG (/RS). > This > > > > > > > > > scenario was considered as a blocking in -03 version of > > > > > metadata. > > > > > > > > > I'm not arguing to have this scenario but it is major > > > concern > > > > > for > > > > > > > > > few folks. > > > > > > > > > > > > > > > > > > CS is between focus and UA, UA acts as SRC, UA > > > receives the > > > > > > > > > participant info via conference event package but those > > > > > > > > > participants are not related in CS directly (and > > > only focus > > > > is > > > > > > > > > related) but they contributed for the mixed stream. > > > > > > > > > > > > > > > > > > > > > That user is sending/receiving Media Streams that > > > > > are part of a > > > > > > > > > CS, or if it isn't sending/receiving Media Streams, > > > > > what is the > > > > > > > > > relevance > > > > > > > of > > > > > > > > > that Participant? > > > > > > > > > > > > > > > > > > Mixed media stream from focus to UA > > > belongs to the > > > > > > > Conference > > > > > > > > > event package participants. There participant are not > > > > directly > > > > > > > > > involved as part of CS. Why would we > > > > > create a new RS > > > > > > > > > for such a participant? > > > > > > > > > RS is not created for participant. Multiple > > > > > RS shall be > > > > > > > > > created the same CS during the different time > > > frame as shown > > > > > > below > > > > > > > > > > > > > > > > > > <-------------------CS1-------------> > > > > > > > > > <---RS1--> <---RS2------> > > > > > > > > > > > > > > > > > > CS1 is between UA (SRC) and focus whereas RS1, RS2 is > > > > > between UA > > > > > > > (SRC) > > > > > > > > > and SRS. Here tangling (conference event package) > > > participant > > > > > has > > > > > > > > > to be grouped together in RS1, RS2 by some means > through > > > > given > > > > > > > > > metadata. > > > > > > > The > > > > > > > > > question whether this corner has to be solved ? > > > > > > > > > > > > > > > > > > > John (as individual) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > Partha > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Elwell, John > > > > > [mailto:john.elwell@siemens-enterprise.com] > > > > > > > > > > Sent: Friday, April 08, 2011 9:36 PM > > > > > > > > > > To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); > > > > > > > > > siprec@ietf.org > > > > > > > > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe > > > > > > Hildebrand > > > > > > > > > > (jhildebr) > > > > > > > > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > > > > > > > > > > > > > > > Focusing just on participant and stream for the time > > > being, > > > > > > > > > do these > > > > > > > > > > need to be unique across multiple CSs or not? > > > > > > > > > > > > > > > > > > > > John > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Parthasarathi R (partr) > [mailto:partr@cisco.com] > > > > > > > > > > > Sent: 07 April 2011 10:51 > > > > > > > > > > > To: Paul Kyzivat (pkyzivat); siprec@ietf.org; > Elwell, > > > > John > > > > > > > > > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); > Joe > > > > > > > Hildebrand > > > > > > > > > > > (jhildebr) > > > > > > > > > > > Subject: RE: [siprec] Partial updates and > identifiers > > > > > > > > > > > > > > > > > > > > > > John, > > > > > > > > > > > > > > > > > > > > > > Sorry for the lengthy mail but it contains lot of > > > > analysis > > > > > > and > > > > > > > > > > > reasoning for this id approach. > > > > > > > > > > > > > > > > > > > > > > Adding to Paul's point, I wish to give more > background > > > > and > > > > > > > > > > reason for > > > > > > > > > > > these globally unique id. Initially I had the > > > impression > > > > > that > > > > > > > the > > > > > > > > > > > single unique id (RS dialog-id) in the recording > > > (session > > > > > > > > > > level) and > > > > > > > > > > > some relevant natural id for the rest of the > element > > > will > > > > > > > > > serve the > > > > > > > > > > > purpose. > > > > > > > > > > > There are usecases where this assumption fails. > > > > > Even I have > > > > > > > > > > thought of > > > > > > > > > > > > > > > > > > > > > using "xml:id" instead of URN UUID to avoid long > > > > > string but > > > > > > > > > > xml:id may > > > > > > > > > > > > > > > > > > > > > not end up with unique value always. Our analysis > for > > > URN > > > > > > > > > UUID for > > > > > > > > > > > each level is as follows and please provide your > input > > > in > > > > > > case > > > > > > > id > > > > > > > > > > > shall be > > > > > > > > > > > tweaked: > > > > > > > > > > > > > > > > > > > > > > 1) Recording block: The reason for globally > > > unique id is > > > > > > > > > > that multiple > > > > > > > > > > > > > > > > > > > > > SRC with same id to single SRS. > > > > > > > > > > > > > > > > > > > > > > Topology: > > > > > > > > > > > > > > > > > > > > > > SRC1 SRC2 > > > > > > > > > > > | | > > > > > > > > > > > | ----(RS1-ID1)-----SRS1 > > > > > > > > > > > | > > > > > > > > > > > ---(RS2-ID1)------------------SRS1 > > > > > > > > > > > > > > > > > > > > > > In the above topology, it is possible for ID1 is > > > > generated > > > > > by > > > > > > > both > > > > > > > > > > > SRC1 and SRC2 at the same time. > > > > > > > > > > > > > > > > > > > > > > 2) group (CSG) block: Grouping mechanism (Hadriel > > > > > > > > > session-id, Paul > > > > > > > > > > > Jones > > > > > > > > > > > Session-UUID) is outside the scope of SIPREC. URN > UUID > > > > > > > > > > abstracts the > > > > > > > > > > > exact mechanism to SRS and provides the > > > information only > > > > > > > > > about the > > > > > > > > > > > group of CS from SRC perspective. It possible > > > > > that group may > > > > > > > span > > > > > > > > > > > across multiple RS and It is up to SRS to > > > group and view > > > > > > > > > as single > > > > > > > > > > > recording. > > > > > > > > > > > Here, the single level id in the top will fail. > > > > > The counter > > > > > > > > > > argument > > > > > > > > > > > is to force the single RS having complete CSG but > > > > > > > it*may not* be > > > > > > > > > > > possible in SRC implementation. Here, xml:id will > not > > > > > > > serve the > > > > > > > > > > > purpose > > > > > > > > > > > > > > > > > > > > > > 3) session (CS) block: At the immediate look, > session > > > > > > > > > falls exactly > > > > > > > > > > > under recording block. Use case 3 of > > > > > draft-ietf-siprec-req-09 > > > > > > > > > > > illustrates where CS span across multiple RS. This > > > > > > > > > > requirement calls > > > > > > > > > > > for unique id in session by which these > > > session shall be > > > > > > > > > viewed as > > > > > > > > > > > single CS even though there is no group exists > among > > > > > > > > > them. IMO, in > > > > > > > > > > > case session should not have globally unique id, > > > > > then it is > > > > > > > > > > preferred > > > > > > > > > > > to remove usecase 3 in the requirement. > > > > > > > > > > > > > > > > > > > > > > 4) participant block: It needs some id which may > > > > > be AOR but > > > > > > > > > > AOR is not > > > > > > > > > > > > > > > > > > > > > unique. IMO, xml:id may serve the purpose with > session > > > > > > > > > > unique id. The > > > > > > > > > > > trick exists for participant who are not > > > associated with > > > > > > > > > > CS. We shall > > > > > > > > > > > discuss and fine tune if required. > > > > > > > > > > > > > > > > > > > > > > 5) stream block: Label attribute shall be > > > used as unique > > > > > > > > > > value but RFC > > > > > > > > > > > 4574 does not mandate label attribute has to be > unique > > > > > across > > > > > > > the > > > > > > > > > > > dialog or CS and so, it may possible to change > within > > > > > > > RS and no > > > > > > > > > > > normative statement to stop this implementation. > IMO, > > > > > > > > > > xml:id may serve > > > > > > > > > > > > > > > > > > > > > the purpose with session unique id. Here as well, > We > > > > shall > > > > > > > > > > discuss and > > > > > > > > > > > > > > > > > > > > > fine tune if required. > > > > > > > > > > > > > > > > > > > > > > 6) extensiondata block: This is tracked in > > > the separate > > > > > > > > > mail thread > > > > > > > > > > > whether unique id is required or not. Let us > > > close this > > > > > > > > > as part of > > > > > > > > > > > that mail thread. > > > > > > > > > > > > > > > > > > > > > > Including explicitly Hadriel, Peter, Joe in this > mail > > > > > > > > > > thread as they > > > > > > > > > > > have different view on this ID mechanism. > > > > > > > > > > > > > > > > > > > > > > I had offline discussion with Hadriel in Prague > after > > > > > > > > > > SIPREC meeting > > > > > > > > > > > and my understanding of his major concern is that > how > > > SRS > > > > > > > > > > will be able > > > > > > > > > > > > > > > > > > > > > to design the database in case partial update > > > > > does not have > > > > > > > > > > recording > > > > > > > > > > > (top) id information. I'll put more thought > > > > > > > processing to close > > > > > > > > > > > Hadriel concern of how top id has to be > > > tracked in case > > > > > > > > > > partial update > > > > > > > > > > > > > > > > > > > > > by which SRS implementation will be > > > simplified in terms > > > > of > > > > > > > > > > aggregation > > > > > > > > > > > > > > > > > > > > > maintenance. > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > Partha > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: siprec-bounces@ietf.org > > > > > > > > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul > > > > Kyzivat > > > > > > > > > > (pkyzivat) > > > > > > > > > > > Sent: Thursday, April 07, 2011 12:33 AM > > > > > > > > > > > To: siprec@ietf.org > > > > > > > > > > > Subject: Re: [siprec] Partial updates and > identifiers > > > > > > > > > > > > > > > > > > > > > > John, > > > > > > > > > > > > > > > > > > > > > > For the moment we have proposed that the ids be > > > > > conveyed in > > > > > > > > > > the form > > > > > > > > > > > of URIs that are globally unique, and > > > specifically that > > > > > > > > > > they be UUID > > > > > > > > > > > URNs. > > > > > > > > > > > There is no dependency on the particular form of > the > > > URI, > > > > > but > > > > > > > > > > > specifying they must be UUID URNs makes it possible > to > > > > > > > > > perform some > > > > > > > > > > > internal optimizations for storage. > > > > > > > > > > > > > > > > > > > > > > The UUID URN is a pretty inefficient encoding. A > UUID > > > can > > > > > > > > > > be expressed > > > > > > > > > > > > > > > > > > > > > in 32 bits, so we could consider retaining UUIDs > but > > > > alter > > > > > > the > > > > > > > > > > > encoding if its really an issue. However I am far > from > > > > > > > > > > convinced that > > > > > > > > > > > the size of the IDs is going to be a major > > > issue in the > > > > > > > > > > overall size > > > > > > > > > > > of messages, so I think its probably > > > premature to worry > > > > > about > > > > > > > it. > > > > > > > > > > > > > > > > > > > > > > Because the ids can be expressed in 32 bits, > > > the SRC and > > > > > > > > > > SRS can store > > > > > > > > > > > > > > > > > > > > > them internally that way, thus reducing the > > > > > runtime cost of > > > > > > > > > > > maintaining the data. > > > > > > > > > > > > > > > > > > > > > > The use of unique ids is a significant part of the > > > > overall > > > > > > > > > > approach to > > > > > > > > > > > > > > > > > > > > > formatting updates. If somebody has a > > > different concept > > > > > > > > > in mind it > > > > > > > > > > > could be useful to have an alternative > > > proposal for the > > > > > > > > > > format. If we > > > > > > > > > > > had two worked out approaches we could compare the > > > > > > > > > > tradeoffs in each. > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > Paul > > > > > > > > > > > > > > > > > > > > > > On 4/6/2011 10:24 AM, Elwell, John wrote: > > > > > > > > > > > > Much of the discussion on draft-ram-metadata- > format > > > > > > > in Prague > > > > > > > > > > > concerned the mechanism for performing partial > updates > > > > and > > > > > > > > > > the use of > > > > > > > > > > > identifiers. The draft permits partial updates by > > > > allowing > > > > > > > > > > individual > > > > > > > > > > > objects (e.g., CS, participant, media stream) > > > to be sent > > > > > > > > > > with updated > > > > > > > > > > > content, without having to send again other > > > objects that > > > > > have > > > > > > > not > > > > > > > > > > > changed. So, for example, in a large conference, it > > > would > > > > > > > > > > be possible > > > > > > > > > > > to add or modify an individual participant object > > > without > > > > > > > > > having to > > > > > > > > > > > send all the other participant objects again. I do > not > > > > > recall > > > > > > > any > > > > > > > > > > > opposition to this basic principle. > > > > > > > > > > > > > > > > > > > > > > > > However, to achieve this, every object requires > an > > > > > > > > > > > identifier, and it > > > > > > > > > > > was asserted that these identifiers need to > > > be globally > > > > > > > > > > unique for all > > > > > > > > > > > > > > > > > > > > > time. Although this might be efficient for updating > an > > > > > > > individual > > > > > > > > > > > object, when sending many objects (e.g., at > > > the start of > > > > a > > > > > > > > > > CS or when > > > > > > > > > > > refreshing the entire metadata), this can make the > > > > > > > metadata very > > > > > > > > > > > bulky. > > > > > > > > > > > It depends, of course, on the format of the > > > identifiers, > > > > > > > > > and it was > > > > > > > > > > > stated that there could be alternatives to UUID. > > > > > > > > > Nevertheless, some > > > > > > > > > > > people had concerns. These concerns also > > > extended to the > > > > > > > > > > impact on the > > > > > > > > > > > > > > > > > > > > > database where metadata is stored, since it > > > might not be > > > > > > > > > > feasible to > > > > > > > > > > > convert to a database-friendly mechanism for > linking > > > > > > > > > > objects together. > > > > > > > > > > > > > > > > > > > > > > > > One alternative proposal during the meeting was > > > > > to have a > > > > > > > single > > > > > > > > > > > unique identifier at the top level (for the > > > RS) and use > > > > > local > > > > > > > > > > > identifiers for other objects. Thus when updating a > > > > single > > > > > > > > > > object, it > > > > > > > > > > > would be necessary to include the top level > identifier > > > as > > > > > > > > > > well as one > > > > > > > > > > > or more local identifiers. However, there were > > > > > also concerns > > > > > > > this > > > > > > > > > > > might not fulfil actual or perceived future > > > requirements. > > > > > > > > > > > > > > > > > > > > > > > > Please continue discussion on this. > > > > > > > > > > > > > > > > > > > > > > > > John (as chair) > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > siprec mailing list > > > > > > > > > > > > siprec@ietf.org > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > siprec mailing list > > > > > > > > > > > siprec@ietf.org > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > siprec mailing list > > > > > > > > siprec@ietf.org > > > > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > > > > > _______________________________________________ > > > > > siprec mailing list > > > > > siprec@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > _______________________________________________ > > > > > siprec mailing list > > > > > siprec@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > > _______________________________________________ > > > > siprec mailing list > > > > siprec@ietf.org > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec From rmohanr@cisco.com Mon Apr 18 00:25:49 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B306FE0795 for ; Mon, 18 Apr 2011 00:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.961 X-Spam-Level: X-Spam-Status: No, score=-9.961 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTNEv1KI0TfN for ; Mon, 18 Apr 2011 00:25:45 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfc.amsl.com (Postfix) with ESMTP id 361C2E06D3 for ; Mon, 18 Apr 2011 00:25:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=4806; q=dns/txt; s=iport; t=1303111545; x=1304321145; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=QiCn0ZN7fRnMPt9qbjfP872UJIvHnOTYNJsnxYnJY6k=; b=mpI4S4sXpb7MWGYhdVWRnSKNuMU8h+q8Gu/a3vuX4WAQnMC8g+QtNFyh QHerCXsacPF1MN94IlmrRPK24c3e4bUx/xTYf4yf+z5pmM5QKYytkT3iW bwQ/pgHVod13ZvqxrnO8f6ALW3ILEQCcOIDgWOmo0DXiPbPPwgDSTD+wQ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4AAEnmq02Q/khMgWdsb2JhbACXWI4AFAEBFiYliG+dZ5s+hXEEhWCMHg X-IronPort-AV: E=Sophos;i="4.64,231,1301875200"; d="scan'208";a="83962362" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 18 Apr 2011 07:25:37 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3I7PXSX019187; Mon, 18 Apr 2011 07:25:33 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 18 Apr 2011 12:55:32 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Apr 2011 12:55:31 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD06133514@XMB-BGL-417.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] FW: Do we need to model participants not part ofCS butassociated with Media Stream block in the metadatamodel ? Thread-Index: Acv0jVXI4ji2YTo+SquJ6T6YR3i+lQAdOkDgAEETmvAAg54qsAADKDEgAADSn+AAEAO1UAANZylQABBzW2AABHtBwACZNyqAAAGC+nAAAd/QMAAHC/qgAADkBPAAAwwR4ACBrXAAAAB+UuA= References: <35BCE99A477D6A4986FB2216D8CF2CFD061331FF@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD061332DC@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD0613330A@XMB-BGL-417.cisco.com> From: "Ram Mohan R (rmohanr)" To: "Elwell, John" , "Parthasarathi R (partr)" , X-OriginalArrivalTime: 18 Apr 2011 07:25:32.0893 (UTC) FILETIME=[CD73C0D0:01CBFD99] Subject: Re: [siprec] FW: Do we need to model participants not part ofCS butassociated with Media Stream block in the metadatamodel ? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 07:25:49 -0000 Hi John, Please see inline [Ram] > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Monday, April 18, 2011 12:16 PM > To: Ram Mohan R (rmohanr); Parthasarathi R (partr); siprec@ietf.org > Subject: RE: [siprec] FW: Do we need to model participants not part > ofCS butassociated with Media Stream block in the metadatamodel ? >=20 >=20 >=20 > > -----Original Message----- > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > Sent: 15 April 2011 17:54 > > To: Elwell, John; Parthasarathi R (partr); siprec@ietf.org > > Subject: RE: [siprec] FW: Do we need to model participants > > not part ofCS butassociated with Media Stream block in the > > metadatamodel ? (was RE: Partial updates and identifiers) > > > > Hi John, Please see inline > > > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > Sent: Friday, April 15, 2011 8:57 PM > > > To: Ram Mohan R (rmohanr); Parthasarathi R (partr); siprec@ietf.org > > > Subject: RE: [siprec] FW: Do we need to model participants not part > > > ofCS butassociated with Media Stream block in the > > metadatamodel ? (was > > > RE: Partial updates and identifiers) > > > > > > > > > > > > > -----Original Message----- > > > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > > > Sent: 15 April 2011 16:04 > > > > To: Parthasarathi R (partr); Elwell, John; siprec@ietf.org > > > > Subject: RE: [siprec] FW: Do we need to model participants > > > > not part ofCS butassociated with Media Stream block in the > > > > metadatamodel ? (was RE: Partial updates and identifiers) > > > > > > > > I am ok with associating participants behind a UA [ for case > > > > where UA is > > > > capable of learning them] in CS as part of that CS in the > > > > model/format. > > > > One question I have is, Do we need to distinguish these > > participants > > > > from the others by having some attributes as part of > > > > participant block? > > > > Or is it sufficient if we just treat them as any other > > participants > > > of > > > > CS. > > > [JRE] We could treat them as other Participants, but if we > > don't have > > > information about the media they are sending receiving and > therefore > > > all media is seen by the SRC as being sent/received by the > > conference > > > UA, then I don't really see it makes sense to treat them as > separate > > > Participant objects. > > > > Yes I agree with you. My thought here is for cases where the > > conference > > UA can learn the other participants, we can convey them as separate > > participant objects in the model, of course all of them will be > > associated ("sends" association) with the same mixed stream. > > For cases where conference UA cannot determine, we will have only one > > participant object ( i.e. conference UA) conveyed in the model > > > > I hope this would be sufficient for most use cases. > [JRE] But in this case, even though the UA has learned the identities > of other parties behind the conference focus, it doesn't know which of > these parties are really contributing to media received by the UA and > which of these parties actually receive media sent by the UA. Also the > UA does not know what media is exchanged between those other parties. [Ram] This is a good point that you have brought up.=20 The conference event package (RFC 4575) does have a enough information to convey the above details. The conf package has certain elements () defined for each user (). This element () does convey the information on the state(through element) of each user of the conference. This has values connected/on-hold among others. On-hold is used to indicate that user is neither "hearing" the conference mix nor is his/her media being mixed in the conference. Please refer to section 5.7.3 of RFC 4575 for more details. Also the information on what media is exchanged in the conference is conveyed in element. However I see its going to be very difficult for the Conference UA/SRC to retrieve this information each time it has to send metadata to SRS. So I am open to your suggestion of just having basic information (like URI) about participant behind conference UA participant. I would like to hear thoughts from others like Charles, Brian and others who are interested in conference recording in SIPREC. Regards, Ram > Therefore treating them as Participants is, I think, misleading. I > agree we should try to include the identities of these other parties, > but it seems to make more sense to include them as attributes of the > Participant representing the conference. >=20 > John (as individual) From pkyzivat@cisco.com Mon Apr 18 05:38:52 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BF7C4E07BF for ; Mon, 18 Apr 2011 05:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.444 X-Spam-Level: X-Spam-Status: No, score=-110.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6twzOmfwWbB for ; Mon, 18 Apr 2011 05:38:48 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfc.amsl.com (Postfix) with ESMTP id 5F098E0664 for ; Mon, 18 Apr 2011 05:38:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=1924; q=dns/txt; s=iport; t=1303130328; x=1304339928; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=gnQ8to7eXhvexN/7vYdRkywpO3dMyRhBokL6frnk3Hw=; b=IZQazVRKAUcdewYTYsIhNqhzMBmqp/7kKYRednd1GrurIh8Ndl9PGFm9 cyMiEf4gMw8Qcle9pBqehd7nE/w4kJZzFDaBzo+hwuYknu3aMNfb9W/qC 7hdJBPtPW8pSlJurWnvAbZf37FToWfR+XUPWkxqfWtxEVA6UJcZ1fd3I4 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQIAMovrE2rRDoG/2dsb2JhbACYGY1Dd6dFm3SFcQSOAoN1 X-IronPort-AV: E=Sophos;i="4.64,232,1301875200"; d="scan'208";a="339648371" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-2.cisco.com with ESMTP; 18 Apr 2011 12:38:47 +0000 Received: from [161.44.174.125] (dhcp-161-44-174-125.cisco.com [161.44.174.125]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3ICclhC008003 for ; Mon, 18 Apr 2011 12:38:47 GMT Message-ID: <4DAC30D6.1010705@cisco.com> Date: Mon, 18 Apr 2011 08:38:46 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: siprec@ietf.org References: <35BCE99A477D6A4986FB2216D8CF2CFD061331FF@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD061332DC@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD0613330A@XMB-BGL-417.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] FW: Do we need to model participants not part ofCS butassociated with Media Stream block in the metadatamodel ? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 12:38:52 -0000 I am ok with either direction here, as long as its done in a way that makes clear what is/isn't known. The point here is that there is some information about participation that we would like to retain, whether we have details of association with particular media streams or not. In the future, you might want to search for recorded CSs that involve a particular participant. We should be enabling that even in this case. Thanks, Paul On 4/18/2011 2:46 AM, Elwell, John wrote: >>> [JRE] We could treat them as other Participants, but if we >> don't have >>> information about the media they are sending receiving and therefore >>> all media is seen by the SRC as being sent/received by the >> conference >>> UA, then I don't really see it makes sense to treat them as separate >>> Participant objects. >> >> Yes I agree with you. My thought here is for cases where the >> conference >> UA can learn the other participants, we can convey them as separate >> participant objects in the model, of course all of them will be >> associated ("sends" association) with the same mixed stream. >> For cases where conference UA cannot determine, we will have only one >> participant object ( i.e. conference UA) conveyed in the model >> >> I hope this would be sufficient for most use cases. > [JRE] But in this case, even though the UA has learned the identities of other parties behind the conference focus, it doesn't know which of these parties are really contributing to media received by the UA and which of these parties actually receive media sent by the UA. Also the UA does not know what media is exchanged between those other parties. Therefore treating them as Participants is, I think, misleading. I agree we should try to include the identities of these other parties, but it seems to make more sense to include them as attributes of the Participant representing the conference. From rmohanr@cisco.com Mon Apr 18 05:47:46 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 59D49E06FC for ; Mon, 18 Apr 2011 05:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.264 X-Spam-Level: X-Spam-Status: No, score=-10.264 tagged_above=-999 required=5 tests=[AWL=0.335, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0d1LZK9f4bc for ; Mon, 18 Apr 2011 05:47:42 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfc.amsl.com (Postfix) with ESMTP id E2630E0664 for ; Mon, 18 Apr 2011 05:47:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=2830; q=dns/txt; s=iport; t=1303130861; x=1304340461; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=2MygblndLLmPj2GK8T6F0kK/w+h7YCoRHndAZlEP8XU=; b=YsrA2XayJCuj8VVs7DKXxbkO0b5aC7C1fIWwia4UKqOMCgHwYjoZDgnc 6ozF6jm9a/f6gJYm0qtCb8EWqOQyvwRrxrKFt8Fk55e3R1rfVML61FrP4 X0Lm6rWtsqTeIusJehPxu7xI2s8bGLyHDrfDCD8rh7/oY1aWDpDhSPNoX w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtEAACcyrE2Q/khMgWdsb2JhbACXWo4CFAEBFiYlpzybdoVxBIVgjB4 X-IronPort-AV: E=Sophos;i="4.64,232,1301875200"; d="scan'208";a="26115538" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 18 Apr 2011 12:47:36 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3ICkP6p016510 for ; Mon, 18 Apr 2011 12:47:35 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); Mon, 18 Apr 2011 18:17:00 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Apr 2011 18:16:59 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD06133659@XMB-BGL-417.cisco.com> In-Reply-To: <4DAC30D6.1010705@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] FW: Do we need to model participants not part ofCS butassociated with Media Stream block in the metadatamodel ? Thread-Index: Acv9xZpD8FJEKJ+UTrWQLp01GJ8t2gAAM/tg References: <35BCE99A477D6A4986FB2216D8CF2CFD061331FF@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD061332DC@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD0613330A@XMB-BGL-417.cisco.com> <4DAC30D6.1010705@cisco.com> From: "Ram Mohan R (rmohanr)" To: "Paul Kyzivat (pkyzivat)" , X-OriginalArrivalTime: 18 Apr 2011 12:47:00.0197 (UTC) FILETIME=[B594C950:01CBFDC6] Subject: Re: [siprec] FW: Do we need to model participants not part ofCS butassociated with Media Stream block in the metadatamodel ? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 12:47:46 -0000 Paul, Agreed with your thoughts. The information that John asks for can be learnt from conf package as I mentioned in the other mail. http://www.ietf.org/mail-archive/web/siprec/current/msg01861.html However I am ok with either directions once we have a consensus from wider team. Regards, Ram > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Paul Kyzivat (pkyzivat) > Sent: Monday, April 18, 2011 6:09 PM > To: siprec@ietf.org > Subject: Re: [siprec] FW: Do we need to model participants not part > ofCS butassociated with Media Stream block in the metadatamodel ? >=20 > I am ok with either direction here, as long as its done in a way that > makes clear what is/isn't known. The point here is that there is some > information about participation that we would like to retain, whether > we > have details of association with particular media streams or not. >=20 > In the future, you might want to search for recorded CSs that involve a > particular participant. We should be enabling that even in this case. >=20 > Thanks, > Paul >=20 > On 4/18/2011 2:46 AM, Elwell, John wrote: >=20 > >>> [JRE] We could treat them as other Participants, but if we > >> don't have > >>> information about the media they are sending receiving and > therefore > >>> all media is seen by the SRC as being sent/received by the > >> conference > >>> UA, then I don't really see it makes sense to treat them as > separate > >>> Participant objects. > >> > >> Yes I agree with you. My thought here is for cases where the > >> conference > >> UA can learn the other participants, we can convey them as separate > >> participant objects in the model, of course all of them will be > >> associated ("sends" association) with the same mixed stream. > >> For cases where conference UA cannot determine, we will have only > one > >> participant object ( i.e. conference UA) conveyed in the model > >> > >> I hope this would be sufficient for most use cases. > > [JRE] But in this case, even though the UA has learned the identities > of other parties behind the conference focus, it doesn't know which of > these parties are really contributing to media received by the UA and > which of these parties actually receive media sent by the UA. Also the > UA does not know what media is exchanged between those other parties. > Therefore treating them as Participants is, I think, misleading. I > agree we should try to include the identities of these other parties, > but it seems to make more sense to include them as attributes of the > Participant representing the conference. >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From partr@cisco.com Mon Apr 18 06:25:17 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 71877E0664 for ; Mon, 18 Apr 2011 06:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.113 X-Spam-Level: X-Spam-Status: No, score=-10.113 tagged_above=-999 required=5 tests=[AWL=0.486, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0cTxe4kzXQZ for ; Mon, 18 Apr 2011 06:25:13 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfc.amsl.com (Postfix) with ESMTP id D4536E06F6 for ; Mon, 18 Apr 2011 06:25:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=4015; q=dns/txt; s=iport; t=1303133113; x=1304342713; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=JDv0GBBzI5KPwHlxB+q2g9rzd0mpTclBgMZFSJT3RY0=; b=GyQJ3YEo/VAnq6Xn6nx0gRNItdhbNpylpFGfjaa9Zb+Fg+BAJl+GOAmS RaFluzrJF3iA9LIDNn1T1l/nwDIYJBVmvyeKw1LVHR7QeFoj2fz6tGYqt crkaHvkOtpGr1aLTCsV6fI2lsVdYJylOhSaXBLvSYmDJWm0ZWHSEG4UM9 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtEAAJo6rE2Q/khRgWdsb2JhbACXWo4CFAEBFiYliG+eZZwFhXEEhWCMHg X-IronPort-AV: E=Sophos;i="4.64,232,1301875200"; d="scan'208";a="84026412" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 18 Apr 2011 13:25:12 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3IDP81l025752; Mon, 18 Apr 2011 13:25:11 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 18 Apr 2011 18:55:09 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Apr 2011 18:55:08 +0530 Message-ID: In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD06133659@XMB-BGL-417.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] FW: Do we need to model participants not part ofCSbutassociated with Media Stream block in the metadatamodel ? Thread-Index: Acv9xZpD8FJEKJ+UTrWQLp01GJ8t2gAAM/tgAAEcy/A= References: <35BCE99A477D6A4986FB2216D8CF2CFD061331FF@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD061332DC@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD0613330A@XMB-BGL-417.cisco.com><4DAC30D6.1010705@cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD06133659@XMB-BGL-417.cisco.com> From: "Parthasarathi R (partr)" To: "Ram Mohan R (rmohanr)" , "Paul Kyzivat (pkyzivat)" , , "Elwell, John" X-OriginalArrivalTime: 18 Apr 2011 13:25:09.0641 (UTC) FILETIME=[0A323790:01CBFDCC] Subject: Re: [siprec] FW: Do we need to model participants not part ofCSbutassociated with Media Stream block in the metadatamodel ? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 13:25:17 -0000 I prefer to represent as a separate participant because it is possible to fetch participant information using RFC 4575. As I explained with model diagram in another mail thread, I'm seeing conference participants to media stream as remote mixed stream relationship. In case of mixed stream, it is always expected to lose lot of information like time at which specific participant contributes to the media and remote mixed stream is not the exception. Having said that I don't have experience in RFC 4575 implementation, it looks bit complicated to pull these participant data in the real time but those implemented may talk for it. Thanks Partha -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Ram Mohan R (rmohanr) Sent: Monday, April 18, 2011 6:17 PM To: Paul Kyzivat (pkyzivat); siprec@ietf.org Subject: Re: [siprec] FW: Do we need to model participants not part ofCSbutassociated with Media Stream block in the metadatamodel ? Paul, Agreed with your thoughts. The information that John asks for can be learnt from conf package as I mentioned in the other mail. http://www.ietf.org/mail-archive/web/siprec/current/msg01861.html However I am ok with either directions once we have a consensus from wider team. Regards, Ram > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > Behalf Of Paul Kyzivat (pkyzivat) > Sent: Monday, April 18, 2011 6:09 PM > To: siprec@ietf.org > Subject: Re: [siprec] FW: Do we need to model participants not part=20 > ofCS butassociated with Media Stream block in the metadatamodel ? >=20 > I am ok with either direction here, as long as its done in a way that=20 > makes clear what is/isn't known. The point here is that there is some=20 > information about participation that we would like to retain, whether=20 > we have details of association with particular media streams or not. >=20 > In the future, you might want to search for recorded CSs that involve a > particular participant. We should be enabling that even in this case. >=20 > Thanks, > Paul >=20 > On 4/18/2011 2:46 AM, Elwell, John wrote: >=20 > >>> [JRE] We could treat them as other Participants, but if we > >> don't have > >>> information about the media they are sending receiving and > therefore > >>> all media is seen by the SRC as being sent/received by the > >> conference > >>> UA, then I don't really see it makes sense to treat them as > separate > >>> Participant objects. > >> > >> Yes I agree with you. My thought here is for cases where the=20 > >> conference UA can learn the other participants, we can convey them=20 > >> as separate participant objects in the model, of course all of them > >> will be associated ("sends" association) with the same mixed=20 > >> stream. > >> For cases where conference UA cannot determine, we will have only > one > >> participant object ( i.e. conference UA) conveyed in the model > >> > >> I hope this would be sufficient for most use cases. > > [JRE] But in this case, even though the UA has learned the identities > of other parties behind the conference focus, it doesn't know which of > these parties are really contributing to media received by the UA and=20 > which of these parties actually receive media sent by the UA. Also the > UA does not know what media is exchanged between those other parties. > Therefore treating them as Participants is, I think, misleading. I=20 > agree we should try to include the identities of these other parties,=20 > but it seems to make more sense to include them as attributes of the=20 > Participant representing the conference. >=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 partr@cisco.com Mon Apr 18 23:49:41 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1990FE068B for ; Mon, 18 Apr 2011 23:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.238 X-Spam-Level: X-Spam-Status: No, score=-9.238 tagged_above=-999 required=5 tests=[AWL=-0.439, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YaxYpBKUIxUN for ; Mon, 18 Apr 2011 23:49:38 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfc.amsl.com (Postfix) with ESMTP id B5BA1E05F5 for ; Mon, 18 Apr 2011 23:49:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=19375; q=dns/txt; s=iport; t=1303195777; x=1304405377; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=RtFGJJOWhjxsrVOAsHg3V8+OTvCytVLyJyRkQ62NbX0=; b=Z01fsvJuMw5jriYe0YQRotB+/DV14ghfDucI030Y447lld8CDid0xDge 0Sjou9N5VJcIkQ75wRlHT1088/Th+68hc9pgOXf3hzaIjgQ/rUOSQzfAm 9HibCP23+WJ7Jo3tNSoKvVKL55dzge/eUs88jW/9BHuYLUxr2fMfx9j+P 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtsAAJQvrU2Q/khNgWdsb2JhbACXPo4FFAEBFiYliG+gGZxqgwCCcQSFZYwk X-IronPort-AV: E=Sophos;i="4.64,238,1301875200"; d="scan'208";a="84141664" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 19 Apr 2011 06:49:36 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3J6nYYr009280; Tue, 19 Apr 2011 06:49:36 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 19 Apr 2011 12:19:34 +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, 19 Apr 2011 12:19:33 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Partial updates and identifiers Thread-Index: Acv0jVXI4ji2YTo+SquJ6T6YR3i+lQAdOkDgAEETmvAAg54qsAADKDEgAADSn+AAEAO1UAANZylQAXAZhbA= References: <4D9CB8E1.7030402@cisco.com> From: "Parthasarathi R (partr)" To: "Charles Eckel (eckelcu)" , "Elwell, John" , "Paul Kyzivat (pkyzivat)" , X-OriginalArrivalTime: 19 Apr 2011 06:49:34.0224 (UTC) FILETIME=[F132C100:01CBFE5D] Cc: "Peter Saint-Andre \(psaintan\)" , "Joe Hildebrand \(jhildebr\)" Subject: Re: [siprec] Partial updates and identifiers X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 19 Apr 2011 06:49:41 -0000 Hi all, As per the progress in another mail thread (http://www.ietf.org/mail-archive/web/siprec/current/msg01864.html), there is no known usecase wherein participant involved in RS but not involved in CS directly. IOW, participant is always within CS. This change in metadata model makes us to re-look whether participant shall be unique id within CS (something like xml:id) rather than globally unique id. The open question is whether participant in multiple CS within single RS should have same id or not. Example: Alice acts as SRC and the scenario is as follows: 1) Alice establish CS1 with Bob, RS is established between Alice & SRS, CS1 details with Alice & Bob as participant is passed 2) Bob transfer the session to Carol=20 3) New CS2 is established between Alice & Carol, RS is updated with new CS2 info having Alice & Carol as participants=20 The open question are 1) At step 3, whether Alice MUST have the same unique id as in step 1 or it is not mandatory?=20 2) If required to be unique across RS, whether xml:id serve the purpose? Thanks Partha=20 -----Original Message----- From: Charles Eckel (eckelcu)=20 Sent: Tuesday, April 12, 2011 4:23 AM To: Elwell, John; Parthasarathi R (partr); Paul Kyzivat (pkyzivat); siprec@ietf.org Cc: Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr); Hadriel Kaplan Subject: RE: [siprec] Partial updates and identifiers Hi John, I have attached the last e-mail I have from the thread in which I first raised this issue. Unfortunately, I do not have the e-mail with the ultimate agreement, but maybe someone else does or this will help prompt some memories. Cheers, Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > Behalf Of Elwell, John > Sent: Monday, April 11, 2011 9:46 AM > To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); siprec@ietf.org > Cc: Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr); Hadriel=20 > Kaplan > Subject: Re: [siprec] Partial updates and identifiers >=20 > Partha, >=20 > Thanks for reminding me - I now recall the discussion some=20 > weeks/months ago about the participants obtained from the conference=20 > event package. I was never particularly comfortable with the fact=20 > these were not considered part of the CS. While that might be correct=20 > if we consider the CS to be the SIP dialog between the SRC and the=20 > conference focus, taking a broader view of CS those participants behind the focus could be considered part of the CS. I don't particularly want to open up the old discussion if people are happy with what we have, but something doesn't seem quite right to me. >=20 > For example, if these "participants" are not considered part of the=20 > CS, and if we don't have specific information about their involvement=20 > in media streams, do they really merit being considered Participant objects? >=20 > In other words, two possible approaches are: >=20 > 1) The CS extends only as far as the focus / mixer. The focus/mixer is > a "Participant" and the users behind the focus are not separate=20 > Participants but are just additional data associated with the=20 > focus/mixer Participant. The only Media Streams we are concerned with are between the mixer and the SRC. >=20 > 2) The CS extends beyond the focus/mixer to users learned via the=20 > conference event package, each of those users is a separate=20 > Participant object, and we are concerned with Media Stream objects=20 > that those participants send and receive. I am not sure how feasible this approach is, because I am not sure that the SRC can obtain enough information about media streams at users behind the focus/mixer. >=20 > It seems the present solution is somewhere between the two, which is why I am uncomfortable. >=20 > Regards, >=20 > John (as individual) >=20 >=20 > > -----Original Message----- > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > Sent: 11 April 2011 10:29 > > To: Elwell, John; Paul Kyzivat (pkyzivat); siprec@ietf.org > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe Hildebrand=20 > > (jhildebr) > > Subject: RE: [siprec] Partial updates and identifiers > > > > John, > > > > Please read inline. > > > > Thanks > > Partha > > > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Monday, April 11, 2011 2:11 PM > > To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat);=20 > > siprec@ietf.org > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe Hildebrand > > (jhildebr) > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > > > > -----Original Message----- > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > Sent: 11 April 2011 08:35 > > > To: Elwell, John; Paul Kyzivat (pkyzivat); siprec@ietf.org > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe Hildebrand > > > (jhildebr) > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > John, > > > > > > As I mentioned below, stream block will be unique within CS, (not=20 > > > required to be unique across multiple CS) and so, xml:id or > > enhancing > > > the normative statement of RFC 4574 label attribute to be unique=20 > > > within CS will serve the purpose. I'm fine with any of the above=20 > > > mentioned id. > > > Please note that RFC 4574 "label" attribute is the nature > > data for RS > > > dialog. > > > > > > In case participant within CS, xml:id will serve the purpose but=20 > > > we need to get more clarity about participants who are not > > part of CS but > > > > > within RS. > > [JRE] If I understand the figure in section 3 of metadata-04=20 > > correctly, a Participant can have a relationship with a CS, but no=20 > > direct relationship with an RS. > > > > Sorry, I mixed up my statement with the latest update of=20 > > making CSG optional. As per Sec 3 of metadata-04, participant has=20 > > direct relationship with CSG in case CS is left completely=20 > > unattached. In case CSG is optional, then participant will have=20 > > direct relationship with RS in case there is no relationship between > > CS and participant. > > > > > > So a participant that does not have a relationship with a CS is=20 > > left completely unattached, unless it has a relationship with a=20 > > Media Stream (which always has a relationship with a CS). So to=20 > > summarize: > > - a Participant can have a direct relationship with a CS; or > > - a Participant can have an indirect relationship with a CS (via a=20 > > Media Stream); agreed > > - a Participant can have no relationship with a CS, and therefore no > > relationship with an RS. > > Do we really need this last case? > > > > I'm happy if the last case is not required because it=20 > > simplify the solution and there is no need of unique id for=20 > > participant. But SRS implementers may prefer to have relationship=20 > > with participant and RS. I wish more opinion before taking decision=20 > > whether to remove the last case > > > > > Because CS may span across different RS how about the > > participant who > > > are not part of CS? > > [JRE] I don't understand the words "Because CS may span across=20 > > different RS", because in the rest of the sentence you are talking=20 > > about a Participant that is not part of a CS. > > > > > Ex: One of the user in the conference acts as SRC, fetch > > participant > > > info using conferene package and new RS is created during initial=20 > > > conference creation and hold&resume of a user within CS. > > [JRE] I am not sure what you are trying to say here. I would=20 > > consider a user whose identity is obtained via a conference event=20 > > package as being part of the CS. > > > > I'm trying to give the example where participant is not=20 > > associated with CS directly but related to CSG (/RS). This scenario=20 > > was considered as a blocking in -03 version of metadata. I'm not=20 > > arguing to have this scenario but it is major concern for few folks. > > > > CS is between focus and UA, UA acts as SRC, UA receives the=20 > > participant info via conference event package but those participants > > are not related in CS directly (and only focus is related) but they=20 > > contributed for the mixed stream. > > > > That user is sending/receiving Media Streams that are part of a CS, > > or if it isn't sending/receiving Media Streams, what is the=20 > > relevance of that Participant? > > > > Mixed media stream from focus to UA belongs to the=20 > > Conference event package participants. There participant are not=20 > > directly involved as part of CS. Why would we create a=20 > > new RS for such a participant? > > RS is not created for participant. Multiple RS shall be=20 > > created the same CS during the different time frame as shown below > > > > <-------------------CS1-------------> > > <---RS1--> <---RS2------> > > > > CS1 is between UA (SRC) and focus whereas RS1, RS2 is between UA=20 > > (SRC) and SRS. Here tangling (conference event package) participant=20 > > has to be grouped together in RS1, RS2 by some means through given=20 > > metadata. The question whether this corner has to be solved ?=20 > > > > > > John (as individual) > > > > > > > > > > > > Thanks > > > Partha > > > > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > Sent: Friday, April 08, 2011 9:36 PM > > > To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); > > siprec@ietf.org > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe Hildebrand > > > (jhildebr) > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > Focusing just on participant and stream for the time being, > > do these > > > need to be unique across multiple CSs or not? > > > > > > John > > > > > > > -----Original Message----- > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > Sent: 07 April 2011 10:51 > > > > To: Paul Kyzivat (pkyzivat); siprec@ietf.org; Elwell, John > > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe Hildebrand > > > > (jhildebr) > > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > > > John, > > > > > > > > Sorry for the lengthy mail but it contains lot of analysis and=20 > > > > reasoning for this id approach. > > > > > > > > Adding to Paul's point, I wish to give more background and > > > reason for > > > > these globally unique id. Initially I had the impression that=20 > > > > the single unique id (RS dialog-id) in the recording (session > > > level) and > > > > some relevant natural id for the rest of the element will > > serve the > > > > purpose. > > > > There are usecases where this assumption fails. Even I have > > > thought of > > > > > > > using "xml:id" instead of URN UUID to avoid long string but > > > xml:id may > > > > > > > not end up with unique value always. Our analysis for URN > > UUID for > > > > each level is as follows and please provide your input in case=20 > > > > id shall be > > > > tweaked: > > > > > > > > 1) Recording block: The reason for globally unique id is > > > that multiple > > > > > > > SRC with same id to single SRS. > > > > > > > > Topology: > > > > > > > > SRC1 SRC2 > > > > | | > > > > | ----(RS1-ID1)-----SRS1 > > > > | > > > > ---(RS2-ID1)------------------SRS1 > > > > > > > > In the above topology, it is possible for ID1 is generated by=20 > > > > both > > > > SRC1 and SRC2 at the same time. > > > > > > > > 2) group (CSG) block: Grouping mechanism (Hadriel > > session-id, Paul > > > > Jones > > > > Session-UUID) is outside the scope of SIPREC. URN UUID > > > abstracts the > > > > exact mechanism to SRS and provides the information only > > about the > > > > group of CS from SRC perspective. It possible that group may=20 > > > > span across multiple RS and It is up to SRS to group and view > > as single > > > > recording. > > > > Here, the single level id in the top will fail. The counter > > > argument > > > > is to force the single RS having complete CSG but it*may not* be > > > > possible in SRC implementation. Here, xml:id will not serve the=20 > > > > purpose > > > > > > > > 3) session (CS) block: At the immediate look, session > > falls exactly > > > > under recording block. Use case 3 of draft-ietf-siprec-req-09=20 > > > > illustrates where CS span across multiple RS. This > > > requirement calls > > > > for unique id in session by which these session shall be > > viewed as > > > > single CS even though there is no group exists among > > them. IMO, in > > > > case session should not have globally unique id, then it is > > > preferred > > > > to remove usecase 3 in the requirement. > > > > > > > > 4) participant block: It needs some id which may be AOR but > > > AOR is not > > > > > > > unique. IMO, xml:id may serve the purpose with session > > > unique id. The > > > > trick exists for participant who are not associated with > > > CS. We shall > > > > discuss and fine tune if required. > > > > > > > > 5) stream block: Label attribute shall be used as unique > > > value but RFC > > > > 4574 does not mandate label attribute has to be unique across=20 > > > > the dialog or CS and so, it may possible to change within RS and > > > > no normative statement to stop this implementation. IMO, > > > xml:id may serve > > > > > > > the purpose with session unique id. Here as well, We shall > > > discuss and > > > > > > > fine tune if required. > > > > > > > > 6) extensiondata block: This is tracked in the separate > > mail thread > > > > whether unique id is required or not. Let us close this > > as part of > > > > that mail thread. > > > > > > > > Including explicitly Hadriel, Peter, Joe in this mail > > > thread as they > > > > have different view on this ID mechanism. > > > > > > > > I had offline discussion with Hadriel in Prague after > > > SIPREC meeting > > > > and my understanding of his major concern is that how SRS > > > will be able > > > > > > > to design the database in case partial update does not have > > > recording > > > > (top) id information. I'll put more thought processing to close=20 > > > > Hadriel concern of how top id has to be tracked in case > > > partial update > > > > > > > by which SRS implementation will be simplified in terms of > > > aggregation > > > > > > > maintenance. > > > > > > > > Thanks > > > > Partha > > > > > > > > -----Original Message----- > > > > From: siprec-bounces@ietf.org > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > > > (pkyzivat) > > > > Sent: Thursday, April 07, 2011 12:33 AM > > > > To: siprec@ietf.org > > > > Subject: Re: [siprec] Partial updates and identifiers > > > > > > > > John, > > > > > > > > For the moment we have proposed that the ids be conveyed in > > > the form > > > > of URIs that are globally unique, and specifically that > > > they be UUID > > > > URNs. > > > > There is no dependency on the particular form of the URI, but=20 > > > > specifying they must be UUID URNs makes it possible to > > perform some > > > > internal optimizations for storage. > > > > > > > > The UUID URN is a pretty inefficient encoding. A UUID can > > > be expressed > > > > > > > in 32 bits, so we could consider retaining UUIDs but alter the=20 > > > > encoding if its really an issue. However I am far from > > > convinced that > > > > the size of the IDs is going to be a major issue in the > > > overall size > > > > of messages, so I think its probably premature to worry about it. > > > > > > > > Because the ids can be expressed in 32 bits, the SRC and > > > SRS can store > > > > > > > them internally that way, thus reducing the runtime cost of=20 > > > > maintaining the data. > > > > > > > > The use of unique ids is a significant part of the overall > > > approach to > > > > > > > formatting updates. If somebody has a different concept > > in mind it > > > > could be useful to have an alternative proposal for the > > > format. If we > > > > had two worked out approaches we could compare the > > > tradeoffs in each. > > > > > > > > Thanks, > > > > Paul > > > > > > > > On 4/6/2011 10:24 AM, Elwell, John wrote: > > > > > Much of the discussion on draft-ram-metadata-format in Prague > > > > concerned the mechanism for performing partial updates and > > > the use of > > > > identifiers. The draft permits partial updates by allowing > > > individual > > > > objects (e.g., CS, participant, media stream) to be sent > > > with updated > > > > content, without having to send again other objects that have=20 > > > > not changed. So, for example, in a large conference, it would > > > be possible > > > > to add or modify an individual participant object without > > having to > > > > send all the other participant objects again. I do not recall=20 > > > > any opposition to this basic principle. > > > > > > > > > > However, to achieve this, every object requires an > > > > identifier, and it > > > > was asserted that these identifiers need to be globally > > > unique for all > > > > > > > time. Although this might be efficient for updating an=20 > > > > individual object, when sending many objects (e.g., at the start > > > > of a > > > CS or when > > > > refreshing the entire metadata), this can make the metadata very > > > > bulky. > > > > It depends, of course, on the format of the identifiers, > > and it was > > > > stated that there could be alternatives to UUID. > > Nevertheless, some > > > > people had concerns. These concerns also extended to the > > > impact on the > > > > > > > database where metadata is stored, since it might not be > > > feasible to > > > > convert to a database-friendly mechanism for linking > > > objects together. > > > > > > > > > > One alternative proposal during the meeting was to have a=20 > > > > > single > > > > unique identifier at the top level (for the RS) and use local=20 > > > > identifiers for other objects. Thus when updating a single > > > object, it > > > > would be necessary to include the top level identifier as > > > well as one > > > > or more local identifiers. However, there were also concerns=20 > > > > this might not fulfil actual or perceived future requirements. > > > > > > > > > > Please continue discussion on this. > > > > > > > > > > John (as chair) > > > > > _______________________________________________ > > > > > siprec mailing list > > > > > siprec@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > > _______________________________________________ > > > > siprec mailing list > > > > siprec@ietf.org > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From rmohanr@cisco.com Tue Apr 19 03:31:10 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 10CF5E06BB for ; Tue, 19 Apr 2011 03:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.282 X-Spam-Level: X-Spam-Status: No, score=-10.282 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v13e18atApm2 for ; Tue, 19 Apr 2011 03:31:08 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfc.amsl.com (Postfix) with ESMTP id 0D14AE0665 for ; Tue, 19 Apr 2011 03:31:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=9735; q=dns/txt; s=iport; t=1303209068; x=1304418668; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=pNYmgixTcYK4XpB5ksK/54NCQV5P+OBlMLi2yvnFryo=; b=ftVD+jrcXYLoyLSLHaaPRtbnoXwtmseRxwiyStMMyAjp6x4mjz4MWdbo giMQQaHlYEsJpJ7Y2hgsv30lKg160M+F7A68QBkIMuTSwp/4mabG0A55d ciOd3G5RyA3dJy9MHwBt/sG71uRl6o6EfiQTd9xd5z7vFwuOuhAAywPph A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtsAABVjrU2Q/khMgWdsb2JhbACXI44GFAEBFiYlqFeca4VxBIVljCQ X-IronPort-AV: E=Sophos;i="4.64,239,1301875200"; d="scan'208";a="84188112" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 19 Apr 2011 10:31:07 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3JAV6qt026212; Tue, 19 Apr 2011 10:31:06 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, 19 Apr 2011 16:01:05 +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, 19 Apr 2011 16:01:03 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD06133966@XMB-BGL-417.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] comments on draft-ram-siprec-metadata-04 Thread-Index: Acv0kBVIJHb7ZeT6Szm6WV4C4fEO8gAfxgZQAltX3dA= References: <21866C7FE177A4449B9136B5B24B1B130BC011290A@EXMBXCLUS01.citservers.local> <21866C7FE177A4449B9136B5B24B1B130BC011294A@EXMBXCLUS01.citservers.local> <35BCE99A477D6A4986FB2216D8CF2CFD05DD8C0C@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD05EF92EF@XMB-BGL-417.cisco.com> <4D9CBD8C.4010901@cisco.com> From: "Ram Mohan R (rmohanr)" To: "Parthasarathi R (partr)" , "Paul Kyzivat (pkyzivat)" , , "Elwell, John" X-OriginalArrivalTime: 19 Apr 2011 10:31:05.0798 (UTC) FILETIME=[E397FE60:01CBFE7C] Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 19 Apr 2011 10:31:10 -0000 Partha, I agree with your concern here. John, Are you ok with retaining the below relation in the model, If yes we can close this open item of the model +-------------------------------+ 1 | Recording Session (RS) |---------------+ +-------------------------------+ | |1..* |1..* | | | | |0..* |0..* | +--------------+ +-----------------+ | |Communication | | Communication | 1 |=20 | Session (CS) |----------| Session (CS) |---| | Group |0..1 1..*| | | 0..* +----------+ +--------------+ +-----------------+ |------|Extension | 1| | 0..* |1..* | | Data | | | 2..* |0..* | +----------+ 0..*| +---------+ |Extension| =20 | Data | +---------+ Regards, Ram > -----Original Message----- > From: Parthasarathi R (partr) > Sent: Thursday, April 07, 2011 4:07 PM > To: Paul Kyzivat (pkyzivat); siprec@ietf.org; Ram Mohan R (rmohanr); > Elwell, John > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 >=20 > John/Ram, >=20 > I see the issue without direct link between RS and CSG. It may be tough > to correlate CSG to RS in SRS implementation. This issue is raised by > Hadriel in terms of having single unique id for metadata format draft. > I explained his concern in "Partial updates and identifiers" mail > thread. >=20 > Also another issue: SRS may be interested in knowing list of associated > RS for a given CSG. >=20 > Thanks > Partha >=20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Paul Kyzivat (pkyzivat) > Sent: Thursday, April 07, 2011 12:53 AM > To: siprec@ietf.org > Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 >=20 > John, >=20 > I've been thinking about how everything relates to the RS, and that > maybe we should make some more major changes. >=20 > What I'm thinking is that none of the elements have a direct > relationship to RS. Rather, each element is ultimately constructed as a > time series of values delivered in updates. Its the updates that have a > relationship to a RS - the one they are delivered in. That allows the > possibility that not all the updates come from the same RS. >=20 > I haven't drawn a model diagram here because the concept is still > fuzzy. > Its a trial balloon - to see what others think. >=20 > Thanks, > Paul >=20 > On 4/6/2011 11:47 AM, Elwell, John wrote: > > Ram, > > > > I am not sure this answers my question. In the model you drew below, > a CSG has both a direct relationship with an RS and an indirect > relationship (via a CS). I was questioning whether we could remove the > direct relationship, on the basis that the indirect relationship is > sufficient. > > > > John (as individual) > > > > > >> -----Original Message----- > >> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > >> Sent: 06 April 2011 15:52 > >> To: Elwell, John; Scott Orton; Charles Eckel (eckelcu); > Parthasarathi > >> R (partr); siprec@ietf.org > >> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > >> > >> Hi John, > >> > >> Yes We have an indirect relationship in the current model. However > in > >> the current model it is REQUIRED to have a CSG as CS is connected to > >> RS through CSG. However not all use cases would need CSG, IOW CSG > has > >> to be optional and there should be direct association from CS to RS > >> even when CSG is absent. > >> > >> With the below associations we will have: > >> - An instance of RS can have Zero or more CSG blocks. > >> - An instance of RS can have Zero or more CS blocks. > >> - If a CSG is present it will have 1 or more CS. > >> - Each CS can be associated with Zero or 1 CSG. > >> > >> Let me know if you have any concerns. > >> > >> Regards, > >> Ram > >> > >>> -----Original Message----- > >>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > >>> Sent: Wednesday, April 06, 2011 6:16 PM > >>> To: Ram Mohan R (rmohanr); Scott Orton; Charles Eckel (eckelcu); > >>> Parthasarathi R (partr); siprec@ietf.org > >>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > >>> > >>> I am OK in principle, but I wonder whether there really > >> needs to be a > >>> relationship between CSG and RS. Isn't that relationship an > indirect > >>> relationship via CS? > >>> > >>> John (as individual) > >>> > >>> > >>>> -----Original Message----- > >>>> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > >>>> Sent: 03 April 2011 18:13 > >>>> To: Scott Orton; Elwell, John; Charles Eckel (eckelcu); > >>>> Parthasarathi R (partr); siprec@ietf.org > >>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > >>>> > >>>> Scott, > >>>> > >>>> I am ok to make this change to the model. I would like to > >> hear from > >>>> others if they have any issues in incorporating this change in the > >>>> model. > >>>> > >>>> The updated portion of the model will look like > >>>> > >>>> > >>>> +-------------------------------+ 1 > >>>> | Recording Session (RS) |---------------+ > >>>> +-------------------------------+ | > >>>> | 1..* |1..* | > >>>> | | | > >>>> | 0..* |0..* | > >>>> +--------------+ +-----------------+ | > >>>> |Communication | | Communication | 1 | > >>>> | Session (CS) |----------| Session (CS) |---| > >>>> | Group |0..1 1..*| | | 0..* > >> +----------+ > >>>> +--------------+ +-----------------+ > >> |------|Extension > >> | > >>>> 1| | 0..* |1..* | | Data > >> | > >>>> | | 2..* |0..* | > >> +----------+ > >>>> 0..*| > >>>> +---------+ > >>>> |Extension| > >>>> | Data | > >>>> +---------+ > >>>> > >>>> The only change in the association is : > >>>> A CS MUST be associated with zero or one CS-Group > >>>> > >>>> Rest of the associations remain same. Further the association > >>>> between CS and RS remains same as what is between CS-Group and RS. > >>>> > >>>> Comments ? > >>>> > >>>> Regards, > >>>> Ram > >>>> > >>>>> -----Original Message----- > >>>>> From: siprec-bounces@ietf.org > >> [mailto:siprec-bounces@ietf.org] On > >>>>> Behalf Of Scott Orton > >>>>> Sent: Friday, April 01, 2011 12:18 AM > >>>>> To: Elwell, John; Charles Eckel (eckelcu); Parthasarathi R > >> (partr); > >>>>> siprec@ietf.org > >>>>> Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 > >>>>> > >>>>> John, > >>>>> Thanks for the information. > >>>>> > >>>>> In that case I would like to see the CS group be > >> made optional. > >>>>> Rather than the CS pointing to the CS Group, I would like to > >>> suggest > >>>>> that the CS point to the RS and have the CS group stand > >>>> alone where it > >>>>> would just have its own ID and then a list of CS ids that belong > >> to > >>>> the > >>>>> group. > >>>>> > >>>>> Scott > >>>>> > >>>>> -----Original Message----- > >>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > >>>>> Sent: Thursday, March 31, 2011 11:50 AM > >>>>> To: Scott Orton; Charles Eckel (eckelcu); Parthasarathi > >> R (partr); > >>>>> siprec@ietf.org > >>>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > >>>>> > >>>>> Scott, > >>>>> > >>>>> Some folks wanted to be able to group related CSs together > >>>> (e.g., a CS > >>>>> between a customer and an agent and a second CS > >> resulting from the > >>>>> customer being transferred to a second agent). I will > >> leave it to > >>>> those > >>>>> folks to add to this. > >>>>> > >>>>> John (chair hat on) > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Scott Orton [mailto:sorton@broadsoft.com] > >>>>>> Sent: 31 March 2011 17:43 > >>>>>> To: Elwell, John; Charles Eckel (eckelcu); Parthasarathi R > >>>>>> (partr); siprec@ietf.org > >>>>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > >>>>>> > >>>>>> John, Charles, Partha, > >>>>>> I have a question. What is the purpose of the CS Group? I do > >>>>>> not see it adding anything to the metadata. To me it seems that > >>>>>> the whole purpose of the metadata is to describe the recording > >>>>>> session to the SRS. Looking at the requirements I see 3 > >>>>>> relationships that the spec is attempting to describe: > >>>>>> > >>>>>> A one to one relationship - one communication session to one > >>>>>> recording session A one to many relationship - one communication > >>>>>> session with multiple Recording sessions > >>>>>> - one Recording session made up of > >>>>>> multiple communications sessions > >>>>>> > >>>>>> The current metadata format allows all of these and I do not see > >>>>>> what the group is adding. > >>>>>> > >>>>>> Regards, > >>>>>> Scott > >>>>>> > >> > > _______________________________________________ > > siprec mailing 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 partr@cisco.com Tue Apr 19 03:31:26 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CCF7FE06BB for ; Tue, 19 Apr 2011 03:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.517 X-Spam-Level: X-Spam-Status: No, score=-9.517 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zEpGCpNo5DFG for ; Tue, 19 Apr 2011 03:31:20 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfc.amsl.com (Postfix) with ESMTP id 32344E0665 for ; Tue, 19 Apr 2011 03:31:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=17968; q=dns/txt; s=iport; t=1303209080; x=1304418680; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=f28UsCV3ISTXwUI7bMi+XjHPGsUjuTNCGRY1uoMeSGo=; b=hfUVVwsiIlGyGebg2waOLAVfI5azbXxZni1F/GrywTgXTB74WFCxPYb0 W/jIWEdpl8I8oOHIrX3Ge+602YrJ7L/Fv4+gsjf6yJyxe1LJrH8ncT1ee Ld4MELnys9hSTMAIrohuFmpGFpapd7nW9RPNAnOUOvy+bXyur5PO/Tl+Q s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtsAABVjrU2Q/khNgWdsb2JhbACXI44GFAEBFiYliG+faJxrhXEEhWWMJA X-IronPort-AV: E=Sophos;i="4.64,239,1301875200"; d="scan'208";a="84188192" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 19 Apr 2011 10:31:16 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3JAVDek018956; Tue, 19 Apr 2011 10:31:15 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 19 Apr 2011 16:01:15 +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, 19 Apr 2011 16:01:14 +0530 Message-ID: In-Reply-To: <48384EF2-73DD-4ECA-A87E-93847E995E80@voxeo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] extensionData in XML Thread-Index: Acv4X3wDgs8wZodKRU6y7lcfqyT99AGAQFEw References: <4D9CDFC0.9070300@cisco.com> <48384EF2-73DD-4ECA-A87E-93847E995E80@voxeo.com> From: "Parthasarathi R (partr)" To: "Dan Burnett" , "Paul Kyzivat (pkyzivat)" , "Leon Portman" , "Ken Rehor (krehor)" X-OriginalArrivalTime: 19 Apr 2011 10:31:15.0243 (UTC) FILETIME=[E9392FB0:01CBFE7C] Cc: siprec@ietf.org Subject: Re: [siprec] extensionData in XML X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 19 Apr 2011 10:31:27 -0000 Dan & all, Sorry for the late reply. Thanks for sharing your XML experience. tag is provided as extensions to SIPREC metadata. The current approach allows to ignore the extension-data in case SRS does not understand.=20 I have added few extensiondata as a note of this mail which were discussed during earlier SIPREC interim meeting. The open question here is whether the extension-data has to be passed every time (during partial-update) within metadata XML tag (participant, session) update or it is enough to send only when extension-data changes. Partial update of any specific XML elements needs unique id. RFC 5261 recommends to use xml:id or type-id as unique attribute.=20 The following example illustrate three different mechanism for extensiondata: Extensiondata as separate metadata block: (Current format in the draft - works for partial update, URN UUID is used in all metadata block as of now) sip:alice@cisco.com Extensiondata as separate metadata block using xml:id:(Id reduction) sip:alice@cisco.com Extensiondata as an extension within metadata block: (Ignore the attribute but needs to be passed in each partial updated) Example: =20 sip:alice@cisco.com Please let me know which best suites SIPREC metadata. Including Leon & Ken explicitly because they provides lot of Extension data attributes during the discussion of metadata model. I'm fine with any of the above approach. Thanks Partha Note: End point information: ip/port, device id (MAC address), DN (used for the call, in case of multiline).=20 Device type: external, station, IVR, routing point, QUEUE, Gateway, MCU, Operator, etc Participant Role: caller, called, added, last_redirecting, redirecting, conferencing, queing, redirected AgentId, OSLogin -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Dan Burnett Sent: Monday, April 11, 2011 9:15 PM To: Paul Kyzivat (pkyzivat) Cc: siprec@ietf.org Subject: Re: [siprec] extensionData in XML As someone who works quite a bit with XML, I'll point out that there is an important distinction between data for extensibility and expected application-specific data. As an example of the latter, EMMA [1] is an XML format for representing the input of a user (human being, commonly) to an automated system, by speech, gesture, pen, etc. Since the way an input is interpreted is dependent upon its intended use, there was a need for a designated application-specific section to represent the semantics (meaning) of the input. To make it easier for machine consumers of this format that may be seeking the semantics, there is a designated element "interpretation" =20 that holds this information. The contents of this element are arbitrary XML in an application-specific XML namespace. On the other hand, every XML specification I've worked on in W3C has =20 needed a way for implementers to innovate via extensions. =20 Traditionally this is handled via custom elements and attributes in an implementer-specific namespace to avoid name collision with the standard elements and attributes. Since these true innovation extensions can occur anywhere, there is no specific XML element established in most specifications for "extensions". Instead, the specification defines the expected behavior of a conformant processor upon encountering elements and attributes outside of the specification's standard namespace. The nice thing about this approach is that allows for innovation in a way that does not cause name collision but which could become part of the standard in the future (and be moved into the standard's namespace). For the specifications I worked on, we always required that a conformant processor had to do the behavior defined in the specification when it received a conformant document but that the behavior of the processor when it encountered non-standard elements and attributes was at its own discretion -- it could process the attributes, ignore them, or report an error, as it deemed appropriate. So the real question for us here is whether these extension elements are *extensions* (which do not require a custom element/location) or *expected application-specific information* (which can benefit from custom elements and prescribed locations in the XML tree). -- dan [1] http://www.w3.org/TR/emma/ On Apr 6, 2011, at 5:48 PM, Paul Kyzivat wrote: > > > On 4/6/2011 8:57 AM, Elwell, John wrote: >> Yes, I would be keen to hear Peter's or other opinions, but one other >> point. One of the properties of XML is that it is human- readable.=20 >> Having extension data as a child element of the element representing=20 >> the object to which it applies seems, in my opinion, to make it more=20 >> readable. Having extension data as a separate element, with a link to >> the element to which it applies, seems hard for a human reader,=20 >> particularly if the link is a long, random string. > > IMO human readability of the xml is a secondary/tertiary concern. > (SIP is in theory readable, but real sip on the wire tends to be=20 > difficult to read due to need to match up non-ergonomic numeric=20 > addresses and tags from one message to another.) > > I'm inclined to agree it would be better to embed extensions into the=20 > basic elements, but not primarily due to readability. IMO extensions=20 > should function as much like the predefined parts as possible.=20 > (Today's extension may become common usage tomorrow.) > > I just don't know enough xml to define this "correctly". > > Thanks, > Paul > >> John (as individual) >> >> >>> -----Original Message----- >>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] >>> Sent: 06 April 2011 10:16 >>> To: Elwell, John; Hadriel Kaplan >>> Cc: siprec@ietf.org; Jain, Rajnish; Peter Saint-Andre (psaintan) >>> Subject: RE: [siprec] extensionData in XML >>> >>> John, >>> >>> Please read inline >>> >>> Thanks >>> Partha >>> >>> -----Original Message----- >>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>> Sent: Wednesday, April 06, 2011 2:02 PM >>> To: Parthasarathi R (partr); Hadriel Kaplan >>> Cc: siprec@ietf.org; Jain, Rajnish >>> Subject: RE: [siprec] extensionData in XML >>> >>> I already posted on this topic on the other thread. Partha states=20 >>> below an additional motivation for handling extension data in the=20 >>> way specified in the current I-D. My counter argument is that anyone >>> specifying particular extension data could specify the expected=20 >>> behaviour when extension data is present in an object and then=20 >>> absent when that object is updated. For some types of metadata it=20 >>> could be that absence means it no longer applies, and for other=20 >>> types of metadata it could be that absence means it has not changed. >>> >>> Currently, metadata format draft XML element is written=20 >>> with the basics that "it is no longer applies" in case specific=20 >>> element is absent in the update. The question is how the information >>> of extensiondata absence means "it is no longer applies" or "it has=20 >>> not changed" has to be passed between SRC and SRS. Here, there is a=20 >>> need of common understanding between SRC and SRS or else the=20 >>> information will be misunderstand even though both parties=20 >>> understand the specific extension. >>> >>> The current extensiondata is taken the route of all other metadata=20 >>> block XML element definition. There may be better way to represent=20 >>> in extensiondata XML element apart from creating new metadata block=20 >>> with URN UUID. I'm including Peter for his advise on XML=20 >>> front. >>> >>> The latter approach would avoid the need for repeating large=20 >>> quantities of metadata each time there is a minor change to an=20 >>> object. >>> >>> John (as individual) >>> >>>> -----Original Message----- >>>> From: siprec-bounces@ietf.org >>>> [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi >>> R (partr) >>>> Sent: 03 April 2011 19:46 >>>> To: Hadriel Kaplan >>>> Cc: siprec@ietf.org; Jain, Rajnish >>>> Subject: Re: [siprec] extensionData in XML >>>> >>>> Hadriel, >>>> >>>> I guess we have common understaning to the extend that the >>> intention >>>> is to send some extensiondata (Unknown) attribute by SRC >>> which may or >>>> may not understand by SRS and also for the usage of xs:any as the=20 >>>> solution. Few stuff are missing in yours proposal w.r.t >>> partial data >>>> passing of extensiondata: >>>> >>>> The question is whether there is a need to pass the extension data=20 >>>> during every time the corresponding metadata block is passed or=20 >>>> updated. For example, CS metadata block sends extension >>> data specific >>>> to call center data like Agent is remote or local, agent or >>> customer >>>> initiated call (direction) during the CS block creation >>> (INVITE) and >>>> these constant information in extensiondata is not required to be=20 >>>> passed in each update of CS metadata like adding video >>> stream in the >>>> mid-session. >>>> >>>> The current model allows to pass extensiondata only during >>> the initial >>> >>>> CS block creation and there is no need to update or resend while CS >>>> block is getting updated with other CS information. IMO, >>> The current >>>> extensiondata mechanism is required as SIPREC puts lot of >>> call centre >>>> specific attributes proposed during metadata model draft review as=20 >>>> outside the scope of SIPREC and most of the attributes >>> mentioned are >>>> constant within the scope of session. >>>> >>>> Also, it is possible to pass update only extension data within RS=20 >>>> session without impacting parent element. Please let me >>> know your and >>>> others opinion whethter it is fine to continue with the current=20 >>>> extension-data element or to move xs:any element to each of the=20 >>>> metadata block. >>>> >>>> Thanks >>>> Partha >>>> ________________________________ >>>> >>>> From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] >>>> Sent: Sat 4/2/2011 6:19 PM >>>> To: Parthasarathi R (partr) >>>> Cc: Jain, Rajnish; siprec@ietf.org >>>> Subject: Re: [siprec] extensionData in XML >>>> >>>> >>>> >>>> Hi Partha, >>>> I think you're missing my point (or I'm missing yours) - you can do >>>> all of that without specifying an "extensionData" XML element. >>>> Unknown XML elements are simply ignored by the other side, so Cisco >>>> can add a "ciscoPrivateData" XML element wherever it wants >>> and send it >>> >>>> to an Acme; and that private element will be ignored by Acme while=20 >>>> everything else will continue to work. Which I think is >>> the behavior >>>> you want, right? >>>> >>>> -hadriel >>>> >>>> >>>> On Apr 1, 2011, at 10:37 AM, Parthasarathi R (partr) wrote: >>>> >>>>> Hadriel/Raj, >>>>> >>>>> Extensiondata XML is provided as per Metadata model >>>> extensiondata block. >>>>> During the initial discussion of metadata model draft, we >>>> realized that >>>>> lot of attributes specified for recording are call center >>>> specific or >>>>> specific domain related and it is outside the scope of IETF >>>> SIPREC but >>>>> it is required for those specific solution to work. >>>> Extensiondata XML >>>>> element helps to meet those requirement. >>>>> >>>>> Extensiondata is provided with URN UUID to pass or not pass=20 >>>>> independently in partial data. But it is open item whether >>>> extensiondata >>>>> has to be within specific metadatablock or not. >>>>> >>>>> Please read inline for more comments. >>>>> >>>>> Thanks >>>>> Partha >>>>> >>>>> -----Original Message----- >>>>> From: siprec-bounces@ietf.org >>>> [mailto:siprec-bounces@ietf.org] On Behalf >>>>> Of Jain, Rajnish >>>>> Sent: Friday, April 01, 2011 6:41 PM >>>>> To: Hadriel Kaplan; siprec@ietf.org >>>>> Subject: Re: [siprec] extensionData in XML >>>>> >>>>> There may be such motivation from how the CSTA standards >>>> are specified. >>>>> They have an element called privateData for each message. It is a=20 >>>>> placeholder for any non-standardized extensions. This could >>>> be legacy >>>>> and may not mean much for the modern text based protocols. >>>>> >>>>> I really didn't get the reason why is it not >>>> require for modern >>>>> text based protocols. This is more like generic param in >>>> SIP or xs:any >>>>> in XML. RFC 6120 is a new RFC which has the similar usage. >>>>> >>>>> >>>>> That said, I think you're right (this generally applies >>> to any text >>>>> based protocols and is the fundamental basis for forward/backward=20 >>>>> compatibility in such protocols). >>>>> >>>>> Raj >>>>> >>>>> >>>>> ----------------------------------------------------- >>>>> Please consider the environment before printing this email. >>>>> >>>>>> -----Original Message----- >>>>>> From: siprec-bounces@ietf.org >>> [mailto:siprec-bounces@ietf.org] On >>>>>> Behalf Of Hadriel Kaplan >>>>>> Sent: Thursday, March 31, 2011 8:43 PM >>>>>> To: siprec@ietf.org >>>>>> Subject: [siprec] extensionData in XML >>>>>> >>>>>> Howdy, >>>>>> With regards to the extensionData concept and XML, I have >>>> a few basic >>>>>> questions. I am by no means an XML expert so it could >>>> just be my lack >>>>> >>>>>> of knowledge which makes me confused. If so, just tell >>> me to RTFM. >>>>>> >>>>>> draft-ram-siprec-metadata-04 says in section 4.6: >>>>>> A recording metadata object contains additional data not >>>> specified >>>>>> as >>>>>> part of siprec. This is intended to accommodate >>> future standards >>>>>> track extensions, as well as vendor and user specific >>> extensions. >>>>>> The mechanism MUST provide a means of unambiguously >>>> distinguishing >>>>>> such extension data. >>>>>> >>>>>> What confuses me is I didn't think XML had to do such >>>> machinations to >>>>>> accommodate this need. I thought we could just specify >>> in our RFCs >>> >>>>>> that unknown XML elements and attributes MUST be >>> ignored, so that >>>>>> future RFCs could add them without having to leave >>>> specific "blob" XML >>>>> >>>>>> elements to carry such data. Or at least that's what >>> we've done so >>> >>>>>> far in SIP RFCs with XML bodies, afaik. >>>>>> namespace model that could be used to disambiguate proprietary=20 >>>>>> elements from standard ones. If both of those theories >>>> are correct, >>>>>> why do we need to define an extensionData element? >>>>>> >>>>>> -hadriel >>>>>> >>>>>> _______________________________________________ >>>>>> siprec mailing list >>>>>> siprec@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>> >>>>> DISCLAIMER: This e-mail may contain information that is >>>> confidential, >>>>> privileged or otherwise protected from disclosure. If you >>> are not an >>> >>>>> intended recipient of this e-mail, do not duplicate or >>>> redistribute it >>>>> by any means. Please delete it and any attachments and >>>> notify the sender >>>>> that you have received it in error. Unintended recipients >>>> are prohibited >>>>> from taking action on the basis of information in this >>> e-mail.E-mail >>> >>>>> messages may contain computer viruses or other defects, >>> may not be >>>>> accurately replicated on other systems, or may be >>>> intercepted, deleted >>>>> or interfered with without the knowledge of the sender or >>>> the intended >>>>> recipient. If you are not comfortable with the risks >>> associated with >>> >>>>> e-mail messages, you may decide not to use e-mail to >>>> communicate with >>>>> IPC. IPC reserves the right, to the extent and under >>> circumstances >>>>> permitted by applicable law, to retain, monitor and >>> intercept e-mail >>> >>>>> messages to and from its systems. >>>>> _______________________________________________ >>>>> siprec mailing 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 Tue Apr 19 05:33:07 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 03BC6E0691 for ; Tue, 19 Apr 2011 05:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105 X-Spam-Level: X-Spam-Status: No, score=-105 tagged_above=-999 required=5 tests=[AWL=1.599, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJTUQCPItKiE for ; Tue, 19 Apr 2011 05:33:05 -0700 (PDT) Received: from mail182.messagelabs.com (mail182.messagelabs.com [85.158.139.83]) by ietfc.amsl.com (Postfix) with SMTP id 0CB8DE068A for ; Tue, 19 Apr 2011 05:33:01 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1303216380!5314667!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 18307 invoked from network); 19 Apr 2011 12:33:00 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-5.tower-182.messagelabs.com with SMTP; 19 Apr 2011 12:33:00 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id A95B61EB83EE; Tue, 19 Apr 2011 14:33:00 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 19 Apr 2011 14:33:00 +0200 From: "Elwell, John" To: "Ram Mohan R (rmohanr)" , "Parthasarathi R (partr)" , "Paul Kyzivat (pkyzivat)" , "siprec@ietf.org" Date: Tue, 19 Apr 2011 14:32:59 +0200 Thread-Topic: [siprec] comments on draft-ram-siprec-metadata-04 Thread-Index: Acv0kBVIJHb7ZeT6Szm6WV4C4fEO8gAfxgZQAltX3dAABC5+YA== Message-ID: References: <21866C7FE177A4449B9136B5B24B1B130BC011290A@EXMBXCLUS01.citservers.local> <21866C7FE177A4449B9136B5B24B1B130BC011294A@EXMBXCLUS01.citservers.local> <35BCE99A477D6A4986FB2216D8CF2CFD05DD8C0C@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD05EF92EF@XMB-BGL-417.cisco.com> <4D9CBD8C.4010901@cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD06133966@XMB-BGL-417.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD06133966@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] comments on draft-ram-siprec-metadata-04 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 19 Apr 2011 12:33:07 -0000 Ram, I am not quite sure whether that is an issue or not. If we go for a single = unique identifier, I suspect it would need to identify a CS, not an RS. In = fact I was waiting to hear more from Paul on his assertion below, that perh= aps none of the elements has a direct relationship with an RS. I am OK leav= ing the relationship in for now. It might become clearer when we resolve th= e question of identifiers.=20 John (as individual)=20 > -----Original Message----- > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com]=20 > Sent: 19 April 2011 11:31 > To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat);=20 > siprec@ietf.org; Elwell, John > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 >=20 > Partha, > I agree with your concern here. >=20 > John, > Are you ok with retaining the below relation in the model, If=20 > yes we can > close this open item of the model >=20 > +-------------------------------+ 1 > | Recording Session (RS) |---------------+ > +-------------------------------+ | > |1..* |1..* | > | | | > |0..* |0..* | > +--------------+ +-----------------+ | > |Communication | | Communication | 1 |=20 > | Session (CS) |----------| Session (CS) |---| > | Group |0..1 1..*| | | 0..* +----------+ > +--------------+ +-----------------+ |------|Extension | > 1| | 0..* |1..* | | Data | > | | 2..* |0..* | +----------+ > 0..*| > +---------+ > |Extension| =20 > | Data | > +---------+ >=20 > Regards, > Ram >=20 > > -----Original Message----- > > From: Parthasarathi R (partr) > > Sent: Thursday, April 07, 2011 4:07 PM > > To: Paul Kyzivat (pkyzivat); siprec@ietf.org; Ram Mohan R (rmohanr); > > Elwell, John > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > >=20 > > John/Ram, > >=20 > > I see the issue without direct link between RS and CSG. It may be > tough > > to correlate CSG to RS in SRS implementation. This issue is=20 > raised by > > Hadriel in terms of having single unique id for metadata=20 > format draft. > > I explained his concern in "Partial updates and identifiers" mail > > thread. > >=20 > > Also another issue: SRS may be interested in knowing list of > associated > > RS for a given CSG. > >=20 > > Thanks > > Partha > >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Paul Kyzivat (pkyzivat) > > Sent: Thursday, April 07, 2011 12:53 AM > > To: siprec@ietf.org > > Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 > >=20 > > John, > >=20 > > I've been thinking about how everything relates to the RS, and that > > maybe we should make some more major changes. > >=20 > > What I'm thinking is that none of the elements have a direct > > relationship to RS. Rather, each element is ultimately=20 > constructed as > a > > time series of values delivered in updates. Its the updates=20 > that have > a > > relationship to a RS - the one they are delivered in. That=20 > allows the > > possibility that not all the updates come from the same RS. > >=20 > > I haven't drawn a model diagram here because the concept is still > > fuzzy. > > Its a trial balloon - to see what others think. > >=20 > > Thanks, > > Paul > >=20 > > On 4/6/2011 11:47 AM, Elwell, John wrote: > > > Ram, > > > > > > I am not sure this answers my question. In the model you=20 > drew below, > > a CSG has both a direct relationship with an RS and an indirect > > relationship (via a CS). I was questioning whether we could=20 > remove the > > direct relationship, on the basis that the indirect relationship is > > sufficient. > > > > > > John (as individual) > > > > > > > > >> -----Original Message----- > > >> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > >> Sent: 06 April 2011 15:52 > > >> To: Elwell, John; Scott Orton; Charles Eckel (eckelcu); > > Parthasarathi > > >> R (partr); siprec@ietf.org > > >> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > >> > > >> Hi John, > > >> > > >> Yes We have an indirect relationship in the current=20 > model. However > > in > > >> the current model it is REQUIRED to have a CSG as CS is connected > to > > >> RS through CSG. However not all use cases would need CSG, IOW CSG > > has > > >> to be optional and there should be direct association=20 > from CS to RS > > >> even when CSG is absent. > > >> > > >> With the below associations we will have: > > >> - An instance of RS can have Zero or more CSG blocks. > > >> - An instance of RS can have Zero or more CS blocks. > > >> - If a CSG is present it will have 1 or more CS. > > >> - Each CS can be associated with Zero or 1 CSG. > > >> > > >> Let me know if you have any concerns. > > >> > > >> Regards, > > >> Ram > > >> > > >>> -----Original Message----- > > >>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > >>> Sent: Wednesday, April 06, 2011 6:16 PM > > >>> To: Ram Mohan R (rmohanr); Scott Orton; Charles Eckel (eckelcu); > > >>> Parthasarathi R (partr); siprec@ietf.org > > >>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > >>> > > >>> I am OK in principle, but I wonder whether there really > > >> needs to be a > > >>> relationship between CSG and RS. Isn't that relationship an > > indirect > > >>> relationship via CS? > > >>> > > >>> John (as individual) > > >>> > > >>> > > >>>> -----Original Message----- > > >>>> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > >>>> Sent: 03 April 2011 18:13 > > >>>> To: Scott Orton; Elwell, John; Charles Eckel (eckelcu); > > >>>> Parthasarathi R (partr); siprec@ietf.org > > >>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > >>>> > > >>>> Scott, > > >>>> > > >>>> I am ok to make this change to the model. I would like to > > >> hear from > > >>>> others if they have any issues in incorporating this change in > the > > >>>> model. > > >>>> > > >>>> The updated portion of the model will look like > > >>>> > > >>>> > > >>>> +-------------------------------+ 1 > > >>>> | Recording Session (RS) |---------------+ > > >>>> +-------------------------------+ | > > >>>> | 1..* |1..* | > > >>>> | | | > > >>>> | 0..* |0..* | > > >>>> +--------------+ +-----------------+ | > > >>>> |Communication | | Communication | 1 | > > >>>> | Session (CS) |----------| Session (CS) |---| > > >>>> | Group |0..1 1..*| | | 0..* > > >> +----------+ > > >>>> +--------------+ +-----------------+ > > >> |------|Extension > > >> | > > >>>> 1| | 0..* |1..* | =20 > | Data > > >> | > > >>>> | | 2..* |0..* | > > >> +----------+ > > >>>> 0..*| > > >>>> +---------+ > > >>>> |Extension| > > >>>> | Data | > > >>>> +---------+ > > >>>> > > >>>> The only change in the association is : > > >>>> A CS MUST be associated with zero or one CS-Group > > >>>> > > >>>> Rest of the associations remain same. Further the association > > >>>> between CS and RS remains same as what is between CS-Group and > RS. > > >>>> > > >>>> Comments ? > > >>>> > > >>>> Regards, > > >>>> Ram > > >>>> > > >>>>> -----Original Message----- > > >>>>> From: siprec-bounces@ietf.org > > >> [mailto:siprec-bounces@ietf.org] On > > >>>>> Behalf Of Scott Orton > > >>>>> Sent: Friday, April 01, 2011 12:18 AM > > >>>>> To: Elwell, John; Charles Eckel (eckelcu); Parthasarathi R > > >> (partr); > > >>>>> siprec@ietf.org > > >>>>> Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 > > >>>>> > > >>>>> John, > > >>>>> Thanks for the information. > > >>>>> > > >>>>> In that case I would like to see the CS group be > > >> made optional. > > >>>>> Rather than the CS pointing to the CS Group, I would like to > > >>> suggest > > >>>>> that the CS point to the RS and have the CS group stand > > >>>> alone where it > > >>>>> would just have its own ID and then a list of CS ids=20 > that belong > > >> to > > >>>> the > > >>>>> group. > > >>>>> > > >>>>> Scott > > >>>>> > > >>>>> -----Original Message----- > > >>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > >>>>> Sent: Thursday, March 31, 2011 11:50 AM > > >>>>> To: Scott Orton; Charles Eckel (eckelcu); Parthasarathi > > >> R (partr); > > >>>>> siprec@ietf.org > > >>>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > >>>>> > > >>>>> Scott, > > >>>>> > > >>>>> Some folks wanted to be able to group related CSs together > > >>>> (e.g., a CS > > >>>>> between a customer and an agent and a second CS > > >> resulting from the > > >>>>> customer being transferred to a second agent). I will > > >> leave it to > > >>>> those > > >>>>> folks to add to this. > > >>>>> > > >>>>> John (chair hat on) > > >>>>> > > >>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: Scott Orton [mailto:sorton@broadsoft.com] > > >>>>>> Sent: 31 March 2011 17:43 > > >>>>>> To: Elwell, John; Charles Eckel (eckelcu); Parthasarathi R > > >>>>>> (partr); siprec@ietf.org > > >>>>>> Subject: RE: [siprec] comments on=20 > draft-ram-siprec-metadata-04 > > >>>>>> > > >>>>>> John, Charles, Partha, > > >>>>>> I have a question. What is the purpose of the CS Group? I > do > > >>>>>> not see it adding anything to the metadata. To me it=20 > seems that > > >>>>>> the whole purpose of the metadata is to describe the=20 > recording > > >>>>>> session to the SRS. Looking at the requirements I see 3 > > >>>>>> relationships that the spec is attempting to describe: > > >>>>>> > > >>>>>> A one to one relationship - one communication session to one > > >>>>>> recording session A one to many relationship - one > communication > > >>>>>> session with multiple Recording sessions > > >>>>>> - one Recording session=20 > made up of > > >>>>>> multiple communications sessions > > >>>>>> > > >>>>>> The current metadata format allows all of these and I do not > see > > >>>>>> what the group is adding. > > >>>>>> > > >>>>>> Regards, > > >>>>>> Scott > > >>>>>> > > >> > > > _______________________________________________ > > > siprec mailing 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@cisco.com Tue Apr 19 05:37:03 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 04512E06A7 for ; Tue, 19 Apr 2011 05:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.561 X-Spam-Level: X-Spam-Status: No, score=-109.561 tagged_above=-999 required=5 tests=[AWL=-0.762, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0T4vzobak+0 for ; Tue, 19 Apr 2011 05:37:00 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfc.amsl.com (Postfix) with ESMTP id 2F85BE0691 for ; Tue, 19 Apr 2011 05:37:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=19306; q=dns/txt; s=iport; t=1303216620; x=1304426220; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=X7+1yMUAZrfpoAZ30pCX4MRtykOe+x/cEOnAvsgxDDE=; b=Lzly4qwP1P+SE3vV3RTVLoWVZIyG6E1llRvWIutb7p3W80HCVzcHkbBD YfSmqydh1YJY2Fdq+DqNPobOCY00SFx2C2fPm3bby/6a8bhMJxoIFZurz wHYxvB5QqG4H8q6BmZ7EGXOm30VltESELwAEIkHuawvbemslFsvjirehz 0=; X-IronPort-AV: E=Sophos;i="4.64,239,1301875200"; d="scan'208";a="84208137" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 19 Apr 2011 12:36:59 +0000 Received: from [161.44.174.125] (dhcp-161-44-174-125.cisco.com [161.44.174.125]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3JCaw2v003127; Tue, 19 Apr 2011 12:36:58 GMT Message-ID: <4DAD81E9.8090801@cisco.com> Date: Tue, 19 Apr 2011 08:36:57 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Parthasarathi R (partr)" References: <4D9CB8E1.7030402@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Peter Saint-Andre \(psaintan\)" , siprec@ietf.org, "Joe Hildebrand \(jhildebr\)" Subject: Re: [siprec] Partial updates and identifiers X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 19 Apr 2011 12:37:03 -0000 On 4/19/2011 2:49 AM, Parthasarathi R (partr) wrote: > Hi all, > > As per the progress in another mail thread > (http://www.ietf.org/mail-archive/web/siprec/current/msg01864.html), > there is no known usecase wherein participant involved in RS but not > involved in CS directly. IOW, participant is always within CS. This > change in metadata model makes us to re-look whether participant shall > be unique id within CS (something like xml:id) rather than globally > unique id. > > The open question is whether participant in multiple CS within single RS > should have same id or not. Example: Alice acts as SRC and the scenario > is as follows: > > 1) Alice establish CS1 with Bob, RS is established between Alice& SRS, > CS1 details with Alice& Bob as participant is passed > 2) Bob transfer the session to Carol > 3) New CS2 is established between Alice& Carol, RS is updated with new > CS2 info having Alice& Carol as participants > > The open question are > > 1) At step 3, whether Alice MUST have the same unique id as in step 1 or > it is not mandatory? IMO it is at least *preferred* that there be a single Participant entity, with one id, for Alice in both CS. But I don't think we need mandate that - we can leave it as "quality of implementation". While it might be nice to mandate it, I think it would send us down a rat hole trying to figure out how to specify those cases where it must be the same and those where it need not be. Thanks, Paul > 2) If required to be unique across RS, whether xml:id serve the purpose? > > Thanks > Partha > > -----Original Message----- > From: Charles Eckel (eckelcu) > Sent: Tuesday, April 12, 2011 4:23 AM > To: Elwell, John; Parthasarathi R (partr); Paul Kyzivat (pkyzivat); > siprec@ietf.org > Cc: Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr); Hadriel > Kaplan > Subject: RE: [siprec] Partial updates and identifiers > > Hi John, > > I have attached the last e-mail I have from the thread in which I first > raised this issue. Unfortunately, I do not have the e-mail with the > ultimate agreement, but maybe someone else does or this will help prompt > some memories. > > Cheers, > Charles > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Elwell, John >> Sent: Monday, April 11, 2011 9:46 AM >> To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); siprec@ietf.org >> Cc: Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr); Hadriel >> Kaplan >> Subject: Re: [siprec] Partial updates and identifiers >> >> Partha, >> >> Thanks for reminding me - I now recall the discussion some >> weeks/months ago about the participants obtained from the conference >> event package. I was never particularly comfortable with the fact >> these were not considered part of the CS. While that might be correct >> if we consider the CS to be the SIP dialog between the SRC and the >> conference focus, taking a broader view of CS those participants > behind the focus could be considered part of the CS. I don't > particularly want to open up the old discussion if people are happy with > what we have, but something doesn't seem quite right to me. >> >> For example, if these "participants" are not considered part of the >> CS, and if we don't have specific information about their involvement >> in media streams, do they really merit being considered Participant > objects? >> >> In other words, two possible approaches are: >> >> 1) The CS extends only as far as the focus / mixer. The focus/mixer is > >> a "Participant" and the users behind the focus are not separate >> Participants but are just additional data associated with the >> focus/mixer Participant. The only Media Streams we are concerned with > are between the mixer and the SRC. >> >> 2) The CS extends beyond the focus/mixer to users learned via the >> conference event package, each of those users is a separate >> Participant object, and we are concerned with Media Stream objects >> that those participants send and receive. I am not sure how feasible > this approach is, because I am not sure that the SRC can obtain enough > information about media streams at users behind the focus/mixer. >> >> It seems the present solution is somewhere between the two, which is > why I am uncomfortable. >> >> Regards, >> >> John (as individual) >> >> >>> -----Original Message----- >>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] >>> Sent: 11 April 2011 10:29 >>> To: Elwell, John; Paul Kyzivat (pkyzivat); siprec@ietf.org >>> Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe Hildebrand >>> (jhildebr) >>> Subject: RE: [siprec] Partial updates and identifiers >>> >>> John, >>> >>> Please read inline. >>> >>> Thanks >>> Partha >>> >>> -----Original Message----- >>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>> Sent: Monday, April 11, 2011 2:11 PM >>> To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); >>> siprec@ietf.org >>> Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe Hildebrand >>> (jhildebr) >>> Subject: RE: [siprec] Partial updates and identifiers >>> >>> >>> >>>> -----Original Message----- >>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] >>>> Sent: 11 April 2011 08:35 >>>> To: Elwell, John; Paul Kyzivat (pkyzivat); siprec@ietf.org >>>> Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe Hildebrand >>>> (jhildebr) >>>> Subject: RE: [siprec] Partial updates and identifiers >>>> >>>> John, >>>> >>>> As I mentioned below, stream block will be unique within CS, (not >>>> required to be unique across multiple CS) and so, xml:id or >>> enhancing >>>> the normative statement of RFC 4574 label attribute to be unique >>>> within CS will serve the purpose. I'm fine with any of the above >>>> mentioned id. >>>> Please note that RFC 4574 "label" attribute is the nature >>> data for RS >>>> dialog. >>>> >>>> In case participant within CS, xml:id will serve the purpose but >>>> we need to get more clarity about participants who are not >>> part of CS but >>> >>>> within RS. >>> [JRE] If I understand the figure in section 3 of metadata-04 >>> correctly, a Participant can have a relationship with a CS, but no >>> direct relationship with an RS. >>> >>> Sorry, I mixed up my statement with the latest update of >>> making CSG optional. As per Sec 3 of metadata-04, participant has >>> direct relationship with CSG in case CS is left completely >>> unattached. In case CSG is optional, then participant will have >>> direct relationship with RS in case there is no relationship between > >>> CS and participant. >>> >>> >>> So a participant that does not have a relationship with a CS is >>> left completely unattached, unless it has a relationship with a >>> Media Stream (which always has a relationship with a CS). So to >>> summarize: >>> - a Participant can have a direct relationship with a CS; or >>> - a Participant can have an indirect relationship with a CS (via a >>> Media Stream); agreed >>> - a Participant can have no relationship with a CS, and therefore no > >>> relationship with an RS. >>> Do we really need this last case? >>> >>> I'm happy if the last case is not required because it >>> simplify the solution and there is no need of unique id for >>> participant. But SRS implementers may prefer to have relationship >>> with participant and RS. I wish more opinion before taking decision >>> whether to remove the last case >>> >>>> Because CS may span across different RS how about the >>> participant who >>>> are not part of CS? >>> [JRE] I don't understand the words "Because CS may span across >>> different RS", because in the rest of the sentence you are talking >>> about a Participant that is not part of a CS. >>> >>>> Ex: One of the user in the conference acts as SRC, fetch >>> participant >>>> info using conferene package and new RS is created during initial >>>> conference creation and hold&resume of a user within CS. >>> [JRE] I am not sure what you are trying to say here. I would >>> consider a user whose identity is obtained via a conference event >>> package as being part of the CS. >>> >>> I'm trying to give the example where participant is not >>> associated with CS directly but related to CSG (/RS). This scenario >>> was considered as a blocking in -03 version of metadata. I'm not >>> arguing to have this scenario but it is major concern for few folks. >>> >>> CS is between focus and UA, UA acts as SRC, UA receives the >>> participant info via conference event package but those participants > >>> are not related in CS directly (and only focus is related) but they >>> contributed for the mixed stream. >>> >>> That user is sending/receiving Media Streams that are part of a CS, > >>> or if it isn't sending/receiving Media Streams, what is the >>> relevance of that Participant? >>> >>> Mixed media stream from focus to UA belongs to the >>> Conference event package participants. There participant are not >>> directly involved as part of CS. Why would we create a >>> new RS for such a participant? >>> RS is not created for participant. Multiple RS shall be >>> created the same CS during the different time frame as shown below >>> >>> <-------------------CS1-------------> >>> <---RS1--> <---RS2------> >>> >>> CS1 is between UA (SRC) and focus whereas RS1, RS2 is between UA >>> (SRC) and SRS. Here tangling (conference event package) participant >>> has to be grouped together in RS1, RS2 by some means through given >>> metadata. The question whether this corner has to be solved ? >>> >>> >>> John (as individual) >>> >>> >>> >>>> >>>> Thanks >>>> Partha >>>> >>>> -----Original Message----- >>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>>> Sent: Friday, April 08, 2011 9:36 PM >>>> To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); >>> siprec@ietf.org >>>> Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe Hildebrand >>>> (jhildebr) >>>> Subject: RE: [siprec] Partial updates and identifiers >>>> >>>> Focusing just on participant and stream for the time being, >>> do these >>>> need to be unique across multiple CSs or not? >>>> >>>> John >>>> >>>>> -----Original Message----- >>>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] >>>>> Sent: 07 April 2011 10:51 >>>>> To: Paul Kyzivat (pkyzivat); siprec@ietf.org; Elwell, John >>>>> Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe Hildebrand >>>>> (jhildebr) >>>>> Subject: RE: [siprec] Partial updates and identifiers >>>>> >>>>> John, >>>>> >>>>> Sorry for the lengthy mail but it contains lot of analysis and >>>>> reasoning for this id approach. >>>>> >>>>> Adding to Paul's point, I wish to give more background and >>>> reason for >>>>> these globally unique id. Initially I had the impression that >>>>> the single unique id (RS dialog-id) in the recording (session >>>> level) and >>>>> some relevant natural id for the rest of the element will >>> serve the >>>>> purpose. >>>>> There are usecases where this assumption fails. Even I have >>>> thought of >>>> >>>>> using "xml:id" instead of URN UUID to avoid long string but >>>> xml:id may >>>> >>>>> not end up with unique value always. Our analysis for URN >>> UUID for >>>>> each level is as follows and please provide your input in case >>>>> id shall be >>>>> tweaked: >>>>> >>>>> 1) Recording block: The reason for globally unique id is >>>> that multiple >>>> >>>>> SRC with same id to single SRS. >>>>> >>>>> Topology: >>>>> >>>>> SRC1 SRC2 >>>>> | | >>>>> | ----(RS1-ID1)-----SRS1 >>>>> | >>>>> ---(RS2-ID1)------------------SRS1 >>>>> >>>>> In the above topology, it is possible for ID1 is generated by >>>>> both >>>>> SRC1 and SRC2 at the same time. >>>>> >>>>> 2) group (CSG) block: Grouping mechanism (Hadriel >>> session-id, Paul >>>>> Jones >>>>> Session-UUID) is outside the scope of SIPREC. URN UUID >>>> abstracts the >>>>> exact mechanism to SRS and provides the information only >>> about the >>>>> group of CS from SRC perspective. It possible that group may >>>>> span across multiple RS and It is up to SRS to group and view >>> as single >>>>> recording. >>>>> Here, the single level id in the top will fail. The counter >>>> argument >>>>> is to force the single RS having complete CSG but it*may not* be > >>>>> possible in SRC implementation. Here, xml:id will not serve the >>>>> purpose >>>>> >>>>> 3) session (CS) block: At the immediate look, session >>> falls exactly >>>>> under recording block. Use case 3 of draft-ietf-siprec-req-09 >>>>> illustrates where CS span across multiple RS. This >>>> requirement calls >>>>> for unique id in session by which these session shall be >>> viewed as >>>>> single CS even though there is no group exists among >>> them. IMO, in >>>>> case session should not have globally unique id, then it is >>>> preferred >>>>> to remove usecase 3 in the requirement. >>>>> >>>>> 4) participant block: It needs some id which may be AOR but >>>> AOR is not >>>> >>>>> unique. IMO, xml:id may serve the purpose with session >>>> unique id. The >>>>> trick exists for participant who are not associated with >>>> CS. We shall >>>>> discuss and fine tune if required. >>>>> >>>>> 5) stream block: Label attribute shall be used as unique >>>> value but RFC >>>>> 4574 does not mandate label attribute has to be unique across >>>>> the dialog or CS and so, it may possible to change within RS and > >>>>> no normative statement to stop this implementation. IMO, >>>> xml:id may serve >>>> >>>>> the purpose with session unique id. Here as well, We shall >>>> discuss and >>>> >>>>> fine tune if required. >>>>> >>>>> 6) extensiondata block: This is tracked in the separate >>> mail thread >>>>> whether unique id is required or not. Let us close this >>> as part of >>>>> that mail thread. >>>>> >>>>> Including explicitly Hadriel, Peter, Joe in this mail >>>> thread as they >>>>> have different view on this ID mechanism. >>>>> >>>>> I had offline discussion with Hadriel in Prague after >>>> SIPREC meeting >>>>> and my understanding of his major concern is that how SRS >>>> will be able >>>> >>>>> to design the database in case partial update does not have >>>> recording >>>>> (top) id information. I'll put more thought processing to close >>>>> Hadriel concern of how top id has to be tracked in case >>>> partial update >>>> >>>>> by which SRS implementation will be simplified in terms of >>>> aggregation >>>> >>>>> maintenance. >>>>> >>>>> Thanks >>>>> Partha >>>>> >>>>> -----Original Message----- >>>>> From: siprec-bounces@ietf.org >>>>> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat >>>> (pkyzivat) >>>>> Sent: Thursday, April 07, 2011 12:33 AM >>>>> To: siprec@ietf.org >>>>> Subject: Re: [siprec] Partial updates and identifiers >>>>> >>>>> John, >>>>> >>>>> For the moment we have proposed that the ids be conveyed in >>>> the form >>>>> of URIs that are globally unique, and specifically that >>>> they be UUID >>>>> URNs. >>>>> There is no dependency on the particular form of the URI, but >>>>> specifying they must be UUID URNs makes it possible to >>> perform some >>>>> internal optimizations for storage. >>>>> >>>>> The UUID URN is a pretty inefficient encoding. A UUID can >>>> be expressed >>>> >>>>> in 32 bits, so we could consider retaining UUIDs but alter the >>>>> encoding if its really an issue. However I am far from >>>> convinced that >>>>> the size of the IDs is going to be a major issue in the >>>> overall size >>>>> of messages, so I think its probably premature to worry about > it. >>>>> >>>>> Because the ids can be expressed in 32 bits, the SRC and >>>> SRS can store >>>> >>>>> them internally that way, thus reducing the runtime cost of >>>>> maintaining the data. >>>>> >>>>> The use of unique ids is a significant part of the overall >>>> approach to >>>> >>>>> formatting updates. If somebody has a different concept >>> in mind it >>>>> could be useful to have an alternative proposal for the >>>> format. If we >>>>> had two worked out approaches we could compare the >>>> tradeoffs in each. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>> On 4/6/2011 10:24 AM, Elwell, John wrote: >>>>>> Much of the discussion on draft-ram-metadata-format in Prague >>>>> concerned the mechanism for performing partial updates and >>>> the use of >>>>> identifiers. The draft permits partial updates by allowing >>>> individual >>>>> objects (e.g., CS, participant, media stream) to be sent >>>> with updated >>>>> content, without having to send again other objects that have >>>>> not changed. So, for example, in a large conference, it would >>>> be possible >>>>> to add or modify an individual participant object without >>> having to >>>>> send all the other participant objects again. I do not recall >>>>> any opposition to this basic principle. >>>>>> >>>>>> However, to achieve this, every object requires an >>>>> identifier, and it >>>>> was asserted that these identifiers need to be globally >>>> unique for all >>>> >>>>> time. Although this might be efficient for updating an >>>>> individual object, when sending many objects (e.g., at the start > >>>>> of a >>>> CS or when >>>>> refreshing the entire metadata), this can make the metadata very > >>>>> bulky. >>>>> It depends, of course, on the format of the identifiers, >>> and it was >>>>> stated that there could be alternatives to UUID. >>> Nevertheless, some >>>>> people had concerns. These concerns also extended to the >>>> impact on the >>>> >>>>> database where metadata is stored, since it might not be >>>> feasible to >>>>> convert to a database-friendly mechanism for linking >>>> objects together. >>>>>> >>>>>> One alternative proposal during the meeting was to have a >>>>>> single >>>>> unique identifier at the top level (for the RS) and use local >>>>> identifiers for other objects. Thus when updating a single >>>> object, it >>>>> would be necessary to include the top level identifier as >>>> well as one >>>>> or more local identifiers. However, there were also concerns >>>>> this might not fulfil actual or perceived future requirements. >>>>>> >>>>>> Please continue discussion on this. >>>>>> >>>>>> John (as chair) >>>>>> _______________________________________________ >>>>>> siprec mailing list >>>>>> siprec@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>> >>>>> _______________________________________________ >>>>> siprec mailing list >>>>> siprec@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>> >>>> >>> >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec > From pkyzivat@cisco.com Tue Apr 19 06:13:07 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 630A3E06C4 for ; Tue, 19 Apr 2011 06:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.43 X-Spam-Level: X-Spam-Status: No, score=-110.43 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NaHca0xVAMgm for ; Tue, 19 Apr 2011 06:13:05 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by ietfc.amsl.com (Postfix) with ESMTP id 931F4E065A for ; Tue, 19 Apr 2011 06:13:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=12332; q=dns/txt; s=iport; t=1303218785; x=1304428385; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=tM8M04OBzAhkdXv15IXuDxY8r7Zqj9hY/4wXTzU9B4Y=; b=mkY0CRZGI52CQFB48JL/OyKBncqTLKGFlWdsS9MFr+vBTuwCWec8N47W mNhjMeyNlY7lrRsJlB1KjOnyDa5yYf5crIJTG45kbold6CpOSn9dQGmZB 6DYigzBnD9LcPDzmpJprMiefauVBZJ0N6AJ0tGWYeFkJjgFlII9XMjhRL M=; X-IronPort-AV: E=Sophos;i="4.64,239,1301875200"; d="scan'208";a="283245742" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by sj-iport-4.cisco.com with ESMTP; 19 Apr 2011 13:13:04 +0000 Received: from [161.44.174.125] (dhcp-161-44-174-125.cisco.com [161.44.174.125]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p3JDD3FS006769; Tue, 19 Apr 2011 13:13:04 GMT Message-ID: <4DAD8A5F.4040506@cisco.com> Date: Tue, 19 Apr 2011 09:13:03 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Elwell, John" References: <21866C7FE177A4449B9136B5B24B1B130BC011290A@EXMBXCLUS01.citservers.local> <21866C7FE177A4449B9136B5B24B1B130BC011294A@EXMBXCLUS01.citservers.local> <35BCE99A477D6A4986FB2216D8CF2CFD05DD8C0C@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD05EF92EF@XMB-BGL-417.cisco.com> <4D9CBD8C.4010901@cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD06133966@XMB-BGL-417.cisco.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] comments on draft-ram-siprec-metadata-04 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 19 Apr 2011 13:13:07 -0000 On 4/19/2011 8:32 AM, Elwell, John wrote: > Ram, > > I am not quite sure whether that is an issue or not. If we go for a single unique identifier, I suspect it would need to identify a CS, not an RS. In fact I was waiting to hear more from Paul on his assertion below, that perhaps none of the elements has a direct relationship with an RS. I am OK leaving the relationship in for now. It might become clearer when we resolve the question of identifiers. I haven't worked out the details. The concept would require the metamodel to be modified to explicitly represent the results of updates. Then, each individually updatable datum in the model would be tied to the update that delivered it, and thus to an RS in which it was delivered and a timestamp for when it was delivered. Each such updatable datum would be represented as a time series of values. For instance, the relationship between media streams and participants could be represented either as: - each stream has a series for each participant in the stream. Each element in the series identifies a change in the role of the participant relative to that stream. - each participant has a series for each stream in which it participates. Each element in the series identifies a change in the role of the participant relative to the stream. In either case, each element in the series would refer to the RS over which it was delivered, and would have a timestamp indicating when it occurred. For instance, elements in the series might indicate: - (alice:stream-1) sending@t1, inactive@t10, sending@t20, inactive@t30 - (bob:stream-1) recving@t2, inactive@t31 - (carol:stream-1) recving@t8, inactive@t12, recving@t20, inactive@t25 - (ted:stream-1) sending@t10, inactive@t20 Thanks, Paul > John (as individual) > >> -----Original Message----- >> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] >> Sent: 19 April 2011 11:31 >> To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); >> siprec@ietf.org; Elwell, John >> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 >> >> Partha, >> I agree with your concern here. >> >> John, >> Are you ok with retaining the below relation in the model, If >> yes we can >> close this open item of the model >> >> +-------------------------------+ 1 >> | Recording Session (RS) |---------------+ >> +-------------------------------+ | >> |1..* |1..* | >> | | | >> |0..* |0..* | >> +--------------+ +-----------------+ | >> |Communication | | Communication | 1 | >> | Session (CS) |----------| Session (CS) |---| >> | Group |0..1 1..*| | | 0..* +----------+ >> +--------------+ +-----------------+ |------|Extension | >> 1| | 0..* |1..* | | Data | >> | | 2..* |0..* | +----------+ >> 0..*| >> +---------+ >> |Extension| >> | Data | >> +---------+ >> >> Regards, >> Ram >> >>> -----Original Message----- >>> From: Parthasarathi R (partr) >>> Sent: Thursday, April 07, 2011 4:07 PM >>> To: Paul Kyzivat (pkyzivat); siprec@ietf.org; Ram Mohan R (rmohanr); >>> Elwell, John >>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 >>> >>> John/Ram, >>> >>> I see the issue without direct link between RS and CSG. It may be >> tough >>> to correlate CSG to RS in SRS implementation. This issue is >> raised by >>> Hadriel in terms of having single unique id for metadata >> format draft. >>> I explained his concern in "Partial updates and identifiers" mail >>> thread. >>> >>> Also another issue: SRS may be interested in knowing list of >> associated >>> RS for a given CSG. >>> >>> Thanks >>> Partha >>> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>> Behalf Of Paul Kyzivat (pkyzivat) >>> Sent: Thursday, April 07, 2011 12:53 AM >>> To: siprec@ietf.org >>> Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 >>> >>> John, >>> >>> I've been thinking about how everything relates to the RS, and that >>> maybe we should make some more major changes. >>> >>> What I'm thinking is that none of the elements have a direct >>> relationship to RS. Rather, each element is ultimately >> constructed as >> a >>> time series of values delivered in updates. Its the updates >> that have >> a >>> relationship to a RS - the one they are delivered in. That >> allows the >>> possibility that not all the updates come from the same RS. >>> >>> I haven't drawn a model diagram here because the concept is still >>> fuzzy. >>> Its a trial balloon - to see what others think. >>> >>> Thanks, >>> Paul >>> >>> On 4/6/2011 11:47 AM, Elwell, John wrote: >>>> Ram, >>>> >>>> I am not sure this answers my question. In the model you >> drew below, >>> a CSG has both a direct relationship with an RS and an indirect >>> relationship (via a CS). I was questioning whether we could >> remove the >>> direct relationship, on the basis that the indirect relationship is >>> sufficient. >>>> >>>> John (as individual) >>>> >>>> >>>>> -----Original Message----- >>>>> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] >>>>> Sent: 06 April 2011 15:52 >>>>> To: Elwell, John; Scott Orton; Charles Eckel (eckelcu); >>> Parthasarathi >>>>> R (partr); siprec@ietf.org >>>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 >>>>> >>>>> Hi John, >>>>> >>>>> Yes We have an indirect relationship in the current >> model. However >>> in >>>>> the current model it is REQUIRED to have a CSG as CS is connected >> to >>>>> RS through CSG. However not all use cases would need CSG, IOW CSG >>> has >>>>> to be optional and there should be direct association >> from CS to RS >>>>> even when CSG is absent. >>>>> >>>>> With the below associations we will have: >>>>> - An instance of RS can have Zero or more CSG blocks. >>>>> - An instance of RS can have Zero or more CS blocks. >>>>> - If a CSG is present it will have 1 or more CS. >>>>> - Each CS can be associated with Zero or 1 CSG. >>>>> >>>>> Let me know if you have any concerns. >>>>> >>>>> Regards, >>>>> Ram >>>>> >>>>>> -----Original Message----- >>>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>>>>> Sent: Wednesday, April 06, 2011 6:16 PM >>>>>> To: Ram Mohan R (rmohanr); Scott Orton; Charles Eckel (eckelcu); >>>>>> Parthasarathi R (partr); siprec@ietf.org >>>>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 >>>>>> >>>>>> I am OK in principle, but I wonder whether there really >>>>> needs to be a >>>>>> relationship between CSG and RS. Isn't that relationship an >>> indirect >>>>>> relationship via CS? >>>>>> >>>>>> John (as individual) >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] >>>>>>> Sent: 03 April 2011 18:13 >>>>>>> To: Scott Orton; Elwell, John; Charles Eckel (eckelcu); >>>>>>> Parthasarathi R (partr); siprec@ietf.org >>>>>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 >>>>>>> >>>>>>> Scott, >>>>>>> >>>>>>> I am ok to make this change to the model. I would like to >>>>> hear from >>>>>>> others if they have any issues in incorporating this change in >> the >>>>>>> model. >>>>>>> >>>>>>> The updated portion of the model will look like >>>>>>> >>>>>>> >>>>>>> +-------------------------------+ 1 >>>>>>> | Recording Session (RS) |---------------+ >>>>>>> +-------------------------------+ | >>>>>>> | 1..* |1..* | >>>>>>> | | | >>>>>>> | 0..* |0..* | >>>>>>> +--------------+ +-----------------+ | >>>>>>> |Communication | | Communication | 1 | >>>>>>> | Session (CS) |----------| Session (CS) |---| >>>>>>> | Group |0..1 1..*| | | 0..* >>>>> +----------+ >>>>>>> +--------------+ +-----------------+ >>>>> |------|Extension >>>>> | >>>>>>> 1| | 0..* |1..* | >> | Data >>>>> | >>>>>>> | | 2..* |0..* | >>>>> +----------+ >>>>>>> 0..*| >>>>>>> +---------+ >>>>>>> |Extension| >>>>>>> | Data | >>>>>>> +---------+ >>>>>>> >>>>>>> The only change in the association is : >>>>>>> A CS MUST be associated with zero or one CS-Group >>>>>>> >>>>>>> Rest of the associations remain same. Further the association >>>>>>> between CS and RS remains same as what is between CS-Group and >> RS. >>>>>>> >>>>>>> Comments ? >>>>>>> >>>>>>> Regards, >>>>>>> Ram >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: siprec-bounces@ietf.org >>>>> [mailto:siprec-bounces@ietf.org] On >>>>>>>> Behalf Of Scott Orton >>>>>>>> Sent: Friday, April 01, 2011 12:18 AM >>>>>>>> To: Elwell, John; Charles Eckel (eckelcu); Parthasarathi R >>>>> (partr); >>>>>>>> siprec@ietf.org >>>>>>>> Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 >>>>>>>> >>>>>>>> John, >>>>>>>> Thanks for the information. >>>>>>>> >>>>>>>> In that case I would like to see the CS group be >>>>> made optional. >>>>>>>> Rather than the CS pointing to the CS Group, I would like to >>>>>> suggest >>>>>>>> that the CS point to the RS and have the CS group stand >>>>>>> alone where it >>>>>>>> would just have its own ID and then a list of CS ids >> that belong >>>>> to >>>>>>> the >>>>>>>> group. >>>>>>>> >>>>>>>> Scott >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>>>>>>> Sent: Thursday, March 31, 2011 11:50 AM >>>>>>>> To: Scott Orton; Charles Eckel (eckelcu); Parthasarathi >>>>> R (partr); >>>>>>>> siprec@ietf.org >>>>>>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 >>>>>>>> >>>>>>>> Scott, >>>>>>>> >>>>>>>> Some folks wanted to be able to group related CSs together >>>>>>> (e.g., a CS >>>>>>>> between a customer and an agent and a second CS >>>>> resulting from the >>>>>>>> customer being transferred to a second agent). I will >>>>> leave it to >>>>>>> those >>>>>>>> folks to add to this. >>>>>>>> >>>>>>>> John (chair hat on) >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Scott Orton [mailto:sorton@broadsoft.com] >>>>>>>>> Sent: 31 March 2011 17:43 >>>>>>>>> To: Elwell, John; Charles Eckel (eckelcu); Parthasarathi R >>>>>>>>> (partr); siprec@ietf.org >>>>>>>>> Subject: RE: [siprec] comments on >> draft-ram-siprec-metadata-04 >>>>>>>>> >>>>>>>>> John, Charles, Partha, >>>>>>>>> I have a question. What is the purpose of the CS Group? I >> do >>>>>>>>> not see it adding anything to the metadata. To me it >> seems that >>>>>>>>> the whole purpose of the metadata is to describe the >> recording >>>>>>>>> session to the SRS. Looking at the requirements I see 3 >>>>>>>>> relationships that the spec is attempting to describe: >>>>>>>>> >>>>>>>>> A one to one relationship - one communication session to one >>>>>>>>> recording session A one to many relationship - one >> communication >>>>>>>>> session with multiple Recording sessions >>>>>>>>> - one Recording session >> made up of >>>>>>>>> multiple communications sessions >>>>>>>>> >>>>>>>>> The current metadata format allows all of these and I do not >> see >>>>>>>>> what the group is adding. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Scott >>>>>>>>> >>>>> >>>> _______________________________________________ >>>> siprec mailing 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 Apr 19 07:33:40 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DB044E06E9 for ; Tue, 19 Apr 2011 07:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.722 X-Spam-Level: X-Spam-Status: No, score=-104.722 tagged_above=-999 required=5 tests=[AWL=1.277, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-bMDvsRI0Xq for ; Tue, 19 Apr 2011 07:33:39 -0700 (PDT) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfc.amsl.com (Postfix) with SMTP id D9E42E06C0 for ; Tue, 19 Apr 2011 07:33:38 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1303223614!29378506!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 22805 invoked from network); 19 Apr 2011 14:33:34 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-10.tower-27.messagelabs.com with SMTP; 19 Apr 2011 14:33:34 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id A6BFA1EB83EE; Tue, 19 Apr 2011 16:33:37 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 19 Apr 2011 16:33:37 +0200 From: "Elwell, John" To: Paul Kyzivat Date: Tue, 19 Apr 2011 16:33:36 +0200 Thread-Topic: [siprec] comments on draft-ram-siprec-metadata-04 Thread-Index: Acv+k4aXtzEMi5mmSXukZr8unCKrKQACnHkQ Message-ID: References: <21866C7FE177A4449B9136B5B24B1B130BC011290A@EXMBXCLUS01.citservers.local> <21866C7FE177A4449B9136B5B24B1B130BC011294A@EXMBXCLUS01.citservers.local> <35BCE99A477D6A4986FB2216D8CF2CFD05DD8C0C@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD05EF92EF@XMB-BGL-417.cisco.com> <4D9CBD8C.4010901@cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD06133966@XMB-BGL-417.cisco.com> <4DAD8A5F.4040506@cisco.com> In-Reply-To: <4DAD8A5F.4040506@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 Cc: "siprec@ietf.org" Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 19 Apr 2011 14:33:41 -0000 I think I see where you are going. Each element in a series could potential= ly be delivered over a different RS. This seems to imply an RS only needs t= o exist momentarily. However, the RS has SDP that contains the media descri= ptions, and a given media description, including it's a=3Dlabel attribute t= ying it to a Media Stream object, will need to exist continually, between t= he deltas. Tearing down an RS will also tear down the delivery of media for= a Media Stream to the SRS. So I am not entirely sure what you have in mind= . John > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: 19 April 2011 14:13 > To: Elwell, John > Cc: Ram Mohan R (rmohanr); Parthasarathi R (partr); siprec@ietf.org > Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 >=20 >=20 >=20 > On 4/19/2011 8:32 AM, Elwell, John wrote: > > Ram, > > > > I am not quite sure whether that is an issue or not. If we=20 > go for a single unique identifier, I suspect it would need to=20 > identify a CS, not an RS. In fact I was waiting to hear more=20 > from Paul on his assertion below, that perhaps none of the=20 > elements has a direct relationship with an RS. I am OK=20 > leaving the relationship in for now. It might become clearer=20 > when we resolve the question of identifiers. >=20 > I haven't worked out the details. The concept would require the=20 > metamodel to be modified to explicitly represent the results=20 > of updates.=20 > Then, each individually updatable datum in the model would be tied to=20 > the update that delivered it, and thus to an RS in which it was=20 > delivered and a timestamp for when it was delivered. Each=20 > such updatable=20 > datum would be represented as a time series of values. >=20 > For instance, the relationship between media streams and participants=20 > could be represented either as: >=20 > - each stream has a series for each participant in the stream. > Each element in the series identifies a change in the role > of the participant relative to that stream. >=20 > - each participant has a series for each stream in which it > participates. Each element in the series identifies a change > in the role of the participant relative to the stream. >=20 > In either case, each element in the series would refer to the RS over=20 > which it was delivered, and would have a timestamp indicating when it=20 > occurred. >=20 > For instance, elements in the series might indicate: > - (alice:stream-1) sending@t1, inactive@t10, sending@t20, inactive@t30 > - (bob:stream-1) recving@t2, inactive@t31 > - (carol:stream-1) recving@t8, inactive@t12, recving@t20, inactive@t25 > - (ted:stream-1) sending@t10, inactive@t20 >=20 > Thanks, > Paul >=20 >=20 > > John (as individual) > > > >> -----Original Message----- > >> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > >> Sent: 19 April 2011 11:31 > >> To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); > >> siprec@ietf.org; Elwell, John > >> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > >> > >> Partha, > >> I agree with your concern here. > >> > >> John, > >> Are you ok with retaining the below relation in the model, If > >> yes we can > >> close this open item of the model > >> > >> +-------------------------------+ 1 > >> | Recording Session (RS) |---------------+ > >> +-------------------------------+ | > >> |1..* |1..* | > >> | | | > >> |0..* |0..* | > >> +--------------+ +-----------------+ | > >> |Communication | | Communication | 1 | > >> | Session (CS) |----------| Session (CS) |---| > >> | Group |0..1 1..*| | | 0..*=20 > +----------+ > >> +--------------+ +-----------------+ =20 > |------|Extension | > >> 1| | 0..* |1..* | =20 > | Data | > >> | | 2..* |0..* | =20 > +----------+ > >> 0..*| > >> +---------+ > >> |Extension| > >> | Data | > >> +---------+ > >> > >> Regards, > >> Ram > >> > >>> -----Original Message----- > >>> From: Parthasarathi R (partr) > >>> Sent: Thursday, April 07, 2011 4:07 PM > >>> To: Paul Kyzivat (pkyzivat); siprec@ietf.org; Ram Mohan R=20 > (rmohanr); > >>> Elwell, John > >>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > >>> > >>> John/Ram, > >>> > >>> I see the issue without direct link between RS and CSG. It may be > >> tough > >>> to correlate CSG to RS in SRS implementation. This issue is > >> raised by > >>> Hadriel in terms of having single unique id for metadata > >> format draft. > >>> I explained his concern in "Partial updates and identifiers" mail > >>> thread. > >>> > >>> Also another issue: SRS may be interested in knowing list of > >> associated > >>> RS for a given CSG. > >>> > >>> Thanks > >>> Partha > >>> > >>> -----Original Message----- > >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >>> Behalf Of Paul Kyzivat (pkyzivat) > >>> Sent: Thursday, April 07, 2011 12:53 AM > >>> To: siprec@ietf.org > >>> Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 > >>> > >>> John, > >>> > >>> I've been thinking about how everything relates to the=20 > RS, and that > >>> maybe we should make some more major changes. > >>> > >>> What I'm thinking is that none of the elements have a direct > >>> relationship to RS. Rather, each element is ultimately > >> constructed as > >> a > >>> time series of values delivered in updates. Its the updates > >> that have > >> a > >>> relationship to a RS - the one they are delivered in. That > >> allows the > >>> possibility that not all the updates come from the same RS. > >>> > >>> I haven't drawn a model diagram here because the concept is still > >>> fuzzy. > >>> Its a trial balloon - to see what others think. > >>> > >>> Thanks, > >>> Paul > >>> > >>> On 4/6/2011 11:47 AM, Elwell, John wrote: > >>>> Ram, > >>>> > >>>> I am not sure this answers my question. In the model you > >> drew below, > >>> a CSG has both a direct relationship with an RS and an indirect > >>> relationship (via a CS). I was questioning whether we could > >> remove the > >>> direct relationship, on the basis that the indirect=20 > relationship is > >>> sufficient. > >>>> > >>>> John (as individual) > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > >>>>> Sent: 06 April 2011 15:52 > >>>>> To: Elwell, John; Scott Orton; Charles Eckel (eckelcu); > >>> Parthasarathi > >>>>> R (partr); siprec@ietf.org > >>>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > >>>>> > >>>>> Hi John, > >>>>> > >>>>> Yes We have an indirect relationship in the current > >> model. However > >>> in > >>>>> the current model it is REQUIRED to have a CSG as CS is=20 > connected > >> to > >>>>> RS through CSG. However not all use cases would need=20 > CSG, IOW CSG > >>> has > >>>>> to be optional and there should be direct association > >> from CS to RS > >>>>> even when CSG is absent. > >>>>> > >>>>> With the below associations we will have: > >>>>> - An instance of RS can have Zero or more CSG blocks. > >>>>> - An instance of RS can have Zero or more CS blocks. > >>>>> - If a CSG is present it will have 1 or more CS. > >>>>> - Each CS can be associated with Zero or 1 CSG. > >>>>> > >>>>> Let me know if you have any concerns. > >>>>> > >>>>> Regards, > >>>>> Ram > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > >>>>>> Sent: Wednesday, April 06, 2011 6:16 PM > >>>>>> To: Ram Mohan R (rmohanr); Scott Orton; Charles Eckel=20 > (eckelcu); > >>>>>> Parthasarathi R (partr); siprec@ietf.org > >>>>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > >>>>>> > >>>>>> I am OK in principle, but I wonder whether there really > >>>>> needs to be a > >>>>>> relationship between CSG and RS. Isn't that relationship an > >>> indirect > >>>>>> relationship via CS? > >>>>>> > >>>>>> John (as individual) > >>>>>> > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > >>>>>>> Sent: 03 April 2011 18:13 > >>>>>>> To: Scott Orton; Elwell, John; Charles Eckel (eckelcu); > >>>>>>> Parthasarathi R (partr); siprec@ietf.org > >>>>>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > >>>>>>> > >>>>>>> Scott, > >>>>>>> > >>>>>>> I am ok to make this change to the model. I would like to > >>>>> hear from > >>>>>>> others if they have any issues in incorporating this change in > >> the > >>>>>>> model. > >>>>>>> > >>>>>>> The updated portion of the model will look like > >>>>>>> > >>>>>>> > >>>>>>> +-------------------------------+ 1 > >>>>>>> | Recording Session (RS) |---------------+ > >>>>>>> +-------------------------------+ | > >>>>>>> | 1..* |1..* | > >>>>>>> | | | > >>>>>>> | 0..* |0..* | > >>>>>>> +--------------+ +-----------------+ | > >>>>>>> |Communication | | Communication | 1 | > >>>>>>> | Session (CS) |----------| Session (CS) |---| > >>>>>>> | Group |0..1 1..*| | | 0..* > >>>>> +----------+ > >>>>>>> +--------------+ +-----------------+ > >>>>> |------|Extension > >>>>> | > >>>>>>> 1| | 0..* |1..* | > >> | Data > >>>>> | > >>>>>>> | | 2..* |0..* | > >>>>> +----------+ > >>>>>>> 0..*| > >>>>>>> +---------+ > >>>>>>> |Extension| > >>>>>>> | Data | > >>>>>>> +---------+ > >>>>>>> > >>>>>>> The only change in the association is : > >>>>>>> A CS MUST be associated with zero or one CS-Group > >>>>>>> > >>>>>>> Rest of the associations remain same. Further the association > >>>>>>> between CS and RS remains same as what is between CS-Group and > >> RS. > >>>>>>> > >>>>>>> Comments ? > >>>>>>> > >>>>>>> Regards, > >>>>>>> Ram > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: siprec-bounces@ietf.org > >>>>> [mailto:siprec-bounces@ietf.org] On > >>>>>>>> Behalf Of Scott Orton > >>>>>>>> Sent: Friday, April 01, 2011 12:18 AM > >>>>>>>> To: Elwell, John; Charles Eckel (eckelcu); Parthasarathi R > >>>>> (partr); > >>>>>>>> siprec@ietf.org > >>>>>>>> Subject: Re: [siprec] comments on=20 > draft-ram-siprec-metadata-04 > >>>>>>>> > >>>>>>>> John, > >>>>>>>> Thanks for the information. > >>>>>>>> > >>>>>>>> In that case I would like to see the CS group be > >>>>> made optional. > >>>>>>>> Rather than the CS pointing to the CS Group, I would like to > >>>>>> suggest > >>>>>>>> that the CS point to the RS and have the CS group stand > >>>>>>> alone where it > >>>>>>>> would just have its own ID and then a list of CS ids > >> that belong > >>>>> to > >>>>>>> the > >>>>>>>> group. > >>>>>>>> > >>>>>>>> Scott > >>>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Elwell, John=20 > [mailto:john.elwell@siemens-enterprise.com] > >>>>>>>> Sent: Thursday, March 31, 2011 11:50 AM > >>>>>>>> To: Scott Orton; Charles Eckel (eckelcu); Parthasarathi > >>>>> R (partr); > >>>>>>>> siprec@ietf.org > >>>>>>>> Subject: RE: [siprec] comments on=20 > draft-ram-siprec-metadata-04 > >>>>>>>> > >>>>>>>> Scott, > >>>>>>>> > >>>>>>>> Some folks wanted to be able to group related CSs together > >>>>>>> (e.g., a CS > >>>>>>>> between a customer and an agent and a second CS > >>>>> resulting from the > >>>>>>>> customer being transferred to a second agent). I will > >>>>> leave it to > >>>>>>> those > >>>>>>>> folks to add to this. > >>>>>>>> > >>>>>>>> John (chair hat on) > >>>>>>>> > >>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: Scott Orton [mailto:sorton@broadsoft.com] > >>>>>>>>> Sent: 31 March 2011 17:43 > >>>>>>>>> To: Elwell, John; Charles Eckel (eckelcu); Parthasarathi R > >>>>>>>>> (partr); siprec@ietf.org > >>>>>>>>> Subject: RE: [siprec] comments on > >> draft-ram-siprec-metadata-04 > >>>>>>>>> > >>>>>>>>> John, Charles, Partha, > >>>>>>>>> I have a question. What is the purpose of the=20 > CS Group? I > >> do > >>>>>>>>> not see it adding anything to the metadata. To me it > >> seems that > >>>>>>>>> the whole purpose of the metadata is to describe the > >> recording > >>>>>>>>> session to the SRS. Looking at the requirements I see 3 > >>>>>>>>> relationships that the spec is attempting to describe: > >>>>>>>>> > >>>>>>>>> A one to one relationship - one communication session to one > >>>>>>>>> recording session A one to many relationship - one > >> communication > >>>>>>>>> session with multiple Recording sessions > >>>>>>>>> - one Recording session > >> made up of > >>>>>>>>> multiple communications sessions > >>>>>>>>> > >>>>>>>>> The current metadata format allows all of these and I do not > >> see > >>>>>>>>> what the group is adding. > >>>>>>>>> > >>>>>>>>> Regards, > >>>>>>>>> Scott > >>>>>>>>> > >>>>> > >>>> _______________________________________________ > >>>> siprec mailing 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@cisco.com Tue Apr 19 08:23:25 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 159ADE0758 for ; Tue, 19 Apr 2011 08:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.136 X-Spam-Level: X-Spam-Status: No, score=-110.136 tagged_above=-999 required=5 tests=[AWL=-0.137, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p4WIqr0gFK7Q for ; Tue, 19 Apr 2011 08:23:23 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfc.amsl.com (Postfix) with ESMTP id 81144E0756 for ; Tue, 19 Apr 2011 08:23:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=14894; q=dns/txt; s=iport; t=1303226600; x=1304436200; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=dD9f6zuiucIfNQUR05cIJTRUlPH87v0/qf6Ie+LGvkQ=; b=aRibiUjmLVuup527yM1We03qoLY3j6VcbgEGcVe2s62+2ZxuFJFWH9U8 2I49HhUYXb/rSWe7Pfr+IrmBA9LeeNRoHkmQZ9QQEQuEtxbMF+IIFIqA5 Na5yPdiZAPvbZ0ozZuxTGkiwGFt53oQ5NhycFE0/aCs6YYH/S/uRi8qFR c=; X-IronPort-AV: E=Sophos;i="4.64,240,1301875200"; d="scan'208";a="297641605" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by sj-iport-3.cisco.com with ESMTP; 19 Apr 2011 15:23:19 +0000 Received: from [161.44.174.125] (dhcp-161-44-174-125.cisco.com [161.44.174.125]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3JFNI3R009400; Tue, 19 Apr 2011 15:23:18 GMT Message-ID: <4DADA8E6.9010006@cisco.com> Date: Tue, 19 Apr 2011 11:23:18 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Elwell, John" References: <21866C7FE177A4449B9136B5B24B1B130BC011290A@EXMBXCLUS01.citservers.local> <21866C7FE177A4449B9136B5B24B1B130BC011294A@EXMBXCLUS01.citservers.local> <35BCE99A477D6A4986FB2216D8CF2CFD05DD8C0C@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD05EF92EF@XMB-BGL-417.cisco.com> <4D9CBD8C.4010901@cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD06133966@XMB-BGL-417.cisco.com> <4DAD8A5F.4040506@cisco.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] comments on draft-ram-siprec-metadata-04 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 19 Apr 2011 15:23:25 -0000 On 4/19/2011 10:33 AM, Elwell, John wrote: > I think I see where you are going. Each element in a series could potentially be delivered over a different RS. This seems to imply an RS only needs to exist momentarily. However, the RS has SDP that contains the media descriptions, and a given media description, including it's a=label attribute tying it to a Media Stream object, will need to exist continually, between the deltas. Tearing down an RS will also tear down the delivery of media for a Media Stream to the SRS. So I am not entirely sure what you have in mind. First, the idea is only half baked, so certainly feel free to take shots at it. And, in case of MS, perhaps you are right that you can't reference the same MS from two different RS. Or maybe you could. In principle an SRC could lose the RS dialog, establish a new one, and then continue talking about the same CS and MS. (This could happen if the SRS server crashed and a backup took over for it.) Its a different RTP stream on the RS, but its delivering data for the same CS MS. Since in the case of a persistent RS we are prepared to have a single m-line in the RS represent (serially, not concurrently) different MSs, its clear there isn't a 1:1 relationship. So why not two different RS m-lines representing (serially) the same MS? But the notion may be more important for other stuff that changes over time. Thanks, Paul > John > > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: 19 April 2011 14:13 >> To: Elwell, John >> Cc: Ram Mohan R (rmohanr); Parthasarathi R (partr); siprec@ietf.org >> Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 >> >> >> >> On 4/19/2011 8:32 AM, Elwell, John wrote: >>> Ram, >>> >>> I am not quite sure whether that is an issue or not. If we >> go for a single unique identifier, I suspect it would need to >> identify a CS, not an RS. In fact I was waiting to hear more >> from Paul on his assertion below, that perhaps none of the >> elements has a direct relationship with an RS. I am OK >> leaving the relationship in for now. It might become clearer >> when we resolve the question of identifiers. >> >> I haven't worked out the details. The concept would require the >> metamodel to be modified to explicitly represent the results >> of updates. >> Then, each individually updatable datum in the model would be tied to >> the update that delivered it, and thus to an RS in which it was >> delivered and a timestamp for when it was delivered. Each >> such updatable >> datum would be represented as a time series of values. >> >> For instance, the relationship between media streams and participants >> could be represented either as: >> >> - each stream has a series for each participant in the stream. >> Each element in the series identifies a change in the role >> of the participant relative to that stream. >> >> - each participant has a series for each stream in which it >> participates. Each element in the series identifies a change >> in the role of the participant relative to the stream. >> >> In either case, each element in the series would refer to the RS over >> which it was delivered, and would have a timestamp indicating when it >> occurred. >> >> For instance, elements in the series might indicate: >> - (alice:stream-1) sending@t1, inactive@t10, sending@t20, inactive@t30 >> - (bob:stream-1) recving@t2, inactive@t31 >> - (carol:stream-1) recving@t8, inactive@t12, recving@t20, inactive@t25 >> - (ted:stream-1) sending@t10, inactive@t20 >> >> Thanks, >> Paul >> >> >>> John (as individual) >>> >>>> -----Original Message----- >>>> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] >>>> Sent: 19 April 2011 11:31 >>>> To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); >>>> siprec@ietf.org; Elwell, John >>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 >>>> >>>> Partha, >>>> I agree with your concern here. >>>> >>>> John, >>>> Are you ok with retaining the below relation in the model, If >>>> yes we can >>>> close this open item of the model >>>> >>>> +-------------------------------+ 1 >>>> | Recording Session (RS) |---------------+ >>>> +-------------------------------+ | >>>> |1..* |1..* | >>>> | | | >>>> |0..* |0..* | >>>> +--------------+ +-----------------+ | >>>> |Communication | | Communication | 1 | >>>> | Session (CS) |----------| Session (CS) |---| >>>> | Group |0..1 1..*| | | 0..* >> +----------+ >>>> +--------------+ +-----------------+ >> |------|Extension | >>>> 1| | 0..* |1..* | >> | Data | >>>> | | 2..* |0..* | >> +----------+ >>>> 0..*| >>>> +---------+ >>>> |Extension| >>>> | Data | >>>> +---------+ >>>> >>>> Regards, >>>> Ram >>>> >>>>> -----Original Message----- >>>>> From: Parthasarathi R (partr) >>>>> Sent: Thursday, April 07, 2011 4:07 PM >>>>> To: Paul Kyzivat (pkyzivat); siprec@ietf.org; Ram Mohan R >> (rmohanr); >>>>> Elwell, John >>>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 >>>>> >>>>> John/Ram, >>>>> >>>>> I see the issue without direct link between RS and CSG. It may be >>>> tough >>>>> to correlate CSG to RS in SRS implementation. This issue is >>>> raised by >>>>> Hadriel in terms of having single unique id for metadata >>>> format draft. >>>>> I explained his concern in "Partial updates and identifiers" mail >>>>> thread. >>>>> >>>>> Also another issue: SRS may be interested in knowing list of >>>> associated >>>>> RS for a given CSG. >>>>> >>>>> Thanks >>>>> Partha >>>>> >>>>> -----Original Message----- >>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>>>> Behalf Of Paul Kyzivat (pkyzivat) >>>>> Sent: Thursday, April 07, 2011 12:53 AM >>>>> To: siprec@ietf.org >>>>> Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 >>>>> >>>>> John, >>>>> >>>>> I've been thinking about how everything relates to the >> RS, and that >>>>> maybe we should make some more major changes. >>>>> >>>>> What I'm thinking is that none of the elements have a direct >>>>> relationship to RS. Rather, each element is ultimately >>>> constructed as >>>> a >>>>> time series of values delivered in updates. Its the updates >>>> that have >>>> a >>>>> relationship to a RS - the one they are delivered in. That >>>> allows the >>>>> possibility that not all the updates come from the same RS. >>>>> >>>>> I haven't drawn a model diagram here because the concept is still >>>>> fuzzy. >>>>> Its a trial balloon - to see what others think. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>> On 4/6/2011 11:47 AM, Elwell, John wrote: >>>>>> Ram, >>>>>> >>>>>> I am not sure this answers my question. In the model you >>>> drew below, >>>>> a CSG has both a direct relationship with an RS and an indirect >>>>> relationship (via a CS). I was questioning whether we could >>>> remove the >>>>> direct relationship, on the basis that the indirect >> relationship is >>>>> sufficient. >>>>>> >>>>>> John (as individual) >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] >>>>>>> Sent: 06 April 2011 15:52 >>>>>>> To: Elwell, John; Scott Orton; Charles Eckel (eckelcu); >>>>> Parthasarathi >>>>>>> R (partr); siprec@ietf.org >>>>>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 >>>>>>> >>>>>>> Hi John, >>>>>>> >>>>>>> Yes We have an indirect relationship in the current >>>> model. However >>>>> in >>>>>>> the current model it is REQUIRED to have a CSG as CS is >> connected >>>> to >>>>>>> RS through CSG. However not all use cases would need >> CSG, IOW CSG >>>>> has >>>>>>> to be optional and there should be direct association >>>> from CS to RS >>>>>>> even when CSG is absent. >>>>>>> >>>>>>> With the below associations we will have: >>>>>>> - An instance of RS can have Zero or more CSG blocks. >>>>>>> - An instance of RS can have Zero or more CS blocks. >>>>>>> - If a CSG is present it will have 1 or more CS. >>>>>>> - Each CS can be associated with Zero or 1 CSG. >>>>>>> >>>>>>> Let me know if you have any concerns. >>>>>>> >>>>>>> Regards, >>>>>>> Ram >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>>>>>>> Sent: Wednesday, April 06, 2011 6:16 PM >>>>>>>> To: Ram Mohan R (rmohanr); Scott Orton; Charles Eckel >> (eckelcu); >>>>>>>> Parthasarathi R (partr); siprec@ietf.org >>>>>>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 >>>>>>>> >>>>>>>> I am OK in principle, but I wonder whether there really >>>>>>> needs to be a >>>>>>>> relationship between CSG and RS. Isn't that relationship an >>>>> indirect >>>>>>>> relationship via CS? >>>>>>>> >>>>>>>> John (as individual) >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] >>>>>>>>> Sent: 03 April 2011 18:13 >>>>>>>>> To: Scott Orton; Elwell, John; Charles Eckel (eckelcu); >>>>>>>>> Parthasarathi R (partr); siprec@ietf.org >>>>>>>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 >>>>>>>>> >>>>>>>>> Scott, >>>>>>>>> >>>>>>>>> I am ok to make this change to the model. I would like to >>>>>>> hear from >>>>>>>>> others if they have any issues in incorporating this change in >>>> the >>>>>>>>> model. >>>>>>>>> >>>>>>>>> The updated portion of the model will look like >>>>>>>>> >>>>>>>>> >>>>>>>>> +-------------------------------+ 1 >>>>>>>>> | Recording Session (RS) |---------------+ >>>>>>>>> +-------------------------------+ | >>>>>>>>> | 1..* |1..* | >>>>>>>>> | | | >>>>>>>>> | 0..* |0..* | >>>>>>>>> +--------------+ +-----------------+ | >>>>>>>>> |Communication | | Communication | 1 | >>>>>>>>> | Session (CS) |----------| Session (CS) |---| >>>>>>>>> | Group |0..1 1..*| | | 0..* >>>>>>> +----------+ >>>>>>>>> +--------------+ +-----------------+ >>>>>>> |------|Extension >>>>>>> | >>>>>>>>> 1| | 0..* |1..* | >>>> | Data >>>>>>> | >>>>>>>>> | | 2..* |0..* | >>>>>>> +----------+ >>>>>>>>> 0..*| >>>>>>>>> +---------+ >>>>>>>>> |Extension| >>>>>>>>> | Data | >>>>>>>>> +---------+ >>>>>>>>> >>>>>>>>> The only change in the association is : >>>>>>>>> A CS MUST be associated with zero or one CS-Group >>>>>>>>> >>>>>>>>> Rest of the associations remain same. Further the association >>>>>>>>> between CS and RS remains same as what is between CS-Group and >>>> RS. >>>>>>>>> >>>>>>>>> Comments ? >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Ram >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: siprec-bounces@ietf.org >>>>>>> [mailto:siprec-bounces@ietf.org] On >>>>>>>>>> Behalf Of Scott Orton >>>>>>>>>> Sent: Friday, April 01, 2011 12:18 AM >>>>>>>>>> To: Elwell, John; Charles Eckel (eckelcu); Parthasarathi R >>>>>>> (partr); >>>>>>>>>> siprec@ietf.org >>>>>>>>>> Subject: Re: [siprec] comments on >> draft-ram-siprec-metadata-04 >>>>>>>>>> >>>>>>>>>> John, >>>>>>>>>> Thanks for the information. >>>>>>>>>> >>>>>>>>>> In that case I would like to see the CS group be >>>>>>> made optional. >>>>>>>>>> Rather than the CS pointing to the CS Group, I would like to >>>>>>>> suggest >>>>>>>>>> that the CS point to the RS and have the CS group stand >>>>>>>>> alone where it >>>>>>>>>> would just have its own ID and then a list of CS ids >>>> that belong >>>>>>> to >>>>>>>>> the >>>>>>>>>> group. >>>>>>>>>> >>>>>>>>>> Scott >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Elwell, John >> [mailto:john.elwell@siemens-enterprise.com] >>>>>>>>>> Sent: Thursday, March 31, 2011 11:50 AM >>>>>>>>>> To: Scott Orton; Charles Eckel (eckelcu); Parthasarathi >>>>>>> R (partr); >>>>>>>>>> siprec@ietf.org >>>>>>>>>> Subject: RE: [siprec] comments on >> draft-ram-siprec-metadata-04 >>>>>>>>>> >>>>>>>>>> Scott, >>>>>>>>>> >>>>>>>>>> Some folks wanted to be able to group related CSs together >>>>>>>>> (e.g., a CS >>>>>>>>>> between a customer and an agent and a second CS >>>>>>> resulting from the >>>>>>>>>> customer being transferred to a second agent). I will >>>>>>> leave it to >>>>>>>>> those >>>>>>>>>> folks to add to this. >>>>>>>>>> >>>>>>>>>> John (chair hat on) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Scott Orton [mailto:sorton@broadsoft.com] >>>>>>>>>>> Sent: 31 March 2011 17:43 >>>>>>>>>>> To: Elwell, John; Charles Eckel (eckelcu); Parthasarathi R >>>>>>>>>>> (partr); siprec@ietf.org >>>>>>>>>>> Subject: RE: [siprec] comments on >>>> draft-ram-siprec-metadata-04 >>>>>>>>>>> >>>>>>>>>>> John, Charles, Partha, >>>>>>>>>>> I have a question. What is the purpose of the >> CS Group? I >>>> do >>>>>>>>>>> not see it adding anything to the metadata. To me it >>>> seems that >>>>>>>>>>> the whole purpose of the metadata is to describe the >>>> recording >>>>>>>>>>> session to the SRS. Looking at the requirements I see 3 >>>>>>>>>>> relationships that the spec is attempting to describe: >>>>>>>>>>> >>>>>>>>>>> A one to one relationship - one communication session to one >>>>>>>>>>> recording session A one to many relationship - one >>>> communication >>>>>>>>>>> session with multiple Recording sessions >>>>>>>>>>> - one Recording session >>>> made up of >>>>>>>>>>> multiple communications sessions >>>>>>>>>>> >>>>>>>>>>> The current metadata format allows all of these and I do not >>>> see >>>>>>>>>>> what the group is adding. >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> Scott >>>>>>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> siprec mailing list >>>>>> siprec@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>> >>>>> _______________________________________________ >>>>> siprec mailing list >>>>> siprec@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/siprec >>>> >> From rmohanr@cisco.com Tue Apr 19 08:42:27 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 00AF3E0691 for ; Tue, 19 Apr 2011 08:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c92ztj8g-2T5 for ; Tue, 19 Apr 2011 08:42:25 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfc.amsl.com (Postfix) with ESMTP id DAA72E0664 for ; Tue, 19 Apr 2011 08:42:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=12196; q=dns/txt; s=iport; t=1303227744; x=1304437344; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=+TwZnsH0rhfZss3SltRiCI1vNbqWmC4NcuJkkYwaw1E=; b=D881a0H/kNgdyiD8JhoWWQUtsbzHsTKIphvadDEwsYEi/dcvFQQA9VyL upcNae2ECMTvnL2N2usJx9UeU7qDOB7o2Hp6z7OA290MrmryWjP7huyuo mElBIYgA/kuencofqgiAwjJeRCeqmF0zlMz1gzfxLQBO5+gScyrxBOZrb U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcBALqsrU2Q/khLgWdsb2JhbACXI44JFAEBFiYlqAGcaIJ/gnIEhWWMJQ X-IronPort-AV: E=Sophos;i="4.64,240,1301875200"; d="scan'208";a="26314026" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 19 Apr 2011 15:42:23 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3JFgM1a019104; Tue, 19 Apr 2011 15:42:23 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, 19 Apr 2011 21:12:22 +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, 19 Apr 2011 21:12:19 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD06133A51@XMB-BGL-417.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] comments on draft-ram-siprec-metadata-04 Thread-Index: Acv0kBVIJHb7ZeT6Szm6WV4C4fEO8gAfxgZQAltX3dAABC5+YAAGuy5A References: <21866C7FE177A4449B9136B5B24B1B130BC011290A@EXMBXCLUS01.citservers.local><21866C7FE177A4449B9136B5B24B1B130BC011294A@EXMBXCLUS01.citservers.local><35BCE99A477D6A4986FB2216D8CF2CFD05DD8C0C@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD05EF92EF@XMB-BGL-417.cisco.com> <4D9CBD8C.4010901@cisco.com> <35 BCE99A47 7D6A4986FB22 16D8CF2CFD06133966@XMB-BGL-417.cisco.com> From: "Ram Mohan R (rmohanr)" To: "Elwell, John" , "Parthasarathi R (partr)" , "Paul Kyzivat (pkyzivat)" , X-OriginalArrivalTime: 19 Apr 2011 15:42:22.0137 (UTC) FILETIME=[5F8F2A90:01CBFEA8] Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 19 Apr 2011 15:42:27 -0000 Hi John, Yes I agree with you on waiting till get more clarity on the identifiers (UUID) and its need for each blocks. I will respond with my comments on the identifiers in the other thread. Regards, Ram > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Tuesday, April 19, 2011 6:03 PM > To: Ram Mohan R (rmohanr); Parthasarathi R (partr); Paul Kyzivat > (pkyzivat); siprec@ietf.org > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 >=20 > Ram, >=20 > I am not quite sure whether that is an issue or not. If we go for a > single unique identifier, I suspect it would need to identify a CS, not > an RS. In fact I was waiting to hear more from Paul on his assertion > below, that perhaps none of the elements has a direct relationship with > an RS. I am OK leaving the relationship in for now. It might become > clearer when we resolve the question of identifiers. >=20 > John (as individual) >=20 > > -----Original Message----- > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > Sent: 19 April 2011 11:31 > > To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); > > siprec@ietf.org; Elwell, John > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > > > Partha, > > I agree with your concern here. > > > > John, > > Are you ok with retaining the below relation in the model, If > > yes we can > > close this open item of the model > > > > +-------------------------------+ 1 > > | Recording Session (RS) |---------------+ > > +-------------------------------+ | > > |1..* |1..* | > > | | | > > |0..* |0..* | > > +--------------+ +-----------------+ | > > |Communication | | Communication | 1 | > > | Session (CS) |----------| Session (CS) |---| > > | Group |0..1 1..*| | | 0..* +----------+ > > +--------------+ +-----------------+ |------|Extension | > > 1| | 0..* |1..* | | Data | > > | | 2..* |0..* | +----------+ > > 0..*| > > +---------+ > > |Extension| > > | Data | > > +---------+ > > > > Regards, > > Ram > > > > > -----Original Message----- > > > From: Parthasarathi R (partr) > > > Sent: Thursday, April 07, 2011 4:07 PM > > > To: Paul Kyzivat (pkyzivat); siprec@ietf.org; Ram Mohan R > (rmohanr); > > > Elwell, John > > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > > > > > John/Ram, > > > > > > I see the issue without direct link between RS and CSG. It may be > > tough > > > to correlate CSG to RS in SRS implementation. This issue is > > raised by > > > Hadriel in terms of having single unique id for metadata > > format draft. > > > I explained his concern in "Partial updates and identifiers" mail > > > thread. > > > > > > Also another issue: SRS may be interested in knowing list of > > associated > > > RS for a given CSG. > > > > > > Thanks > > > Partha > > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > > Behalf Of Paul Kyzivat (pkyzivat) > > > Sent: Thursday, April 07, 2011 12:53 AM > > > To: siprec@ietf.org > > > Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 > > > > > > John, > > > > > > I've been thinking about how everything relates to the RS, and that > > > maybe we should make some more major changes. > > > > > > What I'm thinking is that none of the elements have a direct > > > relationship to RS. Rather, each element is ultimately > > constructed as > > a > > > time series of values delivered in updates. Its the updates > > that have > > a > > > relationship to a RS - the one they are delivered in. That > > allows the > > > possibility that not all the updates come from the same RS. > > > > > > I haven't drawn a model diagram here because the concept is still > > > fuzzy. > > > Its a trial balloon - to see what others think. > > > > > > Thanks, > > > Paul > > > > > > On 4/6/2011 11:47 AM, Elwell, John wrote: > > > > Ram, > > > > > > > > I am not sure this answers my question. In the model you > > drew below, > > > a CSG has both a direct relationship with an RS and an indirect > > > relationship (via a CS). I was questioning whether we could > > remove the > > > direct relationship, on the basis that the indirect relationship is > > > sufficient. > > > > > > > > John (as individual) > > > > > > > > > > > >> -----Original Message----- > > > >> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > > >> Sent: 06 April 2011 15:52 > > > >> To: Elwell, John; Scott Orton; Charles Eckel (eckelcu); > > > Parthasarathi > > > >> R (partr); siprec@ietf.org > > > >> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > > >> > > > >> Hi John, > > > >> > > > >> Yes We have an indirect relationship in the current > > model. However > > > in > > > >> the current model it is REQUIRED to have a CSG as CS is > connected > > to > > > >> RS through CSG. However not all use cases would need CSG, IOW > CSG > > > has > > > >> to be optional and there should be direct association > > from CS to RS > > > >> even when CSG is absent. > > > >> > > > >> With the below associations we will have: > > > >> - An instance of RS can have Zero or more CSG blocks. > > > >> - An instance of RS can have Zero or more CS blocks. > > > >> - If a CSG is present it will have 1 or more CS. > > > >> - Each CS can be associated with Zero or 1 CSG. > > > >> > > > >> Let me know if you have any concerns. > > > >> > > > >> Regards, > > > >> Ram > > > >> > > > >>> -----Original Message----- > > > >>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > >>> Sent: Wednesday, April 06, 2011 6:16 PM > > > >>> To: Ram Mohan R (rmohanr); Scott Orton; Charles Eckel > (eckelcu); > > > >>> Parthasarathi R (partr); siprec@ietf.org > > > >>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > > >>> > > > >>> I am OK in principle, but I wonder whether there really > > > >> needs to be a > > > >>> relationship between CSG and RS. Isn't that relationship an > > > indirect > > > >>> relationship via CS? > > > >>> > > > >>> John (as individual) > > > >>> > > > >>> > > > >>>> -----Original Message----- > > > >>>> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > > >>>> Sent: 03 April 2011 18:13 > > > >>>> To: Scott Orton; Elwell, John; Charles Eckel (eckelcu); > > > >>>> Parthasarathi R (partr); siprec@ietf.org > > > >>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > > >>>> > > > >>>> Scott, > > > >>>> > > > >>>> I am ok to make this change to the model. I would like to > > > >> hear from > > > >>>> others if they have any issues in incorporating this change in > > the > > > >>>> model. > > > >>>> > > > >>>> The updated portion of the model will look like > > > >>>> > > > >>>> > > > >>>> +-------------------------------+ 1 > > > >>>> | Recording Session (RS) |---------------+ > > > >>>> +-------------------------------+ | > > > >>>> | 1..* |1..* | > > > >>>> | | | > > > >>>> | 0..* |0..* | > > > >>>> +--------------+ +-----------------+ | > > > >>>> |Communication | | Communication | 1 | > > > >>>> | Session (CS) |----------| Session (CS) |---| > > > >>>> | Group |0..1 1..*| | | 0..* > > > >> +----------+ > > > >>>> +--------------+ +-----------------+ > > > >> |------|Extension > > > >> | > > > >>>> 1| | 0..* |1..* | > > | Data > > > >> | > > > >>>> | | 2..* |0..* | > > > >> +----------+ > > > >>>> 0..*| > > > >>>> +---------+ > > > >>>> |Extension| > > > >>>> | Data | > > > >>>> +---------+ > > > >>>> > > > >>>> The only change in the association is : > > > >>>> A CS MUST be associated with zero or one CS-Group > > > >>>> > > > >>>> Rest of the associations remain same. Further the association > > > >>>> between CS and RS remains same as what is between CS-Group and > > RS. > > > >>>> > > > >>>> Comments ? > > > >>>> > > > >>>> Regards, > > > >>>> Ram > > > >>>> > > > >>>>> -----Original Message----- > > > >>>>> From: siprec-bounces@ietf.org > > > >> [mailto:siprec-bounces@ietf.org] On > > > >>>>> Behalf Of Scott Orton > > > >>>>> Sent: Friday, April 01, 2011 12:18 AM > > > >>>>> To: Elwell, John; Charles Eckel (eckelcu); Parthasarathi R > > > >> (partr); > > > >>>>> siprec@ietf.org > > > >>>>> Subject: Re: [siprec] comments on draft-ram-siprec-metadata- > 04 > > > >>>>> > > > >>>>> John, > > > >>>>> Thanks for the information. > > > >>>>> > > > >>>>> In that case I would like to see the CS group be > > > >> made optional. > > > >>>>> Rather than the CS pointing to the CS Group, I would like to > > > >>> suggest > > > >>>>> that the CS point to the RS and have the CS group stand > > > >>>> alone where it > > > >>>>> would just have its own ID and then a list of CS ids > > that belong > > > >> to > > > >>>> the > > > >>>>> group. > > > >>>>> > > > >>>>> Scott > > > >>>>> > > > >>>>> -----Original Message----- > > > >>>>> From: Elwell, John [mailto:john.elwell@siemens- > enterprise.com] > > > >>>>> Sent: Thursday, March 31, 2011 11:50 AM > > > >>>>> To: Scott Orton; Charles Eckel (eckelcu); Parthasarathi > > > >> R (partr); > > > >>>>> siprec@ietf.org > > > >>>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata- > 04 > > > >>>>> > > > >>>>> Scott, > > > >>>>> > > > >>>>> Some folks wanted to be able to group related CSs together > > > >>>> (e.g., a CS > > > >>>>> between a customer and an agent and a second CS > > > >> resulting from the > > > >>>>> customer being transferred to a second agent). I will > > > >> leave it to > > > >>>> those > > > >>>>> folks to add to this. > > > >>>>> > > > >>>>> John (chair hat on) > > > >>>>> > > > >>>>> > > > >>>>>> -----Original Message----- > > > >>>>>> From: Scott Orton [mailto:sorton@broadsoft.com] > > > >>>>>> Sent: 31 March 2011 17:43 > > > >>>>>> To: Elwell, John; Charles Eckel (eckelcu); Parthasarathi R > > > >>>>>> (partr); siprec@ietf.org > > > >>>>>> Subject: RE: [siprec] comments on > > draft-ram-siprec-metadata-04 > > > >>>>>> > > > >>>>>> John, Charles, Partha, > > > >>>>>> I have a question. What is the purpose of the CS Group? > I > > do > > > >>>>>> not see it adding anything to the metadata. To me it > > seems that > > > >>>>>> the whole purpose of the metadata is to describe the > > recording > > > >>>>>> session to the SRS. Looking at the requirements I see 3 > > > >>>>>> relationships that the spec is attempting to describe: > > > >>>>>> > > > >>>>>> A one to one relationship - one communication session to one > > > >>>>>> recording session A one to many relationship - one > > communication > > > >>>>>> session with multiple Recording sessions > > > >>>>>> - one Recording session > > made up of > > > >>>>>> multiple communications sessions > > > >>>>>> > > > >>>>>> The current metadata format allows all of these and I do not > > see > > > >>>>>> what the group is adding. > > > >>>>>> > > > >>>>>> Regards, > > > >>>>>> Scott > > > >>>>>> > > > >> > > > > _______________________________________________ > > > > siprec mailing list > > > > siprec@ietf.org > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > _______________________________________________ > > > siprec mailing list > > > siprec@ietf.org > > > https://www.ietf.org/mailman/listinfo/siprec > > From rmohanr@cisco.com Tue Apr 19 08:50:18 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D2451E0703 for ; Tue, 19 Apr 2011 08:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.014 X-Spam-Level: X-Spam-Status: No, score=-10.014 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eiKDzh554HoF for ; Tue, 19 Apr 2011 08:50:17 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfc.amsl.com (Postfix) with ESMTP id 54C68E0691 for ; Tue, 19 Apr 2011 08:50:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=16534; q=dns/txt; s=iport; t=1303228216; x=1304437816; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=FbOByBzfICEcOcd45GDGZu1Ye+8KjhX2p7+zWMFIDFQ=; b=QMPMlG8Q8uMuQKBeS84rTsEAFlAcYTVc/5B3oNxbFtdX2aSZRhFTzbhP lidaRoO+xFsBK26KoPrpS1qazKphZbDmbwYcTZFxqmexAaOFEIovRna8e x6gTJ2yiB+n+o5YQLc48OknJhgpGKHe5vx6SMQq6tLyz99UldEhbLU3T+ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcBACCurU2Q/khLgWdsb2JhbACXI44JFAEBFiYlp3mcaYJ/gnIEhWWMJQ X-IronPort-AV: E=Sophos;i="4.64,240,1301875200"; d="scan'208";a="84250065" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 19 Apr 2011 15:50:15 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3JFoETu021765; Tue, 19 Apr 2011 15:50:14 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, 19 Apr 2011 21:20:13 +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, 19 Apr 2011 21:20:12 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD06133A56@XMB-BGL-417.cisco.com> In-Reply-To: <4DADA8E6.9010006@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] comments on draft-ram-siprec-metadata-04 Thread-Index: Acv+pbws7MwochNUSB2j8RZ3ismj6AAAQrXw References: <21866C7FE177A4449B9136B5B24B1B130BC011290A@EXMBXCLUS01.citservers.local> <21866C7FE177A4449B9136B5B24B1B130BC011294A@EXMBXCLUS01.citservers.local> <35BCE99A477D6A4986FB2216D8CF2CFD05DD8C0C@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD05EF92EF@XMB-BGL-417.cisco.com> <4D9CBD8C.4010901@cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD06133966@XMB-BGL-417.cisco.com> <4DAD8A5F.4040506@cisco.com> <4DADA8E6.9010006@cisco.com> From: "Ram Mohan R (rmohanr)" To: "Paul Kyzivat (pkyzivat)" , "Elwell, John" X-OriginalArrivalTime: 19 Apr 2011 15:50:13.0631 (UTC) FILETIME=[789770F0:01CBFEA9] Cc: siprec@ietf.org Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 19 Apr 2011 15:50:19 -0000 John, Even If we tear down the RS, we can still have the same MS block in the model ( and in format identified by its unique identifier). Of course the properties of the MS will be different at different instances. In the first instance it will have the label attribute to RS1 SDP. In the second instance it can have label attribute pointing to RS2 SDP. This is just my thought and we should think through different scenarios to see if this can work Regards, Ram > -----Original Message----- > From: Paul Kyzivat (pkyzivat) > Sent: Tuesday, April 19, 2011 8:53 PM > To: Elwell, John > Cc: Ram Mohan R (rmohanr); Parthasarathi R (partr); siprec@ietf.org > Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 >=20 >=20 >=20 > On 4/19/2011 10:33 AM, Elwell, John wrote: > > I think I see where you are going. Each element in a series could > potentially be delivered over a different RS. This seems to imply an RS > only needs to exist momentarily. However, the RS has SDP that contains > the media descriptions, and a given media description, including it's > a=3Dlabel attribute tying it to a Media Stream object, will need to exist > continually, between the deltas. Tearing down an RS will also tear down > the delivery of media for a Media Stream to the SRS. So I am not > entirely sure what you have in mind. >=20 > First, the idea is only half baked, so certainly feel free to take > shots > at it. >=20 > And, in case of MS, perhaps you are right that you can't reference the > same MS from two different RS. >=20 > Or maybe you could. In principle an SRC could lose the RS dialog, > establish a new one, and then continue talking about the same CS and > MS. > (This could happen if the SRS server crashed and a backup took over for > it.) Its a different RTP stream on the RS, but its delivering data for > the same CS MS. >=20 > Since in the case of a persistent RS we are prepared to have a single > m-line in the RS represent (serially, not concurrently) different MSs, > its clear there isn't a 1:1 relationship. So why not two different RS > m-lines representing (serially) the same MS? >=20 > But the notion may be more important for other stuff that changes over > time. >=20 > Thanks, > Paul >=20 > > John > > > > > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: 19 April 2011 14:13 > >> To: Elwell, John > >> Cc: Ram Mohan R (rmohanr); Parthasarathi R (partr); siprec@ietf.org > >> Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 > >> > >> > >> > >> On 4/19/2011 8:32 AM, Elwell, John wrote: > >>> Ram, > >>> > >>> I am not quite sure whether that is an issue or not. If we > >> go for a single unique identifier, I suspect it would need to > >> identify a CS, not an RS. In fact I was waiting to hear more > >> from Paul on his assertion below, that perhaps none of the > >> elements has a direct relationship with an RS. I am OK > >> leaving the relationship in for now. It might become clearer > >> when we resolve the question of identifiers. > >> > >> I haven't worked out the details. The concept would require the > >> metamodel to be modified to explicitly represent the results > >> of updates. > >> Then, each individually updatable datum in the model would be tied > to > >> the update that delivered it, and thus to an RS in which it was > >> delivered and a timestamp for when it was delivered. Each > >> such updatable > >> datum would be represented as a time series of values. > >> > >> For instance, the relationship between media streams and > participants > >> could be represented either as: > >> > >> - each stream has a series for each participant in the stream. > >> Each element in the series identifies a change in the role > >> of the participant relative to that stream. > >> > >> - each participant has a series for each stream in which it > >> participates. Each element in the series identifies a change > >> in the role of the participant relative to the stream. > >> > >> In either case, each element in the series would refer to the RS > over > >> which it was delivered, and would have a timestamp indicating when > it > >> occurred. > >> > >> For instance, elements in the series might indicate: > >> - (alice:stream-1) sending@t1, inactive@t10, sending@t20, > inactive@t30 > >> - (bob:stream-1) recving@t2, inactive@t31 > >> - (carol:stream-1) recving@t8, inactive@t12, recving@t20, > inactive@t25 > >> - (ted:stream-1) sending@t10, inactive@t20 > >> > >> Thanks, > >> Paul > >> > >> > >>> John (as individual) > >>> > >>>> -----Original Message----- > >>>> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > >>>> Sent: 19 April 2011 11:31 > >>>> To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); > >>>> siprec@ietf.org; Elwell, John > >>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > >>>> > >>>> Partha, > >>>> I agree with your concern here. > >>>> > >>>> John, > >>>> Are you ok with retaining the below relation in the model, If > >>>> yes we can > >>>> close this open item of the model > >>>> > >>>> +-------------------------------+ 1 > >>>> | Recording Session (RS) |---------------+ > >>>> +-------------------------------+ | > >>>> |1..* |1..* | > >>>> | | | > >>>> |0..* |0..* | > >>>> +--------------+ +-----------------+ | > >>>> |Communication | | Communication | 1 | > >>>> | Session (CS) |----------| Session (CS) |---| > >>>> | Group |0..1 1..*| | | 0..* > >> +----------+ > >>>> +--------------+ +-----------------+ > >> |------|Extension | > >>>> 1| | 0..* |1..* | > >> | Data | > >>>> | | 2..* |0..* | > >> +----------+ > >>>> 0..*| > >>>> +---------+ > >>>> |Extension| > >>>> | Data | > >>>> +---------+ > >>>> > >>>> Regards, > >>>> Ram > >>>> > >>>>> -----Original Message----- > >>>>> From: Parthasarathi R (partr) > >>>>> Sent: Thursday, April 07, 2011 4:07 PM > >>>>> To: Paul Kyzivat (pkyzivat); siprec@ietf.org; Ram Mohan R > >> (rmohanr); > >>>>> Elwell, John > >>>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > >>>>> > >>>>> John/Ram, > >>>>> > >>>>> I see the issue without direct link between RS and CSG. It may be > >>>> tough > >>>>> to correlate CSG to RS in SRS implementation. This issue is > >>>> raised by > >>>>> Hadriel in terms of having single unique id for metadata > >>>> format draft. > >>>>> I explained his concern in "Partial updates and identifiers" mail > >>>>> thread. > >>>>> > >>>>> Also another issue: SRS may be interested in knowing list of > >>>> associated > >>>>> RS for a given CSG. > >>>>> > >>>>> Thanks > >>>>> Partha > >>>>> > >>>>> -----Original Message----- > >>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >>>>> Behalf Of Paul Kyzivat (pkyzivat) > >>>>> Sent: Thursday, April 07, 2011 12:53 AM > >>>>> To: siprec@ietf.org > >>>>> Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 > >>>>> > >>>>> John, > >>>>> > >>>>> I've been thinking about how everything relates to the > >> RS, and that > >>>>> maybe we should make some more major changes. > >>>>> > >>>>> What I'm thinking is that none of the elements have a direct > >>>>> relationship to RS. Rather, each element is ultimately > >>>> constructed as > >>>> a > >>>>> time series of values delivered in updates. Its the updates > >>>> that have > >>>> a > >>>>> relationship to a RS - the one they are delivered in. That > >>>> allows the > >>>>> possibility that not all the updates come from the same RS. > >>>>> > >>>>> I haven't drawn a model diagram here because the concept is still > >>>>> fuzzy. > >>>>> Its a trial balloon - to see what others think. > >>>>> > >>>>> Thanks, > >>>>> Paul > >>>>> > >>>>> On 4/6/2011 11:47 AM, Elwell, John wrote: > >>>>>> Ram, > >>>>>> > >>>>>> I am not sure this answers my question. In the model you > >>>> drew below, > >>>>> a CSG has both a direct relationship with an RS and an indirect > >>>>> relationship (via a CS). I was questioning whether we could > >>>> remove the > >>>>> direct relationship, on the basis that the indirect > >> relationship is > >>>>> sufficient. > >>>>>> > >>>>>> John (as individual) > >>>>>> > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > >>>>>>> Sent: 06 April 2011 15:52 > >>>>>>> To: Elwell, John; Scott Orton; Charles Eckel (eckelcu); > >>>>> Parthasarathi > >>>>>>> R (partr); siprec@ietf.org > >>>>>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > >>>>>>> > >>>>>>> Hi John, > >>>>>>> > >>>>>>> Yes We have an indirect relationship in the current > >>>> model. However > >>>>> in > >>>>>>> the current model it is REQUIRED to have a CSG as CS is > >> connected > >>>> to > >>>>>>> RS through CSG. However not all use cases would need > >> CSG, IOW CSG > >>>>> has > >>>>>>> to be optional and there should be direct association > >>>> from CS to RS > >>>>>>> even when CSG is absent. > >>>>>>> > >>>>>>> With the below associations we will have: > >>>>>>> - An instance of RS can have Zero or more CSG blocks. > >>>>>>> - An instance of RS can have Zero or more CS blocks. > >>>>>>> - If a CSG is present it will have 1 or more CS. > >>>>>>> - Each CS can be associated with Zero or 1 CSG. > >>>>>>> > >>>>>>> Let me know if you have any concerns. > >>>>>>> > >>>>>>> Regards, > >>>>>>> Ram > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > >>>>>>>> Sent: Wednesday, April 06, 2011 6:16 PM > >>>>>>>> To: Ram Mohan R (rmohanr); Scott Orton; Charles Eckel > >> (eckelcu); > >>>>>>>> Parthasarathi R (partr); siprec@ietf.org > >>>>>>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > >>>>>>>> > >>>>>>>> I am OK in principle, but I wonder whether there really > >>>>>>> needs to be a > >>>>>>>> relationship between CSG and RS. Isn't that relationship an > >>>>> indirect > >>>>>>>> relationship via CS? > >>>>>>>> > >>>>>>>> John (as individual) > >>>>>>>> > >>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > >>>>>>>>> Sent: 03 April 2011 18:13 > >>>>>>>>> To: Scott Orton; Elwell, John; Charles Eckel (eckelcu); > >>>>>>>>> Parthasarathi R (partr); siprec@ietf.org > >>>>>>>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata- > 04 > >>>>>>>>> > >>>>>>>>> Scott, > >>>>>>>>> > >>>>>>>>> I am ok to make this change to the model. I would like to > >>>>>>> hear from > >>>>>>>>> others if they have any issues in incorporating this change > in > >>>> the > >>>>>>>>> model. > >>>>>>>>> > >>>>>>>>> The updated portion of the model will look like > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> +-------------------------------+ 1 > >>>>>>>>> | Recording Session (RS) |---------------+ > >>>>>>>>> +-------------------------------+ | > >>>>>>>>> | 1..* |1..* | > >>>>>>>>> | | | > >>>>>>>>> | 0..* |0..* | > >>>>>>>>> +--------------+ +-----------------+ | > >>>>>>>>> |Communication | | Communication | 1 | > >>>>>>>>> | Session (CS) |----------| Session (CS) |---| > >>>>>>>>> | Group |0..1 1..*| | | 0..* > >>>>>>> +----------+ > >>>>>>>>> +--------------+ +-----------------+ > >>>>>>> |------|Extension > >>>>>>> | > >>>>>>>>> 1| | 0..* |1..* | > >>>> | Data > >>>>>>> | > >>>>>>>>> | | 2..* |0..* | > >>>>>>> +----------+ > >>>>>>>>> 0..*| > >>>>>>>>> +---------+ > >>>>>>>>> |Extension| > >>>>>>>>> | Data | > >>>>>>>>> +---------+ > >>>>>>>>> > >>>>>>>>> The only change in the association is : > >>>>>>>>> A CS MUST be associated with zero or one CS-Group > >>>>>>>>> > >>>>>>>>> Rest of the associations remain same. Further the association > >>>>>>>>> between CS and RS remains same as what is between CS-Group > and > >>>> RS. > >>>>>>>>> > >>>>>>>>> Comments ? > >>>>>>>>> > >>>>>>>>> Regards, > >>>>>>>>> Ram > >>>>>>>>> > >>>>>>>>>> -----Original Message----- > >>>>>>>>>> From: siprec-bounces@ietf.org > >>>>>>> [mailto:siprec-bounces@ietf.org] On > >>>>>>>>>> Behalf Of Scott Orton > >>>>>>>>>> Sent: Friday, April 01, 2011 12:18 AM > >>>>>>>>>> To: Elwell, John; Charles Eckel (eckelcu); Parthasarathi R > >>>>>>> (partr); > >>>>>>>>>> siprec@ietf.org > >>>>>>>>>> Subject: Re: [siprec] comments on > >> draft-ram-siprec-metadata-04 > >>>>>>>>>> > >>>>>>>>>> John, > >>>>>>>>>> Thanks for the information. > >>>>>>>>>> > >>>>>>>>>> In that case I would like to see the CS group be > >>>>>>> made optional. > >>>>>>>>>> Rather than the CS pointing to the CS Group, I would like to > >>>>>>>> suggest > >>>>>>>>>> that the CS point to the RS and have the CS group stand > >>>>>>>>> alone where it > >>>>>>>>>> would just have its own ID and then a list of CS ids > >>>> that belong > >>>>>>> to > >>>>>>>>> the > >>>>>>>>>> group. > >>>>>>>>>> > >>>>>>>>>> Scott > >>>>>>>>>> > >>>>>>>>>> -----Original Message----- > >>>>>>>>>> From: Elwell, John > >> [mailto:john.elwell@siemens-enterprise.com] > >>>>>>>>>> Sent: Thursday, March 31, 2011 11:50 AM > >>>>>>>>>> To: Scott Orton; Charles Eckel (eckelcu); Parthasarathi > >>>>>>> R (partr); > >>>>>>>>>> siprec@ietf.org > >>>>>>>>>> Subject: RE: [siprec] comments on > >> draft-ram-siprec-metadata-04 > >>>>>>>>>> > >>>>>>>>>> Scott, > >>>>>>>>>> > >>>>>>>>>> Some folks wanted to be able to group related CSs together > >>>>>>>>> (e.g., a CS > >>>>>>>>>> between a customer and an agent and a second CS > >>>>>>> resulting from the > >>>>>>>>>> customer being transferred to a second agent). I will > >>>>>>> leave it to > >>>>>>>>> those > >>>>>>>>>> folks to add to this. > >>>>>>>>>> > >>>>>>>>>> John (chair hat on) > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> -----Original Message----- > >>>>>>>>>>> From: Scott Orton [mailto:sorton@broadsoft.com] > >>>>>>>>>>> Sent: 31 March 2011 17:43 > >>>>>>>>>>> To: Elwell, John; Charles Eckel (eckelcu); Parthasarathi R > >>>>>>>>>>> (partr); siprec@ietf.org > >>>>>>>>>>> Subject: RE: [siprec] comments on > >>>> draft-ram-siprec-metadata-04 > >>>>>>>>>>> > >>>>>>>>>>> John, Charles, Partha, > >>>>>>>>>>> I have a question. What is the purpose of the > >> CS Group? I > >>>> do > >>>>>>>>>>> not see it adding anything to the metadata. To me it > >>>> seems that > >>>>>>>>>>> the whole purpose of the metadata is to describe the > >>>> recording > >>>>>>>>>>> session to the SRS. Looking at the requirements I see 3 > >>>>>>>>>>> relationships that the spec is attempting to describe: > >>>>>>>>>>> > >>>>>>>>>>> A one to one relationship - one communication session to > one > >>>>>>>>>>> recording session A one to many relationship - one > >>>> communication > >>>>>>>>>>> session with multiple Recording sessions > >>>>>>>>>>> - one Recording session > >>>> made up of > >>>>>>>>>>> multiple communications sessions > >>>>>>>>>>> > >>>>>>>>>>> The current metadata format allows all of these and I do > not > >>>> see > >>>>>>>>>>> what the group is adding. > >>>>>>>>>>> > >>>>>>>>>>> Regards, > >>>>>>>>>>> Scott > >>>>>>>>>>> > >>>>>>> > >>>>>> _______________________________________________ > >>>>>> siprec mailing 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 Apr 19 14:24:40 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9490EE086D for ; Tue, 19 Apr 2011 14:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.446 X-Spam-Level: X-Spam-Status: No, score=-9.446 tagged_above=-999 required=5 tests=[AWL=-0.647, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwjyrKNoQhhi for ; Tue, 19 Apr 2011 14:24:37 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfc.amsl.com (Postfix) with ESMTP id 11B7DE080A for ; Tue, 19 Apr 2011 14:24:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=20736; q=dns/txt; s=iport; t=1303248277; x=1304457877; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=+jTYsli/1K/C9gVN1BWB3aGPGyKlu0DqvthYBh/3MU8=; b=iFuJrF7khda+NtkMJ/3j1xLSTKIZUX1j6ScdB380lcngfA12PiJmfd7N P5D/gBz0padhPHsY56W3O/S5Qn1JOprDvJLd6RyI52SSCCNR5zK6q/ps5 lxcqJXZ0QCRTtpvLKas/2V0wb6ZgSsz76TKEhbc8aHMjzUtBn52pb5Byq 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj4BAAf9rU2rRDoI/2dsb2JhbACXKY4Ld4hvn0qcb4MAgnEEhWeMIw X-IronPort-AV: E=Sophos;i="4.64,241,1301875200"; d="scan'208";a="684152590" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-6.cisco.com with ESMTP; 19 Apr 2011 21:24:36 +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 p3JLOZSI027675; Tue, 19 Apr 2011 21:24:35 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, 19 Apr 2011 14:24:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: ETPn HNZx JCxF J6Fk LNY6 LwR8 OQEg Pd8Z Rhr2 SoV8 Tm0w V8/c XGTx YIN5 a4RK htqk; 3; aABrAGEAcABsAGEAbgBAAGEAYwBtAGUAcABhAGMAawBlAHQALgBjAG8AbQA7AGoAbwBoAG4ALgBlAGwAdwBlAGwAbABAAHMAaQBlAG0AZQBuAHMALQBlAG4AdABlAHIAcAByAGkAcwBlAC4AYwBvAG0AOwBzAGkAcAByAGUAYwBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {94DDCAA7-30C8-4AED-B561-DB280448FDE1}; ZQBjAGsAZQBsAGMAdQBAAGMAaQBzAGMAbwAuAGMAbwBtAA==; Tue, 19 Apr 2011 21:24:27 GMT; UgBFADoAIABbAHMAaQBwAHIAZQBjAF0AIABQAGEAcgB0AGkAYQBsACAAdQBwAGQAYQB0AGUAcwAgAGEAbgBkACAAaQBkAGUAbgB0AGkAZgBpAGUAcgBzAA== MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {94DDCAA7-30C8-4AED-B561-DB280448FDE1} Content-class: urn:content-classes:message Date: Tue, 19 Apr 2011 14:24:27 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Partial updates and identifiers Thread-Index: Acv0jVXI4ji2YTo+SquJ6T6YR3i+lQAdOkDgAEETmvAAg54qsAADKDEgAADSn+AAEAO1UAANZylQAXAZhbAAHzy2EA== References: <4D9CB8E1.7030402@cisco.com> From: "Charles Eckel (eckelcu)" To: "Parthasarathi R (partr)" , "Elwell, John" , "Paul Kyzivat (pkyzivat)" , X-OriginalArrivalTime: 19 Apr 2011 21:24:35.0100 (UTC) FILETIME=[2E28ADC0:01CBFED8] Cc: "Peter Saint-Andre \(psaintan\)" , "Joe Hildebrand \(jhildebr\)" Subject: Re: [siprec] Partial updates and identifiers X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 19 Apr 2011 21:24:40 -0000 Hi Partha, I think that participants need to be unique within the recording session, even if they span multiple CSs. I do not see a need to make them unique across recording sessions. It would be nice, but I think that is out of scope for SIPREC. Cheers, Charles > -----Original Message----- > From: Parthasarathi R (partr) > Sent: Monday, April 18, 2011 11:50 PM > To: Charles Eckel (eckelcu); 'Elwell, John'; Paul Kyzivat (pkyzivat); 'siprec@ietf.org' > Cc: Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr); 'Hadriel Kaplan' > Subject: RE: [siprec] Partial updates and identifiers >=20 > Hi all, >=20 > As per the progress in another mail thread (http://www.ietf.org/mail- > archive/web/siprec/current/msg01864.html), there is no known usecase wherein participant involved in > RS but not involved in CS directly. IOW, participant is always within CS. This change in metadata > model makes us to re-look whether participant shall be unique id within CS (something like xml:id) > rather than globally unique id. >=20 > The open question is whether participant in multiple CS within single RS should have same id or not. > Example: Alice acts as SRC and the scenario is as follows: >=20 > 1) Alice establish CS1 with Bob, RS is established between Alice & SRS, CS1 details with Alice & Bob > as participant is passed > 2) Bob transfer the session to Carol > 3) New CS2 is established between Alice & Carol, RS is updated with new CS2 info having Alice & Carol > as participants >=20 > The open question are >=20 > 1) At step 3, whether Alice MUST have the same unique id as in step 1 or it is not mandatory? >=20 > 2) If required to be unique across RS, whether xml:id serve the purpose? >=20 > Thanks > Partha >=20 > -----Original Message----- > From: Charles Eckel (eckelcu) > Sent: Tuesday, April 12, 2011 4:23 AM > To: Elwell, John; Parthasarathi R (partr); Paul Kyzivat (pkyzivat); siprec@ietf.org > Cc: Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr); Hadriel Kaplan > Subject: RE: [siprec] Partial updates and identifiers >=20 > Hi John, >=20 > I have attached the last e-mail I have from the thread in which I first raised this issue. > Unfortunately, I do not have the e-mail with the ultimate agreement, but maybe someone else does or > this will help prompt some memories. >=20 > Cheers, > Charles >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Elwell, John > > Sent: Monday, April 11, 2011 9:46 AM > > To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); siprec@ietf.org > > Cc: Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr); Hadriel > > Kaplan > > Subject: Re: [siprec] Partial updates and identifiers > > > > Partha, > > > > Thanks for reminding me - I now recall the discussion some > > weeks/months ago about the participants obtained from the conference > > event package. I was never particularly comfortable with the fact > > these were not considered part of the CS. While that might be correct > > if we consider the CS to be the SIP dialog between the SRC and the > > conference focus, taking a broader view of CS those participants behind the focus could be > considered part of the CS. I don't particularly want to open up the old discussion if people are happy > with what we have, but something doesn't seem quite right to me. > > > > For example, if these "participants" are not considered part of the > > CS, and if we don't have specific information about their involvement > > in media streams, do they really merit being considered Participant objects? > > > > In other words, two possible approaches are: > > > > 1) The CS extends only as far as the focus / mixer. The focus/mixer is > > a "Participant" and the users behind the focus are not separate > > Participants but are just additional data associated with the > > focus/mixer Participant. The only Media Streams we are concerned with are between the mixer and the > SRC. > > > > 2) The CS extends beyond the focus/mixer to users learned via the > > conference event package, each of those users is a separate > > Participant object, and we are concerned with Media Stream objects > > that those participants send and receive. I am not sure how feasible this approach is, because I am > not sure that the SRC can obtain enough information about media streams at users behind the > focus/mixer. > > > > It seems the present solution is somewhere between the two, which is why I am uncomfortable. > > > > Regards, > > > > John (as individual) > > > > > > > -----Original Message----- > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > Sent: 11 April 2011 10:29 > > > To: Elwell, John; Paul Kyzivat (pkyzivat); siprec@ietf.org > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe Hildebrand > > > (jhildebr) > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > John, > > > > > > Please read inline. > > > > > > Thanks > > > Partha > > > > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > Sent: Monday, April 11, 2011 2:11 PM > > > To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); > > > siprec@ietf.org > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe Hildebrand > > > (jhildebr) > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > > > > > > > > -----Original Message----- > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > Sent: 11 April 2011 08:35 > > > > To: Elwell, John; Paul Kyzivat (pkyzivat); siprec@ietf.org > > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe Hildebrand > > > > (jhildebr) > > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > > > John, > > > > > > > > As I mentioned below, stream block will be unique within CS, (not > > > > required to be unique across multiple CS) and so, xml:id or > > > enhancing > > > > the normative statement of RFC 4574 label attribute to be unique > > > > within CS will serve the purpose. I'm fine with any of the above > > > > mentioned id. > > > > Please note that RFC 4574 "label" attribute is the nature > > > data for RS > > > > dialog. > > > > > > > > In case participant within CS, xml:id will serve the purpose but > > > > we need to get more clarity about participants who are not > > > part of CS but > > > > > > > within RS. > > > [JRE] If I understand the figure in section 3 of metadata-04 > > > correctly, a Participant can have a relationship with a CS, but no > > > direct relationship with an RS. > > > > > > Sorry, I mixed up my statement with the latest update of > > > making CSG optional. As per Sec 3 of metadata-04, participant has > > > direct relationship with CSG in case CS is left completely > > > unattached. In case CSG is optional, then participant will have > > > direct relationship with RS in case there is no relationship between > > > CS and participant. > > > > > > > > > So a participant that does not have a relationship with a CS is > > > left completely unattached, unless it has a relationship with a > > > Media Stream (which always has a relationship with a CS). So to > > > summarize: > > > - a Participant can have a direct relationship with a CS; or > > > - a Participant can have an indirect relationship with a CS (via a > > > Media Stream); agreed > > > - a Participant can have no relationship with a CS, and therefore no > > > relationship with an RS. > > > Do we really need this last case? > > > > > > I'm happy if the last case is not required because it > > > simplify the solution and there is no need of unique id for > > > participant. But SRS implementers may prefer to have relationship > > > with participant and RS. I wish more opinion before taking decision > > > whether to remove the last case > > > > > > > Because CS may span across different RS how about the > > > participant who > > > > are not part of CS? > > > [JRE] I don't understand the words "Because CS may span across > > > different RS", because in the rest of the sentence you are talking > > > about a Participant that is not part of a CS. > > > > > > > Ex: One of the user in the conference acts as SRC, fetch > > > participant > > > > info using conferene package and new RS is created during initial > > > > conference creation and hold&resume of a user within CS. > > > [JRE] I am not sure what you are trying to say here. I would > > > consider a user whose identity is obtained via a conference event > > > package as being part of the CS. > > > > > > I'm trying to give the example where participant is not > > > associated with CS directly but related to CSG (/RS). This scenario > > > was considered as a blocking in -03 version of metadata. I'm not > > > arguing to have this scenario but it is major concern for few folks. > > > > > > CS is between focus and UA, UA acts as SRC, UA receives the > > > participant info via conference event package but those participants > > > are not related in CS directly (and only focus is related) but they > > > contributed for the mixed stream. > > > > > > That user is sending/receiving Media Streams that are part of a CS, > > > or if it isn't sending/receiving Media Streams, what is the > > > relevance of that Participant? > > > > > > Mixed media stream from focus to UA belongs to the > > > Conference event package participants. There participant are not > > > directly involved as part of CS. Why would we create a > > > new RS for such a participant? > > > RS is not created for participant. Multiple RS shall be > > > created the same CS during the different time frame as shown below > > > > > > <-------------------CS1-------------> > > > <---RS1--> <---RS2------> > > > > > > CS1 is between UA (SRC) and focus whereas RS1, RS2 is between UA > > > (SRC) and SRS. Here tangling (conference event package) participant > > > has to be grouped together in RS1, RS2 by some means through given > > > metadata. The question whether this corner has to be solved ? > > > > > > > > > John (as individual) > > > > > > > > > > > > > > > > > Thanks > > > > Partha > > > > > > > > -----Original Message----- > > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > Sent: Friday, April 08, 2011 9:36 PM > > > > To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); > > > siprec@ietf.org > > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe Hildebrand > > > > (jhildebr) > > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > > > Focusing just on participant and stream for the time being, > > > do these > > > > need to be unique across multiple CSs or not? > > > > > > > > John > > > > > > > > > -----Original Message----- > > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > > Sent: 07 April 2011 10:51 > > > > > To: Paul Kyzivat (pkyzivat); siprec@ietf.org; Elwell, John > > > > > Cc: Hadriel Kaplan; Peter Saint-Andre (psaintan); Joe Hildebrand > > > > > (jhildebr) > > > > > Subject: RE: [siprec] Partial updates and identifiers > > > > > > > > > > John, > > > > > > > > > > Sorry for the lengthy mail but it contains lot of analysis and > > > > > reasoning for this id approach. > > > > > > > > > > Adding to Paul's point, I wish to give more background and > > > > reason for > > > > > these globally unique id. Initially I had the impression that > > > > > the single unique id (RS dialog-id) in the recording (session > > > > level) and > > > > > some relevant natural id for the rest of the element will > > > serve the > > > > > purpose. > > > > > There are usecases where this assumption fails. Even I have > > > > thought of > > > > > > > > > using "xml:id" instead of URN UUID to avoid long string but > > > > xml:id may > > > > > > > > > not end up with unique value always. Our analysis for URN > > > UUID for > > > > > each level is as follows and please provide your input in case > > > > > id shall be > > > > > tweaked: > > > > > > > > > > 1) Recording block: The reason for globally unique id is > > > > that multiple > > > > > > > > > SRC with same id to single SRS. > > > > > > > > > > Topology: > > > > > > > > > > SRC1 SRC2 > > > > > | | > > > > > | ----(RS1-ID1)-----SRS1 > > > > > | > > > > > ---(RS2-ID1)------------------SRS1 > > > > > > > > > > In the above topology, it is possible for ID1 is generated by > > > > > both > > > > > SRC1 and SRC2 at the same time. > > > > > > > > > > 2) group (CSG) block: Grouping mechanism (Hadriel > > > session-id, Paul > > > > > Jones > > > > > Session-UUID) is outside the scope of SIPREC. URN UUID > > > > abstracts the > > > > > exact mechanism to SRS and provides the information only > > > about the > > > > > group of CS from SRC perspective. It possible that group may > > > > > span across multiple RS and It is up to SRS to group and view > > > as single > > > > > recording. > > > > > Here, the single level id in the top will fail. The counter > > > > argument > > > > > is to force the single RS having complete CSG but it*may not* be > > > > > possible in SRC implementation. Here, xml:id will not serve the > > > > > purpose > > > > > > > > > > 3) session (CS) block: At the immediate look, session > > > falls exactly > > > > > under recording block. Use case 3 of draft-ietf-siprec-req-09 > > > > > illustrates where CS span across multiple RS. This > > > > requirement calls > > > > > for unique id in session by which these session shall be > > > viewed as > > > > > single CS even though there is no group exists among > > > them. IMO, in > > > > > case session should not have globally unique id, then it is > > > > preferred > > > > > to remove usecase 3 in the requirement. > > > > > > > > > > 4) participant block: It needs some id which may be AOR but > > > > AOR is not > > > > > > > > > unique. IMO, xml:id may serve the purpose with session > > > > unique id. The > > > > > trick exists for participant who are not associated with > > > > CS. We shall > > > > > discuss and fine tune if required. > > > > > > > > > > 5) stream block: Label attribute shall be used as unique > > > > value but RFC > > > > > 4574 does not mandate label attribute has to be unique across > > > > > the dialog or CS and so, it may possible to change within RS and > > > > > no normative statement to stop this implementation. IMO, > > > > xml:id may serve > > > > > > > > > the purpose with session unique id. Here as well, We shall > > > > discuss and > > > > > > > > > fine tune if required. > > > > > > > > > > 6) extensiondata block: This is tracked in the separate > > > mail thread > > > > > whether unique id is required or not. Let us close this > > > as part of > > > > > that mail thread. > > > > > > > > > > Including explicitly Hadriel, Peter, Joe in this mail > > > > thread as they > > > > > have different view on this ID mechanism. > > > > > > > > > > I had offline discussion with Hadriel in Prague after > > > > SIPREC meeting > > > > > and my understanding of his major concern is that how SRS > > > > will be able > > > > > > > > > to design the database in case partial update does not have > > > > recording > > > > > (top) id information. I'll put more thought processing to close > > > > > Hadriel concern of how top id has to be tracked in case > > > > partial update > > > > > > > > > by which SRS implementation will be simplified in terms of > > > > aggregation > > > > > > > > > maintenance. > > > > > > > > > > Thanks > > > > > Partha > > > > > > > > > > -----Original Message----- > > > > > From: siprec-bounces@ietf.org > > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > > > > (pkyzivat) > > > > > Sent: Thursday, April 07, 2011 12:33 AM > > > > > To: siprec@ietf.org > > > > > Subject: Re: [siprec] Partial updates and identifiers > > > > > > > > > > John, > > > > > > > > > > For the moment we have proposed that the ids be conveyed in > > > > the form > > > > > of URIs that are globally unique, and specifically that > > > > they be UUID > > > > > URNs. > > > > > There is no dependency on the particular form of the URI, but > > > > > specifying they must be UUID URNs makes it possible to > > > perform some > > > > > internal optimizations for storage. > > > > > > > > > > The UUID URN is a pretty inefficient encoding. A UUID can > > > > be expressed > > > > > > > > > in 32 bits, so we could consider retaining UUIDs but alter the > > > > > encoding if its really an issue. However I am far from > > > > convinced that > > > > > the size of the IDs is going to be a major issue in the > > > > overall size > > > > > of messages, so I think its probably premature to worry about it. > > > > > > > > > > Because the ids can be expressed in 32 bits, the SRC and > > > > SRS can store > > > > > > > > > them internally that way, thus reducing the runtime cost of > > > > > maintaining the data. > > > > > > > > > > The use of unique ids is a significant part of the overall > > > > approach to > > > > > > > > > formatting updates. If somebody has a different concept > > > in mind it > > > > > could be useful to have an alternative proposal for the > > > > format. If we > > > > > had two worked out approaches we could compare the > > > > tradeoffs in each. > > > > > > > > > > Thanks, > > > > > Paul > > > > > > > > > > On 4/6/2011 10:24 AM, Elwell, John wrote: > > > > > > Much of the discussion on draft-ram-metadata-format in Prague > > > > > concerned the mechanism for performing partial updates and > > > > the use of > > > > > identifiers. The draft permits partial updates by allowing > > > > individual > > > > > objects (e.g., CS, participant, media stream) to be sent > > > > with updated > > > > > content, without having to send again other objects that have > > > > > not changed. So, for example, in a large conference, it would > > > > be possible > > > > > to add or modify an individual participant object without > > > having to > > > > > send all the other participant objects again. I do not recall > > > > > any opposition to this basic principle. > > > > > > > > > > > > However, to achieve this, every object requires an > > > > > identifier, and it > > > > > was asserted that these identifiers need to be globally > > > > unique for all > > > > > > > > > time. Although this might be efficient for updating an > > > > > individual object, when sending many objects (e.g., at the start > > > > > of a > > > > CS or when > > > > > refreshing the entire metadata), this can make the metadata very > > > > > bulky. > > > > > It depends, of course, on the format of the identifiers, > > > and it was > > > > > stated that there could be alternatives to UUID. > > > Nevertheless, some > > > > > people had concerns. These concerns also extended to the > > > > impact on the > > > > > > > > > database where metadata is stored, since it might not be > > > > feasible to > > > > > convert to a database-friendly mechanism for linking > > > > objects together. > > > > > > > > > > > > One alternative proposal during the meeting was to have a > > > > > > single > > > > > unique identifier at the top level (for the RS) and use local > > > > > identifiers for other objects. Thus when updating a single > > > > object, it > > > > > would be necessary to include the top level identifier as > > > > well as one > > > > > or more local identifiers. However, there were also concerns > > > > > this might not fulfil actual or perceived future requirements. > > > > > > > > > > > > Please continue discussion on this. > > > > > > > > > > > > John (as chair) > > > > > > _______________________________________________ > > > > > > siprec mailing list > > > > > > siprec@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > > > > _______________________________________________ > > > > > siprec mailing list > > > > > siprec@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > > > > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec From eckelcu@cisco.com Tue Apr 19 16:33:09 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C9A22E06CB for ; Tue, 19 Apr 2011 16:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.314 X-Spam-Level: X-Spam-Status: No, score=-10.314 tagged_above=-999 required=5 tests=[AWL=0.285, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YYXdxbCLfjmt for ; Tue, 19 Apr 2011 16:33:09 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfc.amsl.com (Postfix) with ESMTP id CE848E069D for ; Tue, 19 Apr 2011 16:33:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=1716; q=dns/txt; s=iport; t=1303255988; x=1304465588; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=9Ij5KfuRHPSgdOQidCxf5m1fOhwgXnt6VvbHSTCC+fk=; b=nKawOga/4/+U+jErBlXV2Nh53/r2hdH4bsA1MLN+vX75UWsgcVQTUH3F 4rM/gRhtOTVJONZ/zHWOZi96jbHqWWKQYjFX283yTLWftYYkF+Sk41SKn 3ixYwXiUPS3P/ugcXiQV8IfhY87YzttluoSlXQZiYm+TP+zOmDUt82QLu U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuoGAIgbrk2rRDoH/2dsb2JhbACXa41Md6g2nQ+FcQSFZ4wj X-IronPort-AV: E=Sophos;i="4.64,242,1301875200"; d="scan'208";a="684211569" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-6.cisco.com with ESMTP; 19 Apr 2011 23:33:08 +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 p3JNX8Im023151 for ; Tue, 19 Apr 2011 23:33:08 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, 19 Apr 2011 16:33:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: gcM= 5/s= CbJj EMUB EigO FUXL Fb+C GDGj HQWh Hb5X HeN+ JJiN Jb2u J8+4 LGqy LPoA; 1; cwBpAHAAcgBlAGMAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {04CD2087-4B1F-455C-9DE2-F63FE65EF5DD}; ZQBjAGsAZQBsAGMAdQBAAGMAaQBzAGMAbwAuAGMAbwBtAA==; Tue, 19 Apr 2011 23:33:05 GMT; bABhAHMAdAAgAGMAYQBsAGwAIABjAG8AbQBtAGUAbgB0ACAAbwBuACAAZAByAGEAZgB0AC0AaQBlAHQAZgAtAHMAaQBwAHIAZQBjAC0AcgBlAHEALQAwADkA MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {04CD2087-4B1F-455C-9DE2-F63FE65EF5DD} Content-class: urn:content-classes:message Date: Tue, 19 Apr 2011 16:33:05 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: last call comment on draft-ietf-siprec-req-09 Thread-Index: Acv+6iHPzt5x6M0JTuCSFxKHsei9hA== From: "Charles Eckel (eckelcu)" To: X-OriginalArrivalTime: 19 Apr 2011 23:33:08.0118 (UTC) FILETIME=[2379D360:01CBFEEA] Subject: [siprec] last call comment on draft-ietf-siprec-req-09 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 19 Apr 2011 23:33:10 -0000 I raised this comment previously, but it was not clear to me that we reached a conclusion. As it reads today, it is not clear to me if multiple SRCs per RS is supported. As I understand it, there may be multiple RSs per SRS, but only one SRS per RS. The question I have is: Q1. Is there a similar restriction of one SRC per RS? We could: A1. State the limitation of one SRC per RS. A2. Add a requirement that multiple SRCs per RS be supported. A3. Do nothing and leave it to interpretation. I am not happy with A3, and I previously was assuming A2. I could be convinced to go with A1.=20 I see supporting multiple SRCs as being useful in distributed recording scenarios in which there is not a single B2BUA or conference server or UA that is entirely responsible of the recording. For example, a peer to peer SIP network in which case the peers each decide whether or not their input should be recorded? Or a meeting with multiple presenters in which each presenter sends their own contributions to be recorded? Are such cases intentionally left out of scope? I can see use cases in which multiple parties might want to have their own recording of the same call/meeting, perhaps to record it from their perspective or to have their permissions and preferences associated with the recording. This lends itself nicely to the single SRC per RS model. But other scenarios exist, for scalability, or geographic distribution, or other reasons, in which allowing multiple SRCs to contribute to a single RS would be useful. Support for multiple SRCs definitely increases the complexity. Perhaps it is worth it, perhaps not. I would like to hear what others think. Thanks, Charles=20 From mperumal@cisco.com Tue Apr 19 22:47:10 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0D603E06ED for ; Tue, 19 Apr 2011 22:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.127 X-Spam-Level: X-Spam-Status: No, score=-10.127 tagged_above=-999 required=5 tests=[AWL=0.472, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAa56n9McOmx for ; Tue, 19 Apr 2011 22:47:09 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfc.amsl.com (Postfix) with ESMTP id 03EB0E066C for ; Tue, 19 Apr 2011 22:47:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=2971; q=dns/txt; s=iport; t=1303278430; x=1304488030; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=HrBUOrebmorbVB341+2YCB6YAtoP7op6EY02zUh/LIQ=; b=B78noxa3wh5qLD4MmaOWTGVLqnN4yEIv4mHTGxM7eIkzqkfrcgRLAtZx FAmHQ9dqAay8ooqL9gb+W4iqu04+QLljUH5j1LXDttr8w6BtQn/TEkaTY Y3Sk76To8X0LIbvhIfMzKcTtHA7PFPhC1iFLA3vF1jRgBzPAnpGGdvVp0 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMBALhyrk2Q/khLgWdsb2JhbACXNI4LFAEBFiYlqGydAoJ/gnIEhWeMLg X-IronPort-AV: E=Sophos;i="4.64,244,1301875200"; d="scan'208";a="26378207" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 20 Apr 2011 05:47:09 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3K5krL9002854 for ; Wed, 20 Apr 2011 05:47:07 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Apr 2011 11:17:05 +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: Wed, 20 Apr 2011 11:17:04 +0530 Message-ID: <1D062974A4845E4D8A343C653804920205425335@XMB-BGL-414.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] last call comment on draft-ietf-siprec-req-09 Thread-Index: Acv+6iHPzt5x6M0JTuCSFxKHsei9hAAMBsMA References: From: "Muthu ArulMozhi Perumal (mperumal)" To: "Charles Eckel (eckelcu)" , X-OriginalArrivalTime: 20 Apr 2011 05:47:05.0678 (UTC) FILETIME=[614DC6E0:01CBFF1E] Subject: Re: [siprec] last call comment on draft-ietf-siprec-req-09 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 20 Apr 2011 05:47:10 -0000 In the most trivial case, when the SRC is collocated with the participant's device (such as a phone) we would end up with multiple SRCs. However, each SRC can still setup its own RS to the SRS. If the SRS can identify these recording sessions as being part of the same recorded session, I think we would have achieved what we wanted to. My take: We could limit the model to one SRC per RS. However, we should facilitate the SRS to correlate multiple RSs as being part of the same recorded session -- this could perhaps be done by distributing a unique ID to each SRC which it includes in the metadata it sends to the SRS, with the distributing mechanism itself being outside the scope of SIPREC (for e.g, it could be a 3pcc generating the ID and providing it to each phone during call setup). Muthu=20 |-----Original Message----- |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Charles Eckel (eckelcu) |Sent: Wednesday, April 20, 2011 5:03 AM |To: siprec@ietf.org |Subject: [siprec] last call comment on draft-ietf-siprec-req-09 | |I raised this comment previously, but it was not clear to me that we |reached a conclusion. As it reads today, it is not clear to me if |multiple SRCs per RS is supported. As I understand it, there may be |multiple RSs per SRS, but only one SRS per RS. The question I have is: | |Q1. Is there a similar restriction of one SRC per RS? | |We could: |A1. State the limitation of one SRC per RS. |A2. Add a requirement that multiple SRCs per RS be supported. |A3. Do nothing and leave it to interpretation. | |I am not happy with A3, and I previously was assuming A2. I could be |convinced to go with A1. |I see supporting multiple SRCs as being useful in distributed recording |scenarios in which there is not a single B2BUA or conference server or |UA that is entirely responsible of the recording. For example, a peer to |peer SIP network in which case the peers each decide whether or not |their input should be recorded? Or a meeting with multiple presenters in |which each presenter sends their own contributions to be recorded? Are |such cases intentionally left out of scope? | |I can see use cases in which multiple parties might want to have their |own recording of the same call/meeting, perhaps to record it from their |perspective or to have their permissions and preferences associated with |the recording. This lends itself nicely to the single SRC per RS model. |But other scenarios exist, for scalability, or geographic distribution, |or other reasons, in which allowing multiple SRCs to contribute to a |single RS would be useful. | |Support for multiple SRCs definitely increases the complexity. Perhaps |it is worth it, perhaps not. I would like to hear what others think. | |Thanks, |Charles |_______________________________________________ |siprec mailing list |siprec@ietf.org |https://www.ietf.org/mailman/listinfo/siprec From rmohanr@cisco.com Wed Apr 20 02:45:41 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6E146E0695 for ; Wed, 20 Apr 2011 02:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.313 X-Spam-Level: X-Spam-Status: No, score=-10.313 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92Z0omaCFSo3 for ; Wed, 20 Apr 2011 02:45:40 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfc.amsl.com (Postfix) with ESMTP id 3084FE0689 for ; Wed, 20 Apr 2011 02:45:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=3695; q=dns/txt; s=iport; t=1303292740; x=1304502340; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=fy0IND+1xOBsZU5KUWq7x1BXnMrYeBeGQxkrPLZIlbU=; b=m4ai8U3d0qqsoYifGNS5PEfnnP3tvdP0JzwKdCZoLQQU4mu8KpUNTyJp vEaZc8BDSROcKvwIomoZ9YyILei5zsLz5nW4LbGb+DZ29MRH/sDSbLpzm exB2/y+pY+DTscvjL/sqpKJu4lQ1suwz2k8/JQwvjEqHNBAGawacBhJmh Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvgAAFGqrk2Q/khRgWdsb2JhbACXMY4KFAEBFiYlqmCcfIJ/gnIEhXKMNg X-IronPort-AV: E=Sophos;i="4.64,245,1301875200"; d="scan'208";a="84361613" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 20 Apr 2011 09:45:39 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3K9jcDR031266 for ; Wed, 20 Apr 2011 09:45:39 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); Wed, 20 Apr 2011 15:15:37 +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: Wed, 20 Apr 2011 15:15:36 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD06133CFF@XMB-BGL-417.cisco.com> In-Reply-To: <1D062974A4845E4D8A343C653804920205425335@XMB-BGL-414.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] last call comment on draft-ietf-siprec-req-09 Thread-Index: Acv+6iHPzt5x6M0JTuCSFxKHsei9hAAMBsMAAAja4zA= References: <1D062974A4845E4D8A343C653804920205425335@XMB-BGL-414.cisco.com> From: "Ram Mohan R (rmohanr)" To: "Muthu ArulMozhi Perumal (mperumal)" , "Charles Eckel (eckelcu)" , X-OriginalArrivalTime: 20 Apr 2011 09:45:37.0856 (UTC) FILETIME=[B406D400:01CBFF3F] Subject: Re: [siprec] last call comment on draft-ietf-siprec-req-09 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 20 Apr 2011 09:45:41 -0000 Muthu / Charles, I believe the requirement of multiple SRC per RS is out of scope of SIPREC now. Ram > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Muthu ArulMozhi Perumal (mperumal) > Sent: Wednesday, April 20, 2011 11:17 AM > To: Charles Eckel (eckelcu); siprec@ietf.org > Subject: Re: [siprec] last call comment on draft-ietf-siprec-req-09 >=20 > In the most trivial case, when the SRC is collocated with the > participant's device (such as a phone) we would end up with multiple > SRCs. However, each SRC can still setup its own RS to the SRS. If the > SRS can identify these recording sessions as being part of the same > recorded session, I think we would have achieved what we wanted to. >=20 > My take: We could limit the model to one SRC per RS. However, we should > facilitate the SRS to correlate multiple RSs as being part of the same > recorded session -- this could perhaps be done by distributing a unique > ID to each SRC which it includes in the metadata it sends to the SRS, > with the distributing mechanism itself being outside the scope of > SIPREC > (for e.g, it could be a 3pcc generating the ID and providing it to each > phone during call setup). >=20 > Muthu >=20 > |-----Original Message----- > |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Charles Eckel (eckelcu) > |Sent: Wednesday, April 20, 2011 5:03 AM > |To: siprec@ietf.org > |Subject: [siprec] last call comment on draft-ietf-siprec-req-09 > | > |I raised this comment previously, but it was not clear to me that we > |reached a conclusion. As it reads today, it is not clear to me if > |multiple SRCs per RS is supported. As I understand it, there may be > |multiple RSs per SRS, but only one SRS per RS. The question I have is: > | > |Q1. Is there a similar restriction of one SRC per RS? > | > |We could: > |A1. State the limitation of one SRC per RS. > |A2. Add a requirement that multiple SRCs per RS be supported. > |A3. Do nothing and leave it to interpretation. > | > |I am not happy with A3, and I previously was assuming A2. I could be > |convinced to go with A1. > |I see supporting multiple SRCs as being useful in distributed > recording > |scenarios in which there is not a single B2BUA or conference server or > |UA that is entirely responsible of the recording. For example, a peer > to > |peer SIP network in which case the peers each decide whether or not > |their input should be recorded? Or a meeting with multiple presenters > in > |which each presenter sends their own contributions to be recorded? Are > |such cases intentionally left out of scope? > | > |I can see use cases in which multiple parties might want to have their > |own recording of the same call/meeting, perhaps to record it from > their > |perspective or to have their permissions and preferences associated > with > |the recording. This lends itself nicely to the single SRC per RS > model. > |But other scenarios exist, for scalability, or geographic > distribution, > |or other reasons, in which allowing multiple SRCs to contribute to a > |single RS would be useful. > | > |Support for multiple SRCs definitely increases the complexity. Perhaps > |it is worth it, perhaps not. I would like to hear what others think. > | > |Thanks, > |Charles > |_______________________________________________ > |siprec mailing list > |siprec@ietf.org > |https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From john.elwell@siemens-enterprise.com Wed Apr 20 03:59:33 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A9618E0695 for ; Wed, 20 Apr 2011 03:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.74 X-Spam-Level: X-Spam-Status: No, score=-104.74 tagged_above=-999 required=5 tests=[AWL=1.259, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNf7gRY-VjDF for ; Wed, 20 Apr 2011 03:59:31 -0700 (PDT) Received: from mail216.messagelabs.com (mail216.messagelabs.com [85.158.143.99]) by ietfc.amsl.com (Postfix) with SMTP id 50AC7E0689 for ; Wed, 20 Apr 2011 03:59:31 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1303297170!2815335!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 7842 invoked from network); 20 Apr 2011 10:59:30 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-7.tower-216.messagelabs.com with SMTP; 20 Apr 2011 10:59:30 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 1AAB423F03DB; Wed, 20 Apr 2011 12:59:30 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 20 Apr 2011 12:59:30 +0200 From: "Elwell, John" To: "Ram Mohan R (rmohanr)" , "Paul Kyzivat (pkyzivat)" Date: Wed, 20 Apr 2011 12:59:28 +0200 Thread-Topic: [siprec] comments on draft-ram-siprec-metadata-04 Thread-Index: Acv+pbws7MwochNUSB2j8RZ3ismj6AAAQrXwACiVZgA= Message-ID: References: <21866C7FE177A4449B9136B5B24B1B130BC011290A@EXMBXCLUS01.citservers.local> <21866C7FE177A4449B9136B5B24B1B130BC011294A@EXMBXCLUS01.citservers.local> <35BCE99A477D6A4986FB2216D8CF2CFD05DD8C0C@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD05EF92EF@XMB-BGL-417.cisco.com> <4D9CBD8C.4010901@cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD06133966@XMB-BGL-417.cisco.com> <4DAD8A5F.4040506@cisco.com> <4DADA8E6.9010006@cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD06133A56@XMB-BGL-417.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD06133A56@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 Cc: "siprec@ietf.org" Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 20 Apr 2011 10:59:33 -0000 I guess the point I am trying to make is that the RS has to be persistent s= o that you can continually deliver media streams to the SRS. Agreed it can = break, and have to be re-established, but under normal operation it would b= e persistent for the duration of the CS being recorded (or longer in the ca= se of "persistent recording"). So when a metadata update includes a Media S= tream, the metadata is essentially tied to that RS until a further metadata= update occurs removing that Media Stream or until the RS ceases to exist, = whichever is sooner. John (as individual) > -----Original Message----- > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > Sent: 19 April 2011 16:50 > To: Paul Kyzivat (pkyzivat); Elwell, John > Cc: Parthasarathi R (partr); siprec@ietf.org > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > John, > > Even If we tear down the RS, we can still have the same MS > block in the > model ( and in format identified by its unique identifier). > Of course the properties of the MS will be different at different > instances. In the first instance it will have the label > attribute to RS1 > SDP. > In the second instance it can have label attribute pointing > to RS2 SDP. > This is just my thought and we should think through different > scenarios > to see if this can work > > Regards, > Ram > > > -----Original Message----- > > From: Paul Kyzivat (pkyzivat) > > Sent: Tuesday, April 19, 2011 8:53 PM > > To: Elwell, John > > Cc: Ram Mohan R (rmohanr); Parthasarathi R (partr); siprec@ietf.org > > Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 > > > > > > > > On 4/19/2011 10:33 AM, Elwell, John wrote: > > > I think I see where you are going. Each element in a series could > > potentially be delivered over a different RS. This seems to imply an > RS > > only needs to exist momentarily. However, the RS has SDP > that contains > > the media descriptions, and a given media description, > including it's > > a=3Dlabel attribute tying it to a Media Stream object, will need to > exist > > continually, between the deltas. Tearing down an RS will also tear > down > > the delivery of media for a Media Stream to the SRS. So I am not > > entirely sure what you have in mind. > > > > First, the idea is only half baked, so certainly feel free to take > > shots > > at it. > > > > And, in case of MS, perhaps you are right that you can't > reference the > > same MS from two different RS. > > > > Or maybe you could. In principle an SRC could lose the RS dialog, > > establish a new one, and then continue talking about the same CS and > > MS. > > (This could happen if the SRS server crashed and a backup took over > for > > it.) Its a different RTP stream on the RS, but its > delivering data for > > the same CS MS. > > > > Since in the case of a persistent RS we are prepared to > have a single > > m-line in the RS represent (serially, not concurrently) > different MSs, > > its clear there isn't a 1:1 relationship. So why not two > different RS > > m-lines representing (serially) the same MS? > > > > But the notion may be more important for other stuff that > changes over > > time. > > > > Thanks, > > Paul > > > > > John > > > > > > > > >> -----Original Message----- > > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > >> Sent: 19 April 2011 14:13 > > >> To: Elwell, John > > >> Cc: Ram Mohan R (rmohanr); Parthasarathi R (partr); > siprec@ietf.org > > >> Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 > > >> > > >> > > >> > > >> On 4/19/2011 8:32 AM, Elwell, John wrote: > > >>> Ram, > > >>> > > >>> I am not quite sure whether that is an issue or not. If we > > >> go for a single unique identifier, I suspect it would need to > > >> identify a CS, not an RS. In fact I was waiting to hear more > > >> from Paul on his assertion below, that perhaps none of the > > >> elements has a direct relationship with an RS. I am OK > > >> leaving the relationship in for now. It might become clearer > > >> when we resolve the question of identifiers. > > >> > > >> I haven't worked out the details. The concept would require the > > >> metamodel to be modified to explicitly represent the results > > >> of updates. > > >> Then, each individually updatable datum in the model > would be tied > > to > > >> the update that delivered it, and thus to an RS in which it was > > >> delivered and a timestamp for when it was delivered. Each > > >> such updatable > > >> datum would be represented as a time series of values. > > >> > > >> For instance, the relationship between media streams and > > participants > > >> could be represented either as: > > >> > > >> - each stream has a series for each participant in the stream. > > >> Each element in the series identifies a change in the role > > >> of the participant relative to that stream. > > >> > > >> - each participant has a series for each stream in which it > > >> participates. Each element in the series identifies a change > > >> in the role of the participant relative to the stream. > > >> > > >> In either case, each element in the series would refer to the RS > > over > > >> which it was delivered, and would have a timestamp > indicating when > > it > > >> occurred. > > >> > > >> For instance, elements in the series might indicate: > > >> - (alice:stream-1) sending@t1, inactive@t10, sending@t20, > > inactive@t30 > > >> - (bob:stream-1) recving@t2, inactive@t31 > > >> - (carol:stream-1) recving@t8, inactive@t12, recving@t20, > > inactive@t25 > > >> - (ted:stream-1) sending@t10, inactive@t20 > > >> > > >> Thanks, > > >> Paul > > >> > > >> > > >>> John (as individual) > > >>> > > >>>> -----Original Message----- > > >>>> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > >>>> Sent: 19 April 2011 11:31 > > >>>> To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); > > >>>> siprec@ietf.org; Elwell, John > > >>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > >>>> > > >>>> Partha, > > >>>> I agree with your concern here. > > >>>> > > >>>> John, > > >>>> Are you ok with retaining the below relation in the model, If > > >>>> yes we can > > >>>> close this open item of the model > > >>>> > > >>>> +-------------------------------+ 1 > > >>>> | Recording Session (RS) |---------------+ > > >>>> +-------------------------------+ | > > >>>> |1..* |1..* | > > >>>> | | | > > >>>> |0..* |0..* | > > >>>> +--------------+ +-----------------+ | > > >>>> |Communication | | Communication | 1 | > > >>>> | Session (CS) |----------| Session (CS) |---| > > >>>> | Group |0..1 1..*| | | 0..* > > >> +----------+ > > >>>> +--------------+ +-----------------+ > > >> |------|Extension | > > >>>> 1| | 0..* |1..* | > > >> | Data | > > >>>> | | 2..* |0..* | > > >> +----------+ > > >>>> 0..*| > > >>>> +---------+ > > >>>> |Extension| > > >>>> | Data | > > >>>> +---------+ > > >>>> > > >>>> Regards, > > >>>> Ram > > >>>> > > >>>>> -----Original Message----- > > >>>>> From: Parthasarathi R (partr) > > >>>>> Sent: Thursday, April 07, 2011 4:07 PM > > >>>>> To: Paul Kyzivat (pkyzivat); siprec@ietf.org; Ram Mohan R > > >> (rmohanr); > > >>>>> Elwell, John > > >>>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > >>>>> > > >>>>> John/Ram, > > >>>>> > > >>>>> I see the issue without direct link between RS and CSG. It may > be > > >>>> tough > > >>>>> to correlate CSG to RS in SRS implementation. This issue is > > >>>> raised by > > >>>>> Hadriel in terms of having single unique id for metadata > > >>>> format draft. > > >>>>> I explained his concern in "Partial updates and identifiers" > mail > > >>>>> thread. > > >>>>> > > >>>>> Also another issue: SRS may be interested in knowing list of > > >>>> associated > > >>>>> RS for a given CSG. > > >>>>> > > >>>>> Thanks > > >>>>> Partha > > >>>>> > > >>>>> -----Original Message----- > > >>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] > On > > >>>>> Behalf Of Paul Kyzivat (pkyzivat) > > >>>>> Sent: Thursday, April 07, 2011 12:53 AM > > >>>>> To: siprec@ietf.org > > >>>>> Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 > > >>>>> > > >>>>> John, > > >>>>> > > >>>>> I've been thinking about how everything relates to the > > >> RS, and that > > >>>>> maybe we should make some more major changes. > > >>>>> > > >>>>> What I'm thinking is that none of the elements have a direct > > >>>>> relationship to RS. Rather, each element is ultimately > > >>>> constructed as > > >>>> a > > >>>>> time series of values delivered in updates. Its the updates > > >>>> that have > > >>>> a > > >>>>> relationship to a RS - the one they are delivered in. That > > >>>> allows the > > >>>>> possibility that not all the updates come from the same RS. > > >>>>> > > >>>>> I haven't drawn a model diagram here because the concept is > still > > >>>>> fuzzy. > > >>>>> Its a trial balloon - to see what others think. > > >>>>> > > >>>>> Thanks, > > >>>>> Paul > > >>>>> > > >>>>> On 4/6/2011 11:47 AM, Elwell, John wrote: > > >>>>>> Ram, > > >>>>>> > > >>>>>> I am not sure this answers my question. In the model you > > >>>> drew below, > > >>>>> a CSG has both a direct relationship with an RS and > an indirect > > >>>>> relationship (via a CS). I was questioning whether we could > > >>>> remove the > > >>>>> direct relationship, on the basis that the indirect > > >> relationship is > > >>>>> sufficient. > > >>>>>> > > >>>>>> John (as individual) > > >>>>>> > > >>>>>> > > >>>>>>> -----Original Message----- > > >>>>>>> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > >>>>>>> Sent: 06 April 2011 15:52 > > >>>>>>> To: Elwell, John; Scott Orton; Charles Eckel (eckelcu); > > >>>>> Parthasarathi > > >>>>>>> R (partr); siprec@ietf.org > > >>>>>>> Subject: RE: [siprec] comments on > draft-ram-siprec-metadata-04 > > >>>>>>> > > >>>>>>> Hi John, > > >>>>>>> > > >>>>>>> Yes We have an indirect relationship in the current > > >>>> model. However > > >>>>> in > > >>>>>>> the current model it is REQUIRED to have a CSG as CS is > > >> connected > > >>>> to > > >>>>>>> RS through CSG. However not all use cases would need > > >> CSG, IOW CSG > > >>>>> has > > >>>>>>> to be optional and there should be direct association > > >>>> from CS to RS > > >>>>>>> even when CSG is absent. > > >>>>>>> > > >>>>>>> With the below associations we will have: > > >>>>>>> - An instance of RS can have Zero or more CSG blocks. > > >>>>>>> - An instance of RS can have Zero or more CS blocks. > > >>>>>>> - If a CSG is present it will have 1 or more CS. > > >>>>>>> - Each CS can be associated with Zero or 1 CSG. > > >>>>>>> > > >>>>>>> Let me know if you have any concerns. > > >>>>>>> > > >>>>>>> Regards, > > >>>>>>> Ram > > >>>>>>> > > >>>>>>>> -----Original Message----- > > >>>>>>>> From: Elwell, John > [mailto:john.elwell@siemens-enterprise.com] > > >>>>>>>> Sent: Wednesday, April 06, 2011 6:16 PM > > >>>>>>>> To: Ram Mohan R (rmohanr); Scott Orton; Charles Eckel > > >> (eckelcu); > > >>>>>>>> Parthasarathi R (partr); siprec@ietf.org > > >>>>>>>> Subject: RE: [siprec] comments on > draft-ram-siprec-metadata-04 > > >>>>>>>> > > >>>>>>>> I am OK in principle, but I wonder whether there really > > >>>>>>> needs to be a > > >>>>>>>> relationship between CSG and RS. Isn't that relationship an > > >>>>> indirect > > >>>>>>>> relationship via CS? > > >>>>>>>> > > >>>>>>>> John (as individual) > > >>>>>>>> > > >>>>>>>> > > >>>>>>>>> -----Original Message----- > > >>>>>>>>> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > >>>>>>>>> Sent: 03 April 2011 18:13 > > >>>>>>>>> To: Scott Orton; Elwell, John; Charles Eckel (eckelcu); > > >>>>>>>>> Parthasarathi R (partr); siprec@ietf.org > > >>>>>>>>> Subject: RE: [siprec] comments on > draft-ram-siprec-metadata- > > 04 > > >>>>>>>>> > > >>>>>>>>> Scott, > > >>>>>>>>> > > >>>>>>>>> I am ok to make this change to the model. I would like to > > >>>>>>> hear from > > >>>>>>>>> others if they have any issues in incorporating > this change > > in > > >>>> the > > >>>>>>>>> model. > > >>>>>>>>> > > >>>>>>>>> The updated portion of the model will look like > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> +-------------------------------+ 1 > > >>>>>>>>> | Recording Session (RS) |---------------+ > > >>>>>>>>> +-------------------------------+ | > > >>>>>>>>> | 1..* |1..* | > > >>>>>>>>> | | | > > >>>>>>>>> | 0..* |0..* | > > >>>>>>>>> +--------------+ +-----------------+ | > > >>>>>>>>> |Communication | | Communication | 1 | > > >>>>>>>>> | Session (CS) |----------| Session (CS) |---| > > >>>>>>>>> | Group |0..1 1..*| > | | 0..* > > >>>>>>> +----------+ > > >>>>>>>>> +--------------+ +-----------------+ > > >>>>>>> |------|Extension > > >>>>>>> | > > >>>>>>>>> 1| | 0..* |1..* | > > >>>> | Data > > >>>>>>> | > > >>>>>>>>> | | 2..* |0..* | > > >>>>>>> +----------+ > > >>>>>>>>> 0..*| > > >>>>>>>>> +---------+ > > >>>>>>>>> |Extension| > > >>>>>>>>> | Data | > > >>>>>>>>> +---------+ > > >>>>>>>>> > > >>>>>>>>> The only change in the association is : > > >>>>>>>>> A CS MUST be associated with zero or one CS-Group > > >>>>>>>>> > > >>>>>>>>> Rest of the associations remain same. Further the > association > > >>>>>>>>> between CS and RS remains same as what is between CS-Group > > and > > >>>> RS. > > >>>>>>>>> > > >>>>>>>>> Comments ? > > >>>>>>>>> > > >>>>>>>>> Regards, > > >>>>>>>>> Ram > > >>>>>>>>> > > >>>>>>>>>> -----Original Message----- > > >>>>>>>>>> From: siprec-bounces@ietf.org > > >>>>>>> [mailto:siprec-bounces@ietf.org] On > > >>>>>>>>>> Behalf Of Scott Orton > > >>>>>>>>>> Sent: Friday, April 01, 2011 12:18 AM > > >>>>>>>>>> To: Elwell, John; Charles Eckel (eckelcu); > Parthasarathi R > > >>>>>>> (partr); > > >>>>>>>>>> siprec@ietf.org > > >>>>>>>>>> Subject: Re: [siprec] comments on > > >> draft-ram-siprec-metadata-04 > > >>>>>>>>>> > > >>>>>>>>>> John, > > >>>>>>>>>> Thanks for the information. > > >>>>>>>>>> > > >>>>>>>>>> In that case I would like to see the CS group be > > >>>>>>> made optional. > > >>>>>>>>>> Rather than the CS pointing to the CS Group, I would like > to > > >>>>>>>> suggest > > >>>>>>>>>> that the CS point to the RS and have the CS group stand > > >>>>>>>>> alone where it > > >>>>>>>>>> would just have its own ID and then a list of CS ids > > >>>> that belong > > >>>>>>> to > > >>>>>>>>> the > > >>>>>>>>>> group. > > >>>>>>>>>> > > >>>>>>>>>> Scott > > >>>>>>>>>> > > >>>>>>>>>> -----Original Message----- > > >>>>>>>>>> From: Elwell, John > > >> [mailto:john.elwell@siemens-enterprise.com] > > >>>>>>>>>> Sent: Thursday, March 31, 2011 11:50 AM > > >>>>>>>>>> To: Scott Orton; Charles Eckel (eckelcu); Parthasarathi > > >>>>>>> R (partr); > > >>>>>>>>>> siprec@ietf.org > > >>>>>>>>>> Subject: RE: [siprec] comments on > > >> draft-ram-siprec-metadata-04 > > >>>>>>>>>> > > >>>>>>>>>> Scott, > > >>>>>>>>>> > > >>>>>>>>>> Some folks wanted to be able to group related > CSs together > > >>>>>>>>> (e.g., a CS > > >>>>>>>>>> between a customer and an agent and a second CS > > >>>>>>> resulting from the > > >>>>>>>>>> customer being transferred to a second agent). I will > > >>>>>>> leave it to > > >>>>>>>>> those > > >>>>>>>>>> folks to add to this. > > >>>>>>>>>> > > >>>>>>>>>> John (chair hat on) > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>>> -----Original Message----- > > >>>>>>>>>>> From: Scott Orton [mailto:sorton@broadsoft.com] > > >>>>>>>>>>> Sent: 31 March 2011 17:43 > > >>>>>>>>>>> To: Elwell, John; Charles Eckel (eckelcu); > Parthasarathi R > > >>>>>>>>>>> (partr); siprec@ietf.org > > >>>>>>>>>>> Subject: RE: [siprec] comments on > > >>>> draft-ram-siprec-metadata-04 > > >>>>>>>>>>> > > >>>>>>>>>>> John, Charles, Partha, > > >>>>>>>>>>> I have a question. What is the purpose of the > > >> CS Group? I > > >>>> do > > >>>>>>>>>>> not see it adding anything to the metadata. To me it > > >>>> seems that > > >>>>>>>>>>> the whole purpose of the metadata is to describe the > > >>>> recording > > >>>>>>>>>>> session to the SRS. Looking at the requirements I see 3 > > >>>>>>>>>>> relationships that the spec is attempting to describe: > > >>>>>>>>>>> > > >>>>>>>>>>> A one to one relationship - one communication session to > > one > > >>>>>>>>>>> recording session A one to many relationship - one > > >>>> communication > > >>>>>>>>>>> session with multiple Recording sessions > > >>>>>>>>>>> - one Recording session > > >>>> made up of > > >>>>>>>>>>> multiple communications sessions > > >>>>>>>>>>> > > >>>>>>>>>>> The current metadata format allows all of these and I do > > not > > >>>> see > > >>>>>>>>>>> what the group is adding. > > >>>>>>>>>>> > > >>>>>>>>>>> Regards, > > >>>>>>>>>>> Scott > > >>>>>>>>>>> > > >>>>>>> > > >>>>>> _______________________________________________ > > >>>>>> siprec mailing 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@cisco.com Wed Apr 20 05:41:42 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 70967E066F for ; Wed, 20 Apr 2011 05:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.431 X-Spam-Level: X-Spam-Status: No, score=-110.431 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JIwlpeR4T3Rn for ; Wed, 20 Apr 2011 05:41:41 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfc.amsl.com (Postfix) with ESMTP id 91200E0655 for ; Wed, 20 Apr 2011 05:41:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=2874; q=dns/txt; s=iport; t=1303303301; x=1304512901; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=gtsG/ftWKGAI07ZVOBNj2Hr7k6HV1NX9ioqiZi/TIx4=; b=YmL1wXt3HSy5dSAbT1jojBRR2JtZSNUa8qJ6Cg/dqWKEdnk+OCAhpCKt WE1+AVzvcSXP+XwFCGvb2OcdUpjKbbSLxXcXN8yi5g/VNJwvPph+FECUl ltoP49O5t3SZXbd1ROuGHbeA9atp8FxPgj/jBsz+ab0fHYDF1ph9netQw E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtYHAH7Trk2rRDoI/2dsb2JhbACXcY1Ld6o4nQWFcQSOIoN/ X-IronPort-AV: E=Sophos;i="4.64,246,1301875200"; d="scan'208";a="433494647" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-1.cisco.com with ESMTP; 20 Apr 2011 12:41:40 +0000 Received: from [161.44.174.125] (dhcp-161-44-174-125.cisco.com [161.44.174.125]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3KCfeCB025713 for ; Wed, 20 Apr 2011 12:41:40 GMT Message-ID: <4DAED483.6080703@cisco.com> Date: Wed, 20 Apr 2011 08:41:39 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 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] last call comment on draft-ietf-siprec-req-09 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 20 Apr 2011 12:41:42 -0000 IMO the RS is synonymous with the dialog between the SRC and the SRS, and so fundamentally there is only one SRC and one SRS per RS. If there happen to be two SRCs in the same CS, and they establish RS1 and RS2 to the *same* SRS, then it would be nice if the SRS could recognize that they are talking about the same CS. We early on ruled it out of scope, but I would like to provide at least some basics to facilitate that in the mechanism if it isn't too much trouble. My thought here is that we at least draw the IDs from the same space, so its *possible* for the two SRCs to provide the same ID for the CS. That doesn't make it *easy* because the two SRCs would have to collaborate and share the ID before that could happen. But at least it would be *possible*. If we use a separate ID namespace for each RS that it would fundamentally be impossible. Thanks, Paul On 4/19/2011 7:33 PM, Charles Eckel (eckelcu) wrote: > I raised this comment previously, but it was not clear to me that we > reached a conclusion. As it reads today, it is not clear to me if > multiple SRCs per RS is supported. As I understand it, there may be > multiple RSs per SRS, but only one SRS per RS. The question I have is: > > Q1. Is there a similar restriction of one SRC per RS? > > We could: > A1. State the limitation of one SRC per RS. > A2. Add a requirement that multiple SRCs per RS be supported. > A3. Do nothing and leave it to interpretation. > > I am not happy with A3, and I previously was assuming A2. I could be > convinced to go with A1. > I see supporting multiple SRCs as being useful in distributed recording > scenarios in which there is not a single B2BUA or conference server or > UA that is entirely responsible of the recording. For example, a peer to > peer SIP network in which case the peers each decide whether or not > their input should be recorded? Or a meeting with multiple presenters in > which each presenter sends their own contributions to be recorded? Are > such cases intentionally left out of scope? > > I can see use cases in which multiple parties might want to have their > own recording of the same call/meeting, perhaps to record it from their > perspective or to have their permissions and preferences associated with > the recording. This lends itself nicely to the single SRC per RS model. > But other scenarios exist, for scalability, or geographic distribution, > or other reasons, in which allowing multiple SRCs to contribute to a > single RS would be useful. > > Support for multiple SRCs definitely increases the complexity. Perhaps > it is worth it, perhaps not. I would like to hear what others think. > > Thanks, > Charles > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From mperumal@cisco.com Wed Apr 20 06:24:39 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 49D5BE068A for ; Wed, 20 Apr 2011 06:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.151 X-Spam-Level: X-Spam-Status: No, score=-10.151 tagged_above=-999 required=5 tests=[AWL=0.448, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ohlqxCdWl1kK for ; Wed, 20 Apr 2011 06:24:38 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfc.amsl.com (Postfix) with ESMTP id 3C02FE0674 for ; Wed, 20 Apr 2011 06:24:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=3349; q=dns/txt; s=iport; t=1303305878; x=1304515478; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=YWOb0HK/g7xpBGIIWzVF7bUGZP7GMOnMhoT/ZN1ard4=; b=OfCXby7FkFb6LrMz9ucMh6mu6ySHTDjw7R0ljYmuct/OpbZoDijsRVBw O42TCXe7ukBBl+E5yUVnjqkl6xGxoDNm1NyHDXYFD+90wocqeN5rUEw3k ZHA7czJnom8TlDjNHzICExJNlx5eAnW7W+d9+itKNr7povBjkc6EkPKi0 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtcAAJvdrk2Q/khNgWdsb2JhbACXM44KFAEBFiYlqkadBYVxBIVyjDY X-IronPort-AV: E=Sophos;i="4.64,246,1301875200"; d="scan'208";a="84399635" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 20 Apr 2011 13:24:37 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3KDO0ps020922 for ; Wed, 20 Apr 2011 13:24:37 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Apr 2011 18:54:25 +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: Wed, 20 Apr 2011 18:54:23 +0530 Message-ID: <1D062974A4845E4D8A343C65380492020542548E@XMB-BGL-414.cisco.com> In-Reply-To: <4DAED483.6080703@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] last call comment on draft-ietf-siprec-req-09 Thread-Index: Acv/WFt8v00SYRtiRTOyX9qD7NN9wwABX1tg References: <4DAED483.6080703@cisco.com> From: "Muthu ArulMozhi Perumal (mperumal)" To: "Paul Kyzivat (pkyzivat)" , X-OriginalArrivalTime: 20 Apr 2011 13:24:25.0603 (UTC) FILETIME=[44C60D30:01CBFF5E] Subject: Re: [siprec] last call comment on draft-ietf-siprec-req-09 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 20 Apr 2011 13:24:39 -0000 +1 |-----Original Message----- |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat (pkyzivat) |Sent: Wednesday, April 20, 2011 6:12 PM |To: siprec@ietf.org |Subject: Re: [siprec] last call comment on draft-ietf-siprec-req-09 | |IMO the RS is synonymous with the dialog between the SRC and the SRS, |and so fundamentally there is only one SRC and one SRS per RS. | |If there happen to be two SRCs in the same CS, and they establish RS1 |and RS2 to the *same* SRS, then it would be nice if the SRS could |recognize that they are talking about the same CS. We early on ruled it |out of scope, but I would like to provide at least some basics to |facilitate that in the mechanism if it isn't too much trouble. | |My thought here is that we at least draw the IDs from the same space, so |its *possible* for the two SRCs to provide the same ID for the CS. That |doesn't make it *easy* because the two SRCs would have to collaborate |and share the ID before that could happen. But at least it would be |*possible*. If we use a separate ID namespace for each RS that it would |fundamentally be impossible. | | Thanks, | Paul | |On 4/19/2011 7:33 PM, Charles Eckel (eckelcu) wrote: |> I raised this comment previously, but it was not clear to me that we |> reached a conclusion. As it reads today, it is not clear to me if |> multiple SRCs per RS is supported. As I understand it, there may be |> multiple RSs per SRS, but only one SRS per RS. The question I have is: |> |> Q1. Is there a similar restriction of one SRC per RS? |> |> We could: |> A1. State the limitation of one SRC per RS. |> A2. Add a requirement that multiple SRCs per RS be supported. |> A3. Do nothing and leave it to interpretation. |> |> I am not happy with A3, and I previously was assuming A2. I could be |> convinced to go with A1. |> I see supporting multiple SRCs as being useful in distributed recording |> scenarios in which there is not a single B2BUA or conference server or |> UA that is entirely responsible of the recording. For example, a peer to |> peer SIP network in which case the peers each decide whether or not |> their input should be recorded? Or a meeting with multiple presenters in |> which each presenter sends their own contributions to be recorded? Are |> such cases intentionally left out of scope? |> |> I can see use cases in which multiple parties might want to have their |> own recording of the same call/meeting, perhaps to record it from their |> perspective or to have their permissions and preferences associated with |> the recording. This lends itself nicely to the single SRC per RS model. |> But other scenarios exist, for scalability, or geographic distribution, |> or other reasons, in which allowing multiple SRCs to contribute to a |> single RS would be useful. |> |> Support for multiple SRCs definitely increases the complexity. Perhaps |> it is worth it, perhaps not. I would like to hear what others think. |> |> Thanks, |> Charles |> _______________________________________________ |> siprec mailing list |> siprec@ietf.org |> https://www.ietf.org/mailman/listinfo/siprec |> |_______________________________________________ |siprec mailing list |siprec@ietf.org |https://www.ietf.org/mailman/listinfo/siprec From rmohanr@cisco.com Wed Apr 20 06:52:25 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2E829E06B0 for ; Wed, 20 Apr 2011 06:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.026 X-Spam-Level: X-Spam-Status: No, score=-10.026 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZ8fYY2OBzur for ; Wed, 20 Apr 2011 06:52:23 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfc.amsl.com (Postfix) with ESMTP id 60B3EE06AF for ; Wed, 20 Apr 2011 06:52:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=20409; q=dns/txt; s=iport; t=1303307542; x=1304517142; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=nLQ7HByE4n1MX+ZZIATgvCB/iDflMyAPzcgAqzpEaEw=; b=Z47uvr80SKBDddP0Lj54f/fmkh8mJcFW0uIN96bbCG0Ap/5YufpyRSDc 4niTkM6osWsv2jIaQ2YQa4WjG+uI091kZ/aO04YOVYZ283H3hwSpW2OPj 4sjpKleN2sfhQrJk8bWjoh+E0fFpqTh414wWv/6X61WxdvGfrLHVqcv7I g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtcAAKDkrk2Q/khNgWdsb2JhbACXMo4KFAEBFiYlqledCIJ/gnIEhXKMNg X-IronPort-AV: E=Sophos;i="4.64,246,1301875200"; d="scan'208";a="84405341" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 20 Apr 2011 13:52:21 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3KDqCpp030079; Wed, 20 Apr 2011 13:52:21 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); Wed, 20 Apr 2011 19:22:20 +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: Wed, 20 Apr 2011 19:22:17 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD06133DD4@XMB-BGL-417.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] comments on draft-ram-siprec-metadata-04 Thread-Index: Acv+pbws7MwochNUSB2j8RZ3ismj6AAAQrXwACiVZgAABfyA0A== References: <21866C7FE177A4449B9136B5B24B1B130BC011290A@EXMBXCLUS01.citservers.local><21866C7FE177A4449B9136B5B24B1B130BC011294A@EXMBXCLUS01.citservers.local><35BCE99A477D6A4986FB2216D8CF2CFD05DD8C0C@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD05EF92EF@XMB-BGL-417.cisco.com> <4D9CBD8C.4010901@cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD06133966@XMB-BGL-417.cisco.com> <4DAD8A5F.4040506@cisco.com> <4DADA8E6.9010006@cisco.com> <35BCE99A477D 6A4986FB 2216D8CF2CFD 06133A56@XMB-BGL-417.cisco.com> From: "Ram Mohan R (rmohanr)" To: "Elwell, John" , "Paul Kyzivat (pkyzivat)" X-OriginalArrivalTime: 20 Apr 2011 13:52:20.0215 (UTC) FILETIME=[2AEB9070:01CBFF62] Cc: siprec@ietf.org Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 20 Apr 2011 13:52:25 -0000 John, I agree with you that normal cases RS will remain at least for the duration of CS. However it is common to have use cases where recording is done for first few mins of a CS and then stopped, re-started at a later point (e.g Recording of a company meeting where you may want to record only portions of meeting).=20 In any case, the point I like to high light here is, MS block could be common across RS and even across CS[ due to consult transfer e.t.c]. These use cases indicate the need to have a unique ID for MS block (similar to the UUID that we have defined in format) as we cannot depend on neither CS ID or RS ID. Let me know your comments on this. Regards, Ram > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Wednesday, April 20, 2011 4:29 PM > To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > Cc: Parthasarathi R (partr); siprec@ietf.org > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 >=20 > I guess the point I am trying to make is that the RS has to be > persistent so that you can continually deliver media streams to the > SRS. Agreed it can break, and have to be re-established, but under > normal operation it would be persistent for the duration of the CS > being recorded (or longer in the case of "persistent recording"). So > when a metadata update includes a Media Stream, the metadata is > essentially tied to that RS until a further metadata update occurs > removing that Media Stream or until the RS ceases to exist, whichever > is sooner. >=20 > John (as individual) >=20 > > -----Original Message----- > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > Sent: 19 April 2011 16:50 > > To: Paul Kyzivat (pkyzivat); Elwell, John > > Cc: Parthasarathi R (partr); siprec@ietf.org > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > > > John, > > > > Even If we tear down the RS, we can still have the same MS > > block in the > > model ( and in format identified by its unique identifier). > > Of course the properties of the MS will be different at different > > instances. In the first instance it will have the label > > attribute to RS1 > > SDP. > > In the second instance it can have label attribute pointing > > to RS2 SDP. > > This is just my thought and we should think through different > > scenarios > > to see if this can work > > > > Regards, > > Ram > > > > > -----Original Message----- > > > From: Paul Kyzivat (pkyzivat) > > > Sent: Tuesday, April 19, 2011 8:53 PM > > > To: Elwell, John > > > Cc: Ram Mohan R (rmohanr); Parthasarathi R (partr); siprec@ietf.org > > > Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 > > > > > > > > > > > > On 4/19/2011 10:33 AM, Elwell, John wrote: > > > > I think I see where you are going. Each element in a series could > > > potentially be delivered over a different RS. This seems to imply > an > > RS > > > only needs to exist momentarily. However, the RS has SDP > > that contains > > > the media descriptions, and a given media description, > > including it's > > > a=3Dlabel attribute tying it to a Media Stream object, will need = to > > exist > > > continually, between the deltas. Tearing down an RS will also tear > > down > > > the delivery of media for a Media Stream to the SRS. So I am not > > > entirely sure what you have in mind. > > > > > > First, the idea is only half baked, so certainly feel free to take > > > shots > > > at it. > > > > > > And, in case of MS, perhaps you are right that you can't > > reference the > > > same MS from two different RS. > > > > > > Or maybe you could. In principle an SRC could lose the RS dialog, > > > establish a new one, and then continue talking about the same CS > and > > > MS. > > > (This could happen if the SRS server crashed and a backup took over > > for > > > it.) Its a different RTP stream on the RS, but its > > delivering data for > > > the same CS MS. > > > > > > Since in the case of a persistent RS we are prepared to > > have a single > > > m-line in the RS represent (serially, not concurrently) > > different MSs, > > > its clear there isn't a 1:1 relationship. So why not two > > different RS > > > m-lines representing (serially) the same MS? > > > > > > But the notion may be more important for other stuff that > > changes over > > > time. > > > > > > Thanks, > > > Paul > > > > > > > John > > > > > > > > > > > >> -----Original Message----- > > > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > >> Sent: 19 April 2011 14:13 > > > >> To: Elwell, John > > > >> Cc: Ram Mohan R (rmohanr); Parthasarathi R (partr); > > siprec@ietf.org > > > >> Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 > > > >> > > > >> > > > >> > > > >> On 4/19/2011 8:32 AM, Elwell, John wrote: > > > >>> Ram, > > > >>> > > > >>> I am not quite sure whether that is an issue or not. If we > > > >> go for a single unique identifier, I suspect it would need to > > > >> identify a CS, not an RS. In fact I was waiting to hear more > > > >> from Paul on his assertion below, that perhaps none of the > > > >> elements has a direct relationship with an RS. I am OK > > > >> leaving the relationship in for now. It might become clearer > > > >> when we resolve the question of identifiers. > > > >> > > > >> I haven't worked out the details. The concept would require the > > > >> metamodel to be modified to explicitly represent the results > > > >> of updates. > > > >> Then, each individually updatable datum in the model > > would be tied > > > to > > > >> the update that delivered it, and thus to an RS in which it was > > > >> delivered and a timestamp for when it was delivered. Each > > > >> such updatable > > > >> datum would be represented as a time series of values. > > > >> > > > >> For instance, the relationship between media streams and > > > participants > > > >> could be represented either as: > > > >> > > > >> - each stream has a series for each participant in the stream. > > > >> Each element in the series identifies a change in the role > > > >> of the participant relative to that stream. > > > >> > > > >> - each participant has a series for each stream in which it > > > >> participates. Each element in the series identifies a change > > > >> in the role of the participant relative to the stream. > > > >> > > > >> In either case, each element in the series would refer to the RS > > > over > > > >> which it was delivered, and would have a timestamp > > indicating when > > > it > > > >> occurred. > > > >> > > > >> For instance, elements in the series might indicate: > > > >> - (alice:stream-1) sending@t1, inactive@t10, sending@t20, > > > inactive@t30 > > > >> - (bob:stream-1) recving@t2, inactive@t31 > > > >> - (carol:stream-1) recving@t8, inactive@t12, recving@t20, > > > inactive@t25 > > > >> - (ted:stream-1) sending@t10, inactive@t20 > > > >> > > > >> Thanks, > > > >> Paul > > > >> > > > >> > > > >>> John (as individual) > > > >>> > > > >>>> -----Original Message----- > > > >>>> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > > >>>> Sent: 19 April 2011 11:31 > > > >>>> To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); > > > >>>> siprec@ietf.org; Elwell, John > > > >>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > > >>>> > > > >>>> Partha, > > > >>>> I agree with your concern here. > > > >>>> > > > >>>> John, > > > >>>> Are you ok with retaining the below relation in the model, If > > > >>>> yes we can > > > >>>> close this open item of the model > > > >>>> > > > >>>> +-------------------------------+ 1 > > > >>>> | Recording Session (RS) |---------------+ > > > >>>> +-------------------------------+ | > > > >>>> |1..* |1..* | > > > >>>> | | | > > > >>>> |0..* |0..* | > > > >>>> +--------------+ +-----------------+ | > > > >>>> |Communication | | Communication | 1 | > > > >>>> | Session (CS) |----------| Session (CS) |---| > > > >>>> | Group |0..1 1..*| | | 0..* > > > >> +----------+ > > > >>>> +--------------+ +-----------------+ > > > >> |------|Extension | > > > >>>> 1| | 0..* |1..* | > > > >> | Data | > > > >>>> | | 2..* |0..* | > > > >> +----------+ > > > >>>> 0..*| > > > >>>> +---------+ > > > >>>> |Extension| > > > >>>> | Data | > > > >>>> +---------+ > > > >>>> > > > >>>> Regards, > > > >>>> Ram > > > >>>> > > > >>>>> -----Original Message----- > > > >>>>> From: Parthasarathi R (partr) > > > >>>>> Sent: Thursday, April 07, 2011 4:07 PM > > > >>>>> To: Paul Kyzivat (pkyzivat); siprec@ietf.org; Ram Mohan R > > > >> (rmohanr); > > > >>>>> Elwell, John > > > >>>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata- > 04 > > > >>>>> > > > >>>>> John/Ram, > > > >>>>> > > > >>>>> I see the issue without direct link between RS and CSG. It > may > > be > > > >>>> tough > > > >>>>> to correlate CSG to RS in SRS implementation. This issue is > > > >>>> raised by > > > >>>>> Hadriel in terms of having single unique id for metadata > > > >>>> format draft. > > > >>>>> I explained his concern in "Partial updates and identifiers" > > mail > > > >>>>> thread. > > > >>>>> > > > >>>>> Also another issue: SRS may be interested in knowing list of > > > >>>> associated > > > >>>>> RS for a given CSG. > > > >>>>> > > > >>>>> Thanks > > > >>>>> Partha > > > >>>>> > > > >>>>> -----Original Message----- > > > >>>>> From: siprec-bounces@ietf.org [mailto:siprec- > bounces@ietf.org] > > On > > > >>>>> Behalf Of Paul Kyzivat (pkyzivat) > > > >>>>> Sent: Thursday, April 07, 2011 12:53 AM > > > >>>>> To: siprec@ietf.org > > > >>>>> Subject: Re: [siprec] comments on draft-ram-siprec-metadata- > 04 > > > >>>>> > > > >>>>> John, > > > >>>>> > > > >>>>> I've been thinking about how everything relates to the > > > >> RS, and that > > > >>>>> maybe we should make some more major changes. > > > >>>>> > > > >>>>> What I'm thinking is that none of the elements have a direct > > > >>>>> relationship to RS. Rather, each element is ultimately > > > >>>> constructed as > > > >>>> a > > > >>>>> time series of values delivered in updates. Its the updates > > > >>>> that have > > > >>>> a > > > >>>>> relationship to a RS - the one they are delivered in. That > > > >>>> allows the > > > >>>>> possibility that not all the updates come from the same RS. > > > >>>>> > > > >>>>> I haven't drawn a model diagram here because the concept is > > still > > > >>>>> fuzzy. > > > >>>>> Its a trial balloon - to see what others think. > > > >>>>> > > > >>>>> Thanks, > > > >>>>> Paul > > > >>>>> > > > >>>>> On 4/6/2011 11:47 AM, Elwell, John wrote: > > > >>>>>> Ram, > > > >>>>>> > > > >>>>>> I am not sure this answers my question. In the model you > > > >>>> drew below, > > > >>>>> a CSG has both a direct relationship with an RS and > > an indirect > > > >>>>> relationship (via a CS). I was questioning whether we could > > > >>>> remove the > > > >>>>> direct relationship, on the basis that the indirect > > > >> relationship is > > > >>>>> sufficient. > > > >>>>>> > > > >>>>>> John (as individual) > > > >>>>>> > > > >>>>>> > > > >>>>>>> -----Original Message----- > > > >>>>>>> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > > >>>>>>> Sent: 06 April 2011 15:52 > > > >>>>>>> To: Elwell, John; Scott Orton; Charles Eckel (eckelcu); > > > >>>>> Parthasarathi > > > >>>>>>> R (partr); siprec@ietf.org > > > >>>>>>> Subject: RE: [siprec] comments on > > draft-ram-siprec-metadata-04 > > > >>>>>>> > > > >>>>>>> Hi John, > > > >>>>>>> > > > >>>>>>> Yes We have an indirect relationship in the current > > > >>>> model. However > > > >>>>> in > > > >>>>>>> the current model it is REQUIRED to have a CSG as CS is > > > >> connected > > > >>>> to > > > >>>>>>> RS through CSG. However not all use cases would need > > > >> CSG, IOW CSG > > > >>>>> has > > > >>>>>>> to be optional and there should be direct association > > > >>>> from CS to RS > > > >>>>>>> even when CSG is absent. > > > >>>>>>> > > > >>>>>>> With the below associations we will have: > > > >>>>>>> - An instance of RS can have Zero or more CSG blocks. > > > >>>>>>> - An instance of RS can have Zero or more CS blocks. > > > >>>>>>> - If a CSG is present it will have 1 or more CS. > > > >>>>>>> - Each CS can be associated with Zero or 1 CSG. > > > >>>>>>> > > > >>>>>>> Let me know if you have any concerns. > > > >>>>>>> > > > >>>>>>> Regards, > > > >>>>>>> Ram > > > >>>>>>> > > > >>>>>>>> -----Original Message----- > > > >>>>>>>> From: Elwell, John > > [mailto:john.elwell@siemens-enterprise.com] > > > >>>>>>>> Sent: Wednesday, April 06, 2011 6:16 PM > > > >>>>>>>> To: Ram Mohan R (rmohanr); Scott Orton; Charles Eckel > > > >> (eckelcu); > > > >>>>>>>> Parthasarathi R (partr); siprec@ietf.org > > > >>>>>>>> Subject: RE: [siprec] comments on > > draft-ram-siprec-metadata-04 > > > >>>>>>>> > > > >>>>>>>> I am OK in principle, but I wonder whether there really > > > >>>>>>> needs to be a > > > >>>>>>>> relationship between CSG and RS. Isn't that relationship > an > > > >>>>> indirect > > > >>>>>>>> relationship via CS? > > > >>>>>>>> > > > >>>>>>>> John (as individual) > > > >>>>>>>> > > > >>>>>>>> > > > >>>>>>>>> -----Original Message----- > > > >>>>>>>>> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > > >>>>>>>>> Sent: 03 April 2011 18:13 > > > >>>>>>>>> To: Scott Orton; Elwell, John; Charles Eckel (eckelcu); > > > >>>>>>>>> Parthasarathi R (partr); siprec@ietf.org > > > >>>>>>>>> Subject: RE: [siprec] comments on > > draft-ram-siprec-metadata- > > > 04 > > > >>>>>>>>> > > > >>>>>>>>> Scott, > > > >>>>>>>>> > > > >>>>>>>>> I am ok to make this change to the model. I would like to > > > >>>>>>> hear from > > > >>>>>>>>> others if they have any issues in incorporating > > this change > > > in > > > >>>> the > > > >>>>>>>>> model. > > > >>>>>>>>> > > > >>>>>>>>> The updated portion of the model will look like > > > >>>>>>>>> > > > >>>>>>>>> > > > >>>>>>>>> +-------------------------------+ 1 > > > >>>>>>>>> | Recording Session (RS) |---------------+ > > > >>>>>>>>> +-------------------------------+ | > > > >>>>>>>>> | 1..* |1..* | > > > >>>>>>>>> | | | > > > >>>>>>>>> | 0..* |0..* | > > > >>>>>>>>> +--------------+ +-----------------+ | > > > >>>>>>>>> |Communication | | Communication | 1 | > > > >>>>>>>>> | Session (CS) |----------| Session (CS) |---| > > > >>>>>>>>> | Group |0..1 1..*| > > | | 0..* > > > >>>>>>> +----------+ > > > >>>>>>>>> +--------------+ +-----------------+ > > > >>>>>>> |------|Extension > > > >>>>>>> | > > > >>>>>>>>> 1| | 0..* |1..* | > > > >>>> | Data > > > >>>>>>> | > > > >>>>>>>>> | | 2..* |0..* | > > > >>>>>>> +----------+ > > > >>>>>>>>> 0..*| > > > >>>>>>>>> +---------+ > > > >>>>>>>>> |Extension| > > > >>>>>>>>> | Data | > > > >>>>>>>>> +---------+ > > > >>>>>>>>> > > > >>>>>>>>> The only change in the association is : > > > >>>>>>>>> A CS MUST be associated with zero or one CS-Group > > > >>>>>>>>> > > > >>>>>>>>> Rest of the associations remain same. Further the > > association > > > >>>>>>>>> between CS and RS remains same as what is between CS- > Group > > > and > > > >>>> RS. > > > >>>>>>>>> > > > >>>>>>>>> Comments ? > > > >>>>>>>>> > > > >>>>>>>>> Regards, > > > >>>>>>>>> Ram > > > >>>>>>>>> > > > >>>>>>>>>> -----Original Message----- > > > >>>>>>>>>> From: siprec-bounces@ietf.org > > > >>>>>>> [mailto:siprec-bounces@ietf.org] On > > > >>>>>>>>>> Behalf Of Scott Orton > > > >>>>>>>>>> Sent: Friday, April 01, 2011 12:18 AM > > > >>>>>>>>>> To: Elwell, John; Charles Eckel (eckelcu); > > Parthasarathi R > > > >>>>>>> (partr); > > > >>>>>>>>>> siprec@ietf.org > > > >>>>>>>>>> Subject: Re: [siprec] comments on > > > >> draft-ram-siprec-metadata-04 > > > >>>>>>>>>> > > > >>>>>>>>>> John, > > > >>>>>>>>>> Thanks for the information. > > > >>>>>>>>>> > > > >>>>>>>>>> In that case I would like to see the CS group be > > > >>>>>>> made optional. > > > >>>>>>>>>> Rather than the CS pointing to the CS Group, I would > like > > to > > > >>>>>>>> suggest > > > >>>>>>>>>> that the CS point to the RS and have the CS group stand > > > >>>>>>>>> alone where it > > > >>>>>>>>>> would just have its own ID and then a list of CS ids > > > >>>> that belong > > > >>>>>>> to > > > >>>>>>>>> the > > > >>>>>>>>>> group. > > > >>>>>>>>>> > > > >>>>>>>>>> Scott > > > >>>>>>>>>> > > > >>>>>>>>>> -----Original Message----- > > > >>>>>>>>>> From: Elwell, John > > > >> [mailto:john.elwell@siemens-enterprise.com] > > > >>>>>>>>>> Sent: Thursday, March 31, 2011 11:50 AM > > > >>>>>>>>>> To: Scott Orton; Charles Eckel (eckelcu); Parthasarathi > > > >>>>>>> R (partr); > > > >>>>>>>>>> siprec@ietf.org > > > >>>>>>>>>> Subject: RE: [siprec] comments on > > > >> draft-ram-siprec-metadata-04 > > > >>>>>>>>>> > > > >>>>>>>>>> Scott, > > > >>>>>>>>>> > > > >>>>>>>>>> Some folks wanted to be able to group related > > CSs together > > > >>>>>>>>> (e.g., a CS > > > >>>>>>>>>> between a customer and an agent and a second CS > > > >>>>>>> resulting from the > > > >>>>>>>>>> customer being transferred to a second agent). I will > > > >>>>>>> leave it to > > > >>>>>>>>> those > > > >>>>>>>>>> folks to add to this. > > > >>>>>>>>>> > > > >>>>>>>>>> John (chair hat on) > > > >>>>>>>>>> > > > >>>>>>>>>> > > > >>>>>>>>>>> -----Original Message----- > > > >>>>>>>>>>> From: Scott Orton [mailto:sorton@broadsoft.com] > > > >>>>>>>>>>> Sent: 31 March 2011 17:43 > > > >>>>>>>>>>> To: Elwell, John; Charles Eckel (eckelcu); > > Parthasarathi R > > > >>>>>>>>>>> (partr); siprec@ietf.org > > > >>>>>>>>>>> Subject: RE: [siprec] comments on > > > >>>> draft-ram-siprec-metadata-04 > > > >>>>>>>>>>> > > > >>>>>>>>>>> John, Charles, Partha, > > > >>>>>>>>>>> I have a question. What is the purpose of the > > > >> CS Group? I > > > >>>> do > > > >>>>>>>>>>> not see it adding anything to the metadata. To me it > > > >>>> seems that > > > >>>>>>>>>>> the whole purpose of the metadata is to describe the > > > >>>> recording > > > >>>>>>>>>>> session to the SRS. Looking at the requirements I see 3 > > > >>>>>>>>>>> relationships that the spec is attempting to describe: > > > >>>>>>>>>>> > > > >>>>>>>>>>> A one to one relationship - one communication session > to > > > one > > > >>>>>>>>>>> recording session A one to many relationship - one > > > >>>> communication > > > >>>>>>>>>>> session with multiple Recording sessions > > > >>>>>>>>>>> - one Recording session > > > >>>> made up of > > > >>>>>>>>>>> multiple communications sessions > > > >>>>>>>>>>> > > > >>>>>>>>>>> The current metadata format allows all of these and I > do > > > not > > > >>>> see > > > >>>>>>>>>>> what the group is adding. > > > >>>>>>>>>>> > > > >>>>>>>>>>> Regards, > > > >>>>>>>>>>> Scott > > > >>>>>>>>>>> > > > >>>>>>> > > > >>>>>> _______________________________________________ > > > >>>>>> siprec mailing 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 Apr 20 07:46:10 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D19DCE0745 for ; Wed, 20 Apr 2011 07:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.057 X-Spam-Level: X-Spam-Status: No, score=-105.057 tagged_above=-999 required=5 tests=[AWL=1.542, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9q51F6mnnUS9 for ; Wed, 20 Apr 2011 07:46:10 -0700 (PDT) Received: from mail182.messagelabs.com (mail182.messagelabs.com [85.158.139.83]) by ietfc.amsl.com (Postfix) with SMTP id A4E69E0613 for ; Wed, 20 Apr 2011 07:46:09 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-14.tower-182.messagelabs.com!1303310768!5216292!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 23820 invoked from network); 20 Apr 2011 14:46:08 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-14.tower-182.messagelabs.com with SMTP; 20 Apr 2011 14:46:08 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 8D0E61EB83EF; Wed, 20 Apr 2011 16:46:08 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 20 Apr 2011 16:46:08 +0200 From: "Elwell, John" To: Paul Kyzivat , "siprec@ietf.org" Date: Wed, 20 Apr 2011 16:46:07 +0200 Thread-Topic: [siprec] last call comment on draft-ietf-siprec-req-09 Thread-Index: Acv/WE7qVPT9M8C8TDSzvuOG1YS4LQADyO4Q Message-ID: References: <4DAED483.6080703@cisco.com> In-Reply-To: <4DAED483.6080703@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] last call comment on draft-ietf-siprec-req-09 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 20 Apr 2011 14:46:11 -0000 I pretty much agree with what Paul and others have said in response to Char= les. The RS really represents the SIP dialog, and associated media, between= an SRC and an SRS. If two or more SRCs want to contribute to the same reco= rding, there are a number of possibilities: - Have a unique recording ID - this is not an identifier for the RS but for= the recording. - If the different SRCs are all recording parts of the same CS, a unique CS= ID or some other unique attribute of the CS would serve the purpose. - If the different SRCs are all recording different CSs from the same CS gr= oup, a unique CS Group ID would serve the purpose. All of these are likely to require some means of communication between the = SRCs, typically on the signalling path of the CS, but that has been ruled o= ut of scope for this WG (various proposals for session identifiers are kick= ing around in DISPATCH). Anyway, this is getting in the realm of solution, and the question to Charl= es is whether anything needs to be added to or changed in the Requirements = document to cover his concern. John > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 20 April 2011 13:42 > To: siprec@ietf.org > Subject: Re: [siprec] last call comment on draft-ietf-siprec-req-09 >=20 > IMO the RS is synonymous with the dialog between the SRC and the SRS,=20 > and so fundamentally there is only one SRC and one SRS per RS. >=20 > If there happen to be two SRCs in the same CS, and they establish RS1=20 > and RS2 to the *same* SRS, then it would be nice if the SRS could=20 > recognize that they are talking about the same CS. We early=20 > on ruled it=20 > out of scope, but I would like to provide at least some basics to=20 > facilitate that in the mechanism if it isn't too much trouble. >=20 > My thought here is that we at least draw the IDs from the=20 > same space, so=20 > its *possible* for the two SRCs to provide the same ID for=20 > the CS. That=20 > doesn't make it *easy* because the two SRCs would have to collaborate=20 > and share the ID before that could happen. But at least it would be=20 > *possible*. If we use a separate ID namespace for each RS=20 > that it would=20 > fundamentally be impossible. >=20 > Thanks, > Paul >=20 > On 4/19/2011 7:33 PM, Charles Eckel (eckelcu) wrote: > > I raised this comment previously, but it was not clear to me that we > > reached a conclusion. As it reads today, it is not clear to me if > > multiple SRCs per RS is supported. As I understand it, there may be > > multiple RSs per SRS, but only one SRS per RS. The question=20 > I have is: > > > > Q1. Is there a similar restriction of one SRC per RS? > > > > We could: > > A1. State the limitation of one SRC per RS. > > A2. Add a requirement that multiple SRCs per RS be supported. > > A3. Do nothing and leave it to interpretation. > > > > I am not happy with A3, and I previously was assuming A2. I could be > > convinced to go with A1. > > I see supporting multiple SRCs as being useful in=20 > distributed recording > > scenarios in which there is not a single B2BUA or=20 > conference server or > > UA that is entirely responsible of the recording. For=20 > example, a peer to > > peer SIP network in which case the peers each decide whether or not > > their input should be recorded? Or a meeting with multiple=20 > presenters in > > which each presenter sends their own contributions to be=20 > recorded? Are > > such cases intentionally left out of scope? > > > > I can see use cases in which multiple parties might want to=20 > have their > > own recording of the same call/meeting, perhaps to record=20 > it from their > > perspective or to have their permissions and preferences=20 > associated with > > the recording. This lends itself nicely to the single SRC=20 > per RS model. > > But other scenarios exist, for scalability, or geographic=20 > distribution, > > or other reasons, in which allowing multiple SRCs to contribute to a > > single RS would be useful. > > > > Support for multiple SRCs definitely increases the=20 > complexity. Perhaps > > it is worth it, perhaps not. I would like to hear what others think. > > > > Thanks, > > Charles > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > = From john.elwell@siemens-enterprise.com Wed Apr 20 07:49:00 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2BFDEE0681 for ; Wed, 20 Apr 2011 07:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.778 X-Spam-Level: X-Spam-Status: No, score=-104.778 tagged_above=-999 required=5 tests=[AWL=1.221, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y+iVgAgX4mYF for ; Wed, 20 Apr 2011 07:48:58 -0700 (PDT) Received: from mail182.messagelabs.com (mail182.messagelabs.com [85.158.139.83]) by ietfc.amsl.com (Postfix) with SMTP id 6637CE0613 for ; Wed, 20 Apr 2011 07:48:57 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-13.tower-182.messagelabs.com!1303310936!5210928!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 6339 invoked from network); 20 Apr 2011 14:48:56 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-13.tower-182.messagelabs.com with SMTP; 20 Apr 2011 14:48:56 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 90B6023F03E2; Wed, 20 Apr 2011 16:48:56 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 20 Apr 2011 16:48:56 +0200 From: "Elwell, John" To: "Ram Mohan R (rmohanr)" , "Paul Kyzivat (pkyzivat)" Date: Wed, 20 Apr 2011 16:48:54 +0200 Thread-Topic: [siprec] comments on draft-ram-siprec-metadata-04 Thread-Index: Acv+pbws7MwochNUSB2j8RZ3ismj6AAAQrXwACiVZgAABfyA0AACLm6Q Message-ID: References: <21866C7FE177A4449B9136B5B24B1B130BC011290A@EXMBXCLUS01.citservers.local><21866C7FE177A4449B9136B5B24B1B130BC011294A@EXMBXCLUS01.citservers.local><35BCE99A477D6A4986FB2216D8CF2CFD05DD8C0C@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD05EF92EF@XMB-BGL-417.cisco.com> <4D9CBD8C.4010901@cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD06133966@XMB-BGL-417.cisco.com> <4DAD8A5F.4040506@cisco.com> <4DADA8E6.9010006@cisco.com> <35BCE99A477D 6A4986FB 2216D8CF2CFD 06133A56@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD06133DD4@XMB-BGL-417.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD06133DD4@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 Cc: "siprec@ietf.org" Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 20 Apr 2011 14:49:00 -0000 > -----Original Message----- > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > Sent: 20 April 2011 14:52 > To: Elwell, John; Paul Kyzivat (pkyzivat) > Cc: Parthasarathi R (partr); siprec@ietf.org > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > John, > > I agree with you that normal cases RS will remain at least for the > duration of CS. However it is common to have use cases where recording > is done for first few mins of a CS and then stopped, re-started at a > later point (e.g Recording of a company meeting where you may want to > record only portions of meeting). > > In any case, the point I like to high light here is, MS block could be > common across RS and even across CS[ due to consult transfer e.t.c]. > These use cases indicate the need to have a unique ID for MS block > (similar to the UUID that we have defined in format) as we > cannot depend > on neither CS ID or RS ID. [JRE] I am having a hard time understanding the concept of a single Media S= tream that survives across multiple CSs. For example, in the case of transf= er, I would have thought new Media Streams would be created. John > > Let me know your comments on this. > > Regards, > Ram > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Wednesday, April 20, 2011 4:29 PM > > To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > Cc: Parthasarathi R (partr); siprec@ietf.org > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > > > I guess the point I am trying to make is that the RS has to be > > persistent so that you can continually deliver media streams to the > > SRS. Agreed it can break, and have to be re-established, but under > > normal operation it would be persistent for the duration of the CS > > being recorded (or longer in the case of "persistent recording"). So > > when a metadata update includes a Media Stream, the metadata is > > essentially tied to that RS until a further metadata update occurs > > removing that Media Stream or until the RS ceases to exist, > whichever > > is sooner. > > > > John (as individual) > > > > > -----Original Message----- > > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > > Sent: 19 April 2011 16:50 > > > To: Paul Kyzivat (pkyzivat); Elwell, John > > > Cc: Parthasarathi R (partr); siprec@ietf.org > > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > > > > > John, > > > > > > Even If we tear down the RS, we can still have the same MS > > > block in the > > > model ( and in format identified by its unique identifier). > > > Of course the properties of the MS will be different at different > > > instances. In the first instance it will have the label > > > attribute to RS1 > > > SDP. > > > In the second instance it can have label attribute pointing > > > to RS2 SDP. > > > This is just my thought and we should think through different > > > scenarios > > > to see if this can work > > > > > > Regards, > > > Ram > > > > > > > -----Original Message----- > > > > From: Paul Kyzivat (pkyzivat) > > > > Sent: Tuesday, April 19, 2011 8:53 PM > > > > To: Elwell, John > > > > Cc: Ram Mohan R (rmohanr); Parthasarathi R (partr); > siprec@ietf.org > > > > Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 > > > > > > > > > > > > > > > > On 4/19/2011 10:33 AM, Elwell, John wrote: > > > > > I think I see where you are going. Each element in a series > could > > > > potentially be delivered over a different RS. This > seems to imply > > an > > > RS > > > > only needs to exist momentarily. However, the RS has SDP > > > that contains > > > > the media descriptions, and a given media description, > > > including it's > > > > a=3Dlabel attribute tying it to a Media Stream object, > will need to > > > exist > > > > continually, between the deltas. Tearing down an RS > will also tear > > > down > > > > the delivery of media for a Media Stream to the SRS. So I am not > > > > entirely sure what you have in mind. > > > > > > > > First, the idea is only half baked, so certainly feel > free to take > > > > shots > > > > at it. > > > > > > > > And, in case of MS, perhaps you are right that you can't > > > reference the > > > > same MS from two different RS. > > > > > > > > Or maybe you could. In principle an SRC could lose the > RS dialog, > > > > establish a new one, and then continue talking about the same CS > > and > > > > MS. > > > > (This could happen if the SRS server crashed and a backup took > over > > > for > > > > it.) Its a different RTP stream on the RS, but its > > > delivering data for > > > > the same CS MS. > > > > > > > > Since in the case of a persistent RS we are prepared to > > > have a single > > > > m-line in the RS represent (serially, not concurrently) > > > different MSs, > > > > its clear there isn't a 1:1 relationship. So why not two > > > different RS > > > > m-lines representing (serially) the same MS? > > > > > > > > But the notion may be more important for other stuff that > > > changes over > > > > time. > > > > > > > > Thanks, > > > > Paul > > > > > > > > > John > > > > > > > > > > > > > > >> -----Original Message----- > > > > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > > >> Sent: 19 April 2011 14:13 > > > > >> To: Elwell, John > > > > >> Cc: Ram Mohan R (rmohanr); Parthasarathi R (partr); > > > siprec@ietf.org > > > > >> Subject: Re: [siprec] comments on > draft-ram-siprec-metadata-04 > > > > >> > > > > >> > > > > >> > > > > >> On 4/19/2011 8:32 AM, Elwell, John wrote: > > > > >>> Ram, > > > > >>> > > > > >>> I am not quite sure whether that is an issue or not. If we > > > > >> go for a single unique identifier, I suspect it would need to > > > > >> identify a CS, not an RS. In fact I was waiting to hear more > > > > >> from Paul on his assertion below, that perhaps none of the > > > > >> elements has a direct relationship with an RS. I am OK > > > > >> leaving the relationship in for now. It might become clearer > > > > >> when we resolve the question of identifiers. > > > > >> > > > > >> I haven't worked out the details. The concept would > require the > > > > >> metamodel to be modified to explicitly represent the results > > > > >> of updates. > > > > >> Then, each individually updatable datum in the model > > > would be tied > > > > to > > > > >> the update that delivered it, and thus to an RS in > which it was > > > > >> delivered and a timestamp for when it was delivered. Each > > > > >> such updatable > > > > >> datum would be represented as a time series of values. > > > > >> > > > > >> For instance, the relationship between media streams and > > > > participants > > > > >> could be represented either as: > > > > >> > > > > >> - each stream has a series for each participant in > the stream. > > > > >> Each element in the series identifies a change > in the role > > > > >> of the participant relative to that stream. > > > > >> > > > > >> - each participant has a series for each stream in which it > > > > >> participates. Each element in the series identifies a > change > > > > >> in the role of the participant relative to the stream. > > > > >> > > > > >> In either case, each element in the series would refer to the > RS > > > > over > > > > >> which it was delivered, and would have a timestamp > > > indicating when > > > > it > > > > >> occurred. > > > > >> > > > > >> For instance, elements in the series might indicate: > > > > >> - (alice:stream-1) sending@t1, inactive@t10, sending@t20, > > > > inactive@t30 > > > > >> - (bob:stream-1) recving@t2, inactive@t31 > > > > >> - (carol:stream-1) recving@t8, inactive@t12, recving@t20, > > > > inactive@t25 > > > > >> - (ted:stream-1) sending@t10, inactive@t20 > > > > >> > > > > >> Thanks, > > > > >> Paul > > > > >> > > > > >> > > > > >>> John (as individual) > > > > >>> > > > > >>>> -----Original Message----- > > > > >>>> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > > > >>>> Sent: 19 April 2011 11:31 > > > > >>>> To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); > > > > >>>> siprec@ietf.org; Elwell, John > > > > >>>> Subject: RE: [siprec] comments on > draft-ram-siprec-metadata-04 > > > > >>>> > > > > >>>> Partha, > > > > >>>> I agree with your concern here. > > > > >>>> > > > > >>>> John, > > > > >>>> Are you ok with retaining the below relation in > the model, If > > > > >>>> yes we can > > > > >>>> close this open item of the model > > > > >>>> > > > > >>>> +-------------------------------+ 1 > > > > >>>> | Recording Session (RS) |---------------+ > > > > >>>> +-------------------------------+ | > > > > >>>> |1..* |1..* | > > > > >>>> | | | > > > > >>>> |0..* |0..* | > > > > >>>> +--------------+ +-----------------+ | > > > > >>>> |Communication | | Communication | 1 | > > > > >>>> | Session (CS) |----------| Session (CS) |---| > > > > >>>> | Group |0..1 1..*| | | 0..* > > > > >> +----------+ > > > > >>>> +--------------+ +-----------------+ > > > > >> |------|Extension | > > > > >>>> 1| | 0..* |1..* | > > > > >> | Data | > > > > >>>> | | 2..* |0..* | > > > > >> +----------+ > > > > >>>> 0..*| > > > > >>>> +---------+ > > > > >>>> |Extension| > > > > >>>> | Data | > > > > >>>> +---------+ > > > > >>>> > > > > >>>> Regards, > > > > >>>> Ram > > > > >>>> > > > > >>>>> -----Original Message----- > > > > >>>>> From: Parthasarathi R (partr) > > > > >>>>> Sent: Thursday, April 07, 2011 4:07 PM > > > > >>>>> To: Paul Kyzivat (pkyzivat); siprec@ietf.org; Ram Mohan R > > > > >> (rmohanr); > > > > >>>>> Elwell, John > > > > >>>>> Subject: RE: [siprec] comments on > draft-ram-siprec-metadata- > > 04 > > > > >>>>> > > > > >>>>> John/Ram, > > > > >>>>> > > > > >>>>> I see the issue without direct link between RS and CSG. It > > may > > > be > > > > >>>> tough > > > > >>>>> to correlate CSG to RS in SRS implementation. > This issue is > > > > >>>> raised by > > > > >>>>> Hadriel in terms of having single unique id for metadata > > > > >>>> format draft. > > > > >>>>> I explained his concern in "Partial updates and > identifiers" > > > mail > > > > >>>>> thread. > > > > >>>>> > > > > >>>>> Also another issue: SRS may be interested in > knowing list of > > > > >>>> associated > > > > >>>>> RS for a given CSG. > > > > >>>>> > > > > >>>>> Thanks > > > > >>>>> Partha > > > > >>>>> > > > > >>>>> -----Original Message----- > > > > >>>>> From: siprec-bounces@ietf.org [mailto:siprec- > > bounces@ietf.org] > > > On > > > > >>>>> Behalf Of Paul Kyzivat (pkyzivat) > > > > >>>>> Sent: Thursday, April 07, 2011 12:53 AM > > > > >>>>> To: siprec@ietf.org > > > > >>>>> Subject: Re: [siprec] comments on > draft-ram-siprec-metadata- > > 04 > > > > >>>>> > > > > >>>>> John, > > > > >>>>> > > > > >>>>> I've been thinking about how everything relates to the > > > > >> RS, and that > > > > >>>>> maybe we should make some more major changes. > > > > >>>>> > > > > >>>>> What I'm thinking is that none of the elements > have a direct > > > > >>>>> relationship to RS. Rather, each element is ultimately > > > > >>>> constructed as > > > > >>>> a > > > > >>>>> time series of values delivered in updates. Its > the updates > > > > >>>> that have > > > > >>>> a > > > > >>>>> relationship to a RS - the one they are delivered in. That > > > > >>>> allows the > > > > >>>>> possibility that not all the updates come from > the same RS. > > > > >>>>> > > > > >>>>> I haven't drawn a model diagram here because the > concept is > > > still > > > > >>>>> fuzzy. > > > > >>>>> Its a trial balloon - to see what others think. > > > > >>>>> > > > > >>>>> Thanks, > > > > >>>>> Paul > > > > >>>>> > > > > >>>>> On 4/6/2011 11:47 AM, Elwell, John wrote: > > > > >>>>>> Ram, > > > > >>>>>> > > > > >>>>>> I am not sure this answers my question. In the model you > > > > >>>> drew below, > > > > >>>>> a CSG has both a direct relationship with an RS and > > > an indirect > > > > >>>>> relationship (via a CS). I was questioning > whether we could > > > > >>>> remove the > > > > >>>>> direct relationship, on the basis that the indirect > > > > >> relationship is > > > > >>>>> sufficient. > > > > >>>>>> > > > > >>>>>> John (as individual) > > > > >>>>>> > > > > >>>>>> > > > > >>>>>>> -----Original Message----- > > > > >>>>>>> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > > > >>>>>>> Sent: 06 April 2011 15:52 > > > > >>>>>>> To: Elwell, John; Scott Orton; Charles Eckel (eckelcu); > > > > >>>>> Parthasarathi > > > > >>>>>>> R (partr); siprec@ietf.org > > > > >>>>>>> Subject: RE: [siprec] comments on > > > draft-ram-siprec-metadata-04 > > > > >>>>>>> > > > > >>>>>>> Hi John, > > > > >>>>>>> > > > > >>>>>>> Yes We have an indirect relationship in the current > > > > >>>> model. However > > > > >>>>> in > > > > >>>>>>> the current model it is REQUIRED to have a CSG as CS is > > > > >> connected > > > > >>>> to > > > > >>>>>>> RS through CSG. However not all use cases would need > > > > >> CSG, IOW CSG > > > > >>>>> has > > > > >>>>>>> to be optional and there should be direct association > > > > >>>> from CS to RS > > > > >>>>>>> even when CSG is absent. > > > > >>>>>>> > > > > >>>>>>> With the below associations we will have: > > > > >>>>>>> - An instance of RS can have Zero or more CSG blocks. > > > > >>>>>>> - An instance of RS can have Zero or more CS blocks. > > > > >>>>>>> - If a CSG is present it will have 1 or more CS. > > > > >>>>>>> - Each CS can be associated with Zero or 1 CSG. > > > > >>>>>>> > > > > >>>>>>> Let me know if you have any concerns. > > > > >>>>>>> > > > > >>>>>>> Regards, > > > > >>>>>>> Ram > > > > >>>>>>> > > > > >>>>>>>> -----Original Message----- > > > > >>>>>>>> From: Elwell, John > > > [mailto:john.elwell@siemens-enterprise.com] > > > > >>>>>>>> Sent: Wednesday, April 06, 2011 6:16 PM > > > > >>>>>>>> To: Ram Mohan R (rmohanr); Scott Orton; Charles Eckel > > > > >> (eckelcu); > > > > >>>>>>>> Parthasarathi R (partr); siprec@ietf.org > > > > >>>>>>>> Subject: RE: [siprec] comments on > > > draft-ram-siprec-metadata-04 > > > > >>>>>>>> > > > > >>>>>>>> I am OK in principle, but I wonder whether there really > > > > >>>>>>> needs to be a > > > > >>>>>>>> relationship between CSG and RS. Isn't that > relationship > > an > > > > >>>>> indirect > > > > >>>>>>>> relationship via CS? > > > > >>>>>>>> > > > > >>>>>>>> John (as individual) > > > > >>>>>>>> > > > > >>>>>>>> > > > > >>>>>>>>> -----Original Message----- > > > > >>>>>>>>> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > > > >>>>>>>>> Sent: 03 April 2011 18:13 > > > > >>>>>>>>> To: Scott Orton; Elwell, John; Charles Eckel > (eckelcu); > > > > >>>>>>>>> Parthasarathi R (partr); siprec@ietf.org > > > > >>>>>>>>> Subject: RE: [siprec] comments on > > > draft-ram-siprec-metadata- > > > > 04 > > > > >>>>>>>>> > > > > >>>>>>>>> Scott, > > > > >>>>>>>>> > > > > >>>>>>>>> I am ok to make this change to the model. I would like > to > > > > >>>>>>> hear from > > > > >>>>>>>>> others if they have any issues in incorporating > > > this change > > > > in > > > > >>>> the > > > > >>>>>>>>> model. > > > > >>>>>>>>> > > > > >>>>>>>>> The updated portion of the model will look like > > > > >>>>>>>>> > > > > >>>>>>>>> > > > > >>>>>>>>> +-------------------------------+ 1 > > > > >>>>>>>>> | Recording Session (RS) |---------------+ > > > > >>>>>>>>> +-------------------------------+ | > > > > >>>>>>>>> | 1..* |1..* | > > > > >>>>>>>>> | | | > > > > >>>>>>>>> | 0..* |0..* | > > > > >>>>>>>>> +--------------+ +-----------------+ | > > > > >>>>>>>>> |Communication | | Communication | 1 | > > > > >>>>>>>>> | Session (CS) |----------| Session (CS) |---| > > > > >>>>>>>>> | Group |0..1 1..*| > > > | | 0..* > > > > >>>>>>> +----------+ > > > > >>>>>>>>> +--------------+ +-----------------+ > > > > >>>>>>> |------|Extension > > > > >>>>>>> | > > > > >>>>>>>>> 1| | 0..* |1..* | > > > > >>>> | Data > > > > >>>>>>> | > > > > >>>>>>>>> | | 2..* |0..* | > > > > >>>>>>> +----------+ > > > > >>>>>>>>> 0..*| > > > > >>>>>>>>> +---------+ > > > > >>>>>>>>> |Extension| > > > > >>>>>>>>> | Data | > > > > >>>>>>>>> +---------+ > > > > >>>>>>>>> > > > > >>>>>>>>> The only change in the association is : > > > > >>>>>>>>> A CS MUST be associated with zero or one CS-Group > > > > >>>>>>>>> > > > > >>>>>>>>> Rest of the associations remain same. Further the > > > association > > > > >>>>>>>>> between CS and RS remains same as what is between CS- > > Group > > > > and > > > > >>>> RS. > > > > >>>>>>>>> > > > > >>>>>>>>> Comments ? > > > > >>>>>>>>> > > > > >>>>>>>>> Regards, > > > > >>>>>>>>> Ram > > > > >>>>>>>>> > > > > >>>>>>>>>> -----Original Message----- > > > > >>>>>>>>>> From: siprec-bounces@ietf.org > > > > >>>>>>> [mailto:siprec-bounces@ietf.org] On > > > > >>>>>>>>>> Behalf Of Scott Orton > > > > >>>>>>>>>> Sent: Friday, April 01, 2011 12:18 AM > > > > >>>>>>>>>> To: Elwell, John; Charles Eckel (eckelcu); > > > Parthasarathi R > > > > >>>>>>> (partr); > > > > >>>>>>>>>> siprec@ietf.org > > > > >>>>>>>>>> Subject: Re: [siprec] comments on > > > > >> draft-ram-siprec-metadata-04 > > > > >>>>>>>>>> > > > > >>>>>>>>>> John, > > > > >>>>>>>>>> Thanks for the information. > > > > >>>>>>>>>> > > > > >>>>>>>>>> In that case I would like to see the > CS group be > > > > >>>>>>> made optional. > > > > >>>>>>>>>> Rather than the CS pointing to the CS Group, I would > > like > > > to > > > > >>>>>>>> suggest > > > > >>>>>>>>>> that the CS point to the RS and have the CS > group stand > > > > >>>>>>>>> alone where it > > > > >>>>>>>>>> would just have its own ID and then a list of CS ids > > > > >>>> that belong > > > > >>>>>>> to > > > > >>>>>>>>> the > > > > >>>>>>>>>> group. > > > > >>>>>>>>>> > > > > >>>>>>>>>> Scott > > > > >>>>>>>>>> > > > > >>>>>>>>>> -----Original Message----- > > > > >>>>>>>>>> From: Elwell, John > > > > >> [mailto:john.elwell@siemens-enterprise.com] > > > > >>>>>>>>>> Sent: Thursday, March 31, 2011 11:50 AM > > > > >>>>>>>>>> To: Scott Orton; Charles Eckel (eckelcu); > Parthasarathi > > > > >>>>>>> R (partr); > > > > >>>>>>>>>> siprec@ietf.org > > > > >>>>>>>>>> Subject: RE: [siprec] comments on > > > > >> draft-ram-siprec-metadata-04 > > > > >>>>>>>>>> > > > > >>>>>>>>>> Scott, > > > > >>>>>>>>>> > > > > >>>>>>>>>> Some folks wanted to be able to group related > > > CSs together > > > > >>>>>>>>> (e.g., a CS > > > > >>>>>>>>>> between a customer and an agent and a second CS > > > > >>>>>>> resulting from the > > > > >>>>>>>>>> customer being transferred to a second agent). I will > > > > >>>>>>> leave it to > > > > >>>>>>>>> those > > > > >>>>>>>>>> folks to add to this. > > > > >>>>>>>>>> > > > > >>>>>>>>>> John (chair hat on) > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>>> -----Original Message----- > > > > >>>>>>>>>>> From: Scott Orton [mailto:sorton@broadsoft.com] > > > > >>>>>>>>>>> Sent: 31 March 2011 17:43 > > > > >>>>>>>>>>> To: Elwell, John; Charles Eckel (eckelcu); > > > Parthasarathi R > > > > >>>>>>>>>>> (partr); siprec@ietf.org > > > > >>>>>>>>>>> Subject: RE: [siprec] comments on > > > > >>>> draft-ram-siprec-metadata-04 > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> John, Charles, Partha, > > > > >>>>>>>>>>> I have a question. What is the purpose of the > > > > >> CS Group? I > > > > >>>> do > > > > >>>>>>>>>>> not see it adding anything to the metadata. To me it > > > > >>>> seems that > > > > >>>>>>>>>>> the whole purpose of the metadata is to describe the > > > > >>>> recording > > > > >>>>>>>>>>> session to the SRS. Looking at the > requirements I see > 3 > > > > >>>>>>>>>>> relationships that the spec is attempting > to describe: > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> A one to one relationship - one > communication session > > to > > > > one > > > > >>>>>>>>>>> recording session A one to many relationship - one > > > > >>>> communication > > > > >>>>>>>>>>> session with multiple Recording sessions > > > > >>>>>>>>>>> - one > Recording session > > > > >>>> made up of > > > > >>>>>>>>>>> multiple communications sessions > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> The current metadata format allows all of > these and I > > do > > > > not > > > > >>>> see > > > > >>>>>>>>>>> what the group is adding. > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> Regards, > > > > >>>>>>>>>>> Scott > > > > >>>>>>>>>>> > > > > >>>>>>> > > > > >>>>>> _______________________________________________ > > > > >>>>>> siprec mailing 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 Apr 20 07:51:57 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 59F8DE0701 for ; Wed, 20 Apr 2011 07:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J+axU52HQ8dO for ; Wed, 20 Apr 2011 07:51:56 -0700 (PDT) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfc.amsl.com (Postfix) with ESMTP id EAA4BE06E1 for ; Wed, 20 Apr 2011 07:51:55 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Wed, 20 Apr 2011 17:51:54 +0300 From: Leon Portman To: "Elwell, John" , Paul Kyzivat , "siprec@ietf.org" Date: Wed, 20 Apr 2011 17:51:53 +0300 Thread-Topic: [siprec] last call comment on draft-ietf-siprec-req-09 Thread-Index: Acv/WE7qVPT9M8C8TDSzvuOG1YS4LQADyO4QAACXe0A= Message-ID: <07465C1D981ABC41A344374066AE1A2C38AB73DB0C@TLVMBX01.nice.com> References: <4DAED483.6080703@cisco.com> In-Reply-To: Accept-Language: en-US, he-IL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, he-IL Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] last call comment on draft-ietf-siprec-req-09 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 20 Apr 2011 14:51:57 -0000 +1 The question is if it is more metadata requirement than the mechanism requi= rement. Leon -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Elwell, John Sent: Wednesday, April 20, 2011 5:46 PM To: Paul Kyzivat; siprec@ietf.org Subject: Re: [siprec] last call comment on draft-ietf-siprec-req-09 I pretty much agree with what Paul and others have said in response to Char= les. The RS really represents the SIP dialog, and associated media, between= an SRC and an SRS. If two or more SRCs want to contribute to the same reco= rding, there are a number of possibilities: - Have a unique recording ID - this is not an identifier for the RS but for= the recording. - If the different SRCs are all recording parts of the same CS, a unique CS= ID or some other unique attribute of the CS would serve the purpose. - If the different SRCs are all recording different CSs from the same CS gr= oup, a unique CS Group ID would serve the purpose. All of these are likely to require some means of communication between the = SRCs, typically on the signalling path of the CS, but that has been ruled o= ut of scope for this WG (various proposals for session identifiers are kick= ing around in DISPATCH). Anyway, this is getting in the realm of solution, and the question to Charl= es is whether anything needs to be added to or changed in the Requirements = document to cover his concern. John > -----Original Message----- > From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 20 April 2011 13:42 > To: siprec@ietf.org > Subject: Re: [siprec] last call comment on draft-ietf-siprec-req-09 >=20 > IMO the RS is synonymous with the dialog between the SRC and the SRS,=20 > and so fundamentally there is only one SRC and one SRS per RS. >=20 > If there happen to be two SRCs in the same CS, and they establish RS1=20 > and RS2 to the *same* SRS, then it would be nice if the SRS could=20 > recognize that they are talking about the same CS. We early on ruled=20 > it out of scope, but I would like to provide at least some basics to=20 > facilitate that in the mechanism if it isn't too much trouble. >=20 > My thought here is that we at least draw the IDs from the same space,=20 > so its *possible* for the two SRCs to provide the same ID for the CS.=20 > That doesn't make it *easy* because the two SRCs would have to=20 > collaborate and share the ID before that could happen. But at least it=20 > would be *possible*. If we use a separate ID namespace for each RS=20 > that it would fundamentally be impossible. >=20 > Thanks, > Paul >=20 > On 4/19/2011 7:33 PM, Charles Eckel (eckelcu) wrote: > > I raised this comment previously, but it was not clear to me that we=20 > > reached a conclusion. As it reads today, it is not clear to me if=20 > > multiple SRCs per RS is supported. As I understand it, there may be=20 > > multiple RSs per SRS, but only one SRS per RS. The question > I have is: > > > > Q1. Is there a similar restriction of one SRC per RS? > > > > We could: > > A1. State the limitation of one SRC per RS. > > A2. Add a requirement that multiple SRCs per RS be supported. > > A3. Do nothing and leave it to interpretation. > > > > I am not happy with A3, and I previously was assuming A2. I could be=20 > > convinced to go with A1. > > I see supporting multiple SRCs as being useful in > distributed recording > > scenarios in which there is not a single B2BUA or > conference server or > > UA that is entirely responsible of the recording. For > example, a peer to > > peer SIP network in which case the peers each decide whether or not=20 > > their input should be recorded? Or a meeting with multiple > presenters in > > which each presenter sends their own contributions to be > recorded? Are > > such cases intentionally left out of scope? > > > > I can see use cases in which multiple parties might want to > have their > > own recording of the same call/meeting, perhaps to record > it from their > > perspective or to have their permissions and preferences > associated with > > the recording. This lends itself nicely to the single SRC > per RS model. > > But other scenarios exist, for scalability, or geographic > distribution, > > or other reasons, in which allowing multiple SRCs to contribute to a=20 > > single RS would be useful. > > > > Support for multiple SRCs definitely increases the > complexity. Perhaps > > it is worth it, perhaps not. I would like to hear what others think. > > > > Thanks, > > Charles > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec >=20 _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From rmohanr@cisco.com Wed Apr 20 10:07:55 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7C08AE06CE for ; Wed, 20 Apr 2011 10:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.025 X-Spam-Level: X-Spam-Status: No, score=-10.025 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rmkkKdmeqCxW for ; Wed, 20 Apr 2011 10:07:53 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfc.amsl.com (Postfix) with ESMTP id 3A781E0695 for ; Wed, 20 Apr 2011 10:07:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=24691; q=dns/txt; s=iport; t=1303319272; x=1304528872; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=gzmGJE/MMvfVNCdN7fu4FgNYJpsojiPWu26IaB+Yp44=; b=P8ytPhuF7PYofaw0ESrJ408S/bQ0QWOWj1mV1zblzQs7fwPKv3uB2ioc QJrkR/YDZslV/faF2+6uFCRWbqiAkpbryX1uUF7g/bf0JQEmdeWkjQr/r g5CXdzYl7dHxBJFZzoaduW3r8Ue0T8C5QtmbCxHYYn0rU+vZk3SBuJOx+ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtcAABwSr02Q/khRgWdsb2JhbACXMY4KFAEBCwsmJYhvogScfoJ/gnIEhXKMNg X-IronPort-AV: E=Sophos;i="4.64,247,1301875200"; d="scan'208";a="26482122" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 20 Apr 2011 17:07:51 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3KH7nHL019168; Wed, 20 Apr 2011 17:07:50 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); Wed, 20 Apr 2011 22:37:49 +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: Wed, 20 Apr 2011 22:37:46 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD06133E6B@XMB-BGL-417.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] comments on draft-ram-siprec-metadata-04 Thread-Index: Acv+pbws7MwochNUSB2j8RZ3ismj6AAAQrXwACiVZgAABfyA0AACLm6QAASWOmA= References: <21866C7FE177A4449B9136B5B24B1B130BC011290A@EXMBXCLUS01.citservers.local><21866C7FE177A4449B9136B5B24B1B130BC011294A@EXMBXCLUS01.citservers.local><35BCE99A477D6A4986FB2216D8CF2CFD05DD8C0C@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD05EF92EF@XMB-BGL-417.cisco.com> <4D9CBD8C.4010901@cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD06133966@XMB-BGL-417.cisco.com> <4DAD8A5F.4040506@cisco.com> <4DADA8E6.9010006@cisco.com> <35BCE99A477D 6A4986F B 2216D8CF2C FD06133A56@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD06133DD4@XMB-BGL-417.cisco.com> From: "Ram Mohan R (rmohanr)" To: "Elwell, John" , "Paul Kyzivat (pkyzivat)" X-OriginalArrivalTime: 20 Apr 2011 17:07:49.0299 (UTC) FILETIME=[79FFC030:01CBFF7D] Cc: siprec@ietf.org Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 20 Apr 2011 17:07:55 -0000 Hi John, Please see inline [RAM] > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Wednesday, April 20, 2011 8:19 PM > To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > Cc: Parthasarathi R (partr); siprec@ietf.org > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 >=20 >=20 >=20 > > -----Original Message----- > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > Sent: 20 April 2011 14:52 > > To: Elwell, John; Paul Kyzivat (pkyzivat) > > Cc: Parthasarathi R (partr); siprec@ietf.org > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > > > John, > > > > I agree with you that normal cases RS will remain at least for the > > duration of CS. However it is common to have use cases where > recording > > is done for first few mins of a CS and then stopped, re-started at a > > later point (e.g Recording of a company meeting where you may want to > > record only portions of meeting). > > > > In any case, the point I like to high light here is, MS block could > be > > common across RS and even across CS[ due to consult transfer e.t.c]. > > These use cases indicate the need to have a unique ID for MS block > > (similar to the UUID that we have defined in format) as we > > cannot depend > > on neither CS ID or RS ID. > [JRE] I am having a hard time understanding the concept of a single > Media Stream that survives across multiple CSs. For example, in the > case of transfer, I would have thought new Media Streams would be > created. [RAM] Here is my thoughts.=20 1) There can be multiple RS per CS=20 RS1 --- CS1--MS1 RS2----CS1--MS1 Examples are partial recording of CS (like recording parts of meeting, redundant recording where there are multiple SRCs recording the same CS) 2) There can be same Media Stream across multiple CS.=20 RS1--- CS1--- MS1 RS2--CS2--MS1 Examples are Multicast MoH played to multiple end points who are potentially part of disjoint CSs where each CS is recorded as part of separate RS. Of course the above is arguable where the stream is same or different. My view is since the UA (that supplies the Multicast MoH) and its media are same across all CS, I think it can be represented as same MS block. However it is still possible to treat each as separate stream in the model, in which case the information that it is the same MS played by a UA to different CS will be lost. I don't know if there is an interest to capture this level of detail and if it is of any use to SRS. Regards, Ram >=20 > John >=20 >=20 > > > > Let me know your comments on this. > > > > Regards, > > Ram > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > Sent: Wednesday, April 20, 2011 4:29 PM > > > To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > > Cc: Parthasarathi R (partr); siprec@ietf.org > > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > > > > > I guess the point I am trying to make is that the RS has to be > > > persistent so that you can continually deliver media streams to the > > > SRS. Agreed it can break, and have to be re-established, but under > > > normal operation it would be persistent for the duration of the CS > > > being recorded (or longer in the case of "persistent recording"). > So > > > when a metadata update includes a Media Stream, the metadata is > > > essentially tied to that RS until a further metadata update occurs > > > removing that Media Stream or until the RS ceases to exist, > > whichever > > > is sooner. > > > > > > John (as individual) > > > > > > > -----Original Message----- > > > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > > > Sent: 19 April 2011 16:50 > > > > To: Paul Kyzivat (pkyzivat); Elwell, John > > > > Cc: Parthasarathi R (partr); siprec@ietf.org > > > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > > > > > > > John, > > > > > > > > Even If we tear down the RS, we can still have the same MS > > > > block in the > > > > model ( and in format identified by its unique identifier). > > > > Of course the properties of the MS will be different at different > > > > instances. In the first instance it will have the label > > > > attribute to RS1 > > > > SDP. > > > > In the second instance it can have label attribute pointing > > > > to RS2 SDP. > > > > This is just my thought and we should think through different > > > > scenarios > > > > to see if this can work > > > > > > > > Regards, > > > > Ram > > > > > > > > > -----Original Message----- > > > > > From: Paul Kyzivat (pkyzivat) > > > > > Sent: Tuesday, April 19, 2011 8:53 PM > > > > > To: Elwell, John > > > > > Cc: Ram Mohan R (rmohanr); Parthasarathi R (partr); > > siprec@ietf.org > > > > > Subject: Re: [siprec] comments on draft-ram-siprec-metadata-04 > > > > > > > > > > > > > > > > > > > > On 4/19/2011 10:33 AM, Elwell, John wrote: > > > > > > I think I see where you are going. Each element in a series > > could > > > > > potentially be delivered over a different RS. This > > seems to imply > > > an > > > > RS > > > > > only needs to exist momentarily. However, the RS has SDP > > > > that contains > > > > > the media descriptions, and a given media description, > > > > including it's > > > > > a=3Dlabel attribute tying it to a Media Stream object, > > will need to > > > > exist > > > > > continually, between the deltas. Tearing down an RS > > will also tear > > > > down > > > > > the delivery of media for a Media Stream to the SRS. So I am > not > > > > > entirely sure what you have in mind. > > > > > > > > > > First, the idea is only half baked, so certainly feel > > free to take > > > > > shots > > > > > at it. > > > > > > > > > > And, in case of MS, perhaps you are right that you can't > > > > reference the > > > > > same MS from two different RS. > > > > > > > > > > Or maybe you could. In principle an SRC could lose the > > RS dialog, > > > > > establish a new one, and then continue talking about the same > CS > > > and > > > > > MS. > > > > > (This could happen if the SRS server crashed and a backup took > > over > > > > for > > > > > it.) Its a different RTP stream on the RS, but its > > > > delivering data for > > > > > the same CS MS. > > > > > > > > > > Since in the case of a persistent RS we are prepared to > > > > have a single > > > > > m-line in the RS represent (serially, not concurrently) > > > > different MSs, > > > > > its clear there isn't a 1:1 relationship. So why not two > > > > different RS > > > > > m-lines representing (serially) the same MS? > > > > > > > > > > But the notion may be more important for other stuff that > > > > changes over > > > > > time. > > > > > > > > > > Thanks, > > > > > Paul > > > > > > > > > > > John > > > > > > > > > > > > > > > > > >> -----Original Message----- > > > > > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > > > >> Sent: 19 April 2011 14:13 > > > > > >> To: Elwell, John > > > > > >> Cc: Ram Mohan R (rmohanr); Parthasarathi R (partr); > > > > siprec@ietf.org > > > > > >> Subject: Re: [siprec] comments on > > draft-ram-siprec-metadata-04 > > > > > >> > > > > > >> > > > > > >> > > > > > >> On 4/19/2011 8:32 AM, Elwell, John wrote: > > > > > >>> Ram, > > > > > >>> > > > > > >>> I am not quite sure whether that is an issue or not. If we > > > > > >> go for a single unique identifier, I suspect it would need > to > > > > > >> identify a CS, not an RS. In fact I was waiting to hear more > > > > > >> from Paul on his assertion below, that perhaps none of the > > > > > >> elements has a direct relationship with an RS. I am OK > > > > > >> leaving the relationship in for now. It might become clearer > > > > > >> when we resolve the question of identifiers. > > > > > >> > > > > > >> I haven't worked out the details. The concept would > > require the > > > > > >> metamodel to be modified to explicitly represent the results > > > > > >> of updates. > > > > > >> Then, each individually updatable datum in the model > > > > would be tied > > > > > to > > > > > >> the update that delivered it, and thus to an RS in > > which it was > > > > > >> delivered and a timestamp for when it was delivered. Each > > > > > >> such updatable > > > > > >> datum would be represented as a time series of values. > > > > > >> > > > > > >> For instance, the relationship between media streams and > > > > > participants > > > > > >> could be represented either as: > > > > > >> > > > > > >> - each stream has a series for each participant in > > the stream. > > > > > >> Each element in the series identifies a change > > in the role > > > > > >> of the participant relative to that stream. > > > > > >> > > > > > >> - each participant has a series for each stream in which it > > > > > >> participates. Each element in the series identifies a > > change > > > > > >> in the role of the participant relative to the stream. > > > > > >> > > > > > >> In either case, each element in the series would refer to > the > > RS > > > > > over > > > > > >> which it was delivered, and would have a timestamp > > > > indicating when > > > > > it > > > > > >> occurred. > > > > > >> > > > > > >> For instance, elements in the series might indicate: > > > > > >> - (alice:stream-1) sending@t1, inactive@t10, sending@t20, > > > > > inactive@t30 > > > > > >> - (bob:stream-1) recving@t2, inactive@t31 > > > > > >> - (carol:stream-1) recving@t8, inactive@t12, recving@t20, > > > > > inactive@t25 > > > > > >> - (ted:stream-1) sending@t10, inactive@t20 > > > > > >> > > > > > >> Thanks, > > > > > >> Paul > > > > > >> > > > > > >> > > > > > >>> John (as individual) > > > > > >>> > > > > > >>>> -----Original Message----- > > > > > >>>> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > > > > >>>> Sent: 19 April 2011 11:31 > > > > > >>>> To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); > > > > > >>>> siprec@ietf.org; Elwell, John > > > > > >>>> Subject: RE: [siprec] comments on > > draft-ram-siprec-metadata-04 > > > > > >>>> > > > > > >>>> Partha, > > > > > >>>> I agree with your concern here. > > > > > >>>> > > > > > >>>> John, > > > > > >>>> Are you ok with retaining the below relation in > > the model, If > > > > > >>>> yes we can > > > > > >>>> close this open item of the model > > > > > >>>> > > > > > >>>> +-------------------------------+ 1 > > > > > >>>> | Recording Session (RS) |---------------+ > > > > > >>>> +-------------------------------+ | > > > > > >>>> |1..* |1..* | > > > > > >>>> | | | > > > > > >>>> |0..* |0..* | > > > > > >>>> +--------------+ +-----------------+ | > > > > > >>>> |Communication | | Communication | 1 | > > > > > >>>> | Session (CS) |----------| Session (CS) |---| > > > > > >>>> | Group |0..1 1..*| | | 0..* > > > > > >> +----------+ > > > > > >>>> +--------------+ +-----------------+ > > > > > >> |------|Extension | > > > > > >>>> 1| | 0..* |1..* | > > > > > >> | Data | > > > > > >>>> | | 2..* |0..* | > > > > > >> +----------+ > > > > > >>>> 0..*| > > > > > >>>> +---------+ > > > > > >>>> |Extension| > > > > > >>>> | Data | > > > > > >>>> +---------+ > > > > > >>>> > > > > > >>>> Regards, > > > > > >>>> Ram > > > > > >>>> > > > > > >>>>> -----Original Message----- > > > > > >>>>> From: Parthasarathi R (partr) > > > > > >>>>> Sent: Thursday, April 07, 2011 4:07 PM > > > > > >>>>> To: Paul Kyzivat (pkyzivat); siprec@ietf.org; Ram Mohan R > > > > > >> (rmohanr); > > > > > >>>>> Elwell, John > > > > > >>>>> Subject: RE: [siprec] comments on > > draft-ram-siprec-metadata- > > > 04 > > > > > >>>>> > > > > > >>>>> John/Ram, > > > > > >>>>> > > > > > >>>>> I see the issue without direct link between RS and CSG. > It > > > may > > > > be > > > > > >>>> tough > > > > > >>>>> to correlate CSG to RS in SRS implementation. > > This issue is > > > > > >>>> raised by > > > > > >>>>> Hadriel in terms of having single unique id for metadata > > > > > >>>> format draft. > > > > > >>>>> I explained his concern in "Partial updates and > > identifiers" > > > > mail > > > > > >>>>> thread. > > > > > >>>>> > > > > > >>>>> Also another issue: SRS may be interested in > > knowing list of > > > > > >>>> associated > > > > > >>>>> RS for a given CSG. > > > > > >>>>> > > > > > >>>>> Thanks > > > > > >>>>> Partha > > > > > >>>>> > > > > > >>>>> -----Original Message----- > > > > > >>>>> From: siprec-bounces@ietf.org [mailto:siprec- > > > bounces@ietf.org] > > > > On > > > > > >>>>> Behalf Of Paul Kyzivat (pkyzivat) > > > > > >>>>> Sent: Thursday, April 07, 2011 12:53 AM > > > > > >>>>> To: siprec@ietf.org > > > > > >>>>> Subject: Re: [siprec] comments on > > draft-ram-siprec-metadata- > > > 04 > > > > > >>>>> > > > > > >>>>> John, > > > > > >>>>> > > > > > >>>>> I've been thinking about how everything relates to the > > > > > >> RS, and that > > > > > >>>>> maybe we should make some more major changes. > > > > > >>>>> > > > > > >>>>> What I'm thinking is that none of the elements > > have a direct > > > > > >>>>> relationship to RS. Rather, each element is ultimately > > > > > >>>> constructed as > > > > > >>>> a > > > > > >>>>> time series of values delivered in updates. Its > > the updates > > > > > >>>> that have > > > > > >>>> a > > > > > >>>>> relationship to a RS - the one they are delivered in. > That > > > > > >>>> allows the > > > > > >>>>> possibility that not all the updates come from > > the same RS. > > > > > >>>>> > > > > > >>>>> I haven't drawn a model diagram here because the > > concept is > > > > still > > > > > >>>>> fuzzy. > > > > > >>>>> Its a trial balloon - to see what others think. > > > > > >>>>> > > > > > >>>>> Thanks, > > > > > >>>>> Paul > > > > > >>>>> > > > > > >>>>> On 4/6/2011 11:47 AM, Elwell, John wrote: > > > > > >>>>>> Ram, > > > > > >>>>>> > > > > > >>>>>> I am not sure this answers my question. In the model you > > > > > >>>> drew below, > > > > > >>>>> a CSG has both a direct relationship with an RS and > > > > an indirect > > > > > >>>>> relationship (via a CS). I was questioning > > whether we could > > > > > >>>> remove the > > > > > >>>>> direct relationship, on the basis that the indirect > > > > > >> relationship is > > > > > >>>>> sufficient. > > > > > >>>>>> > > > > > >>>>>> John (as individual) > > > > > >>>>>> > > > > > >>>>>> > > > > > >>>>>>> -----Original Message----- > > > > > >>>>>>> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > > > > >>>>>>> Sent: 06 April 2011 15:52 > > > > > >>>>>>> To: Elwell, John; Scott Orton; Charles Eckel (eckelcu); > > > > > >>>>> Parthasarathi > > > > > >>>>>>> R (partr); siprec@ietf.org > > > > > >>>>>>> Subject: RE: [siprec] comments on > > > > draft-ram-siprec-metadata-04 > > > > > >>>>>>> > > > > > >>>>>>> Hi John, > > > > > >>>>>>> > > > > > >>>>>>> Yes We have an indirect relationship in the current > > > > > >>>> model. However > > > > > >>>>> in > > > > > >>>>>>> the current model it is REQUIRED to have a CSG as CS is > > > > > >> connected > > > > > >>>> to > > > > > >>>>>>> RS through CSG. However not all use cases would need > > > > > >> CSG, IOW CSG > > > > > >>>>> has > > > > > >>>>>>> to be optional and there should be direct association > > > > > >>>> from CS to RS > > > > > >>>>>>> even when CSG is absent. > > > > > >>>>>>> > > > > > >>>>>>> With the below associations we will have: > > > > > >>>>>>> - An instance of RS can have Zero or more CSG blocks. > > > > > >>>>>>> - An instance of RS can have Zero or more CS blocks. > > > > > >>>>>>> - If a CSG is present it will have 1 or more CS. > > > > > >>>>>>> - Each CS can be associated with Zero or 1 CSG. > > > > > >>>>>>> > > > > > >>>>>>> Let me know if you have any concerns. > > > > > >>>>>>> > > > > > >>>>>>> Regards, > > > > > >>>>>>> Ram > > > > > >>>>>>> > > > > > >>>>>>>> -----Original Message----- > > > > > >>>>>>>> From: Elwell, John > > > > [mailto:john.elwell@siemens-enterprise.com] > > > > > >>>>>>>> Sent: Wednesday, April 06, 2011 6:16 PM > > > > > >>>>>>>> To: Ram Mohan R (rmohanr); Scott Orton; Charles Eckel > > > > > >> (eckelcu); > > > > > >>>>>>>> Parthasarathi R (partr); siprec@ietf.org > > > > > >>>>>>>> Subject: RE: [siprec] comments on > > > > draft-ram-siprec-metadata-04 > > > > > >>>>>>>> > > > > > >>>>>>>> I am OK in principle, but I wonder whether there > really > > > > > >>>>>>> needs to be a > > > > > >>>>>>>> relationship between CSG and RS. Isn't that > > relationship > > > an > > > > > >>>>> indirect > > > > > >>>>>>>> relationship via CS? > > > > > >>>>>>>> > > > > > >>>>>>>> John (as individual) > > > > > >>>>>>>> > > > > > >>>>>>>> > > > > > >>>>>>>>> -----Original Message----- > > > > > >>>>>>>>> From: Ram Mohan R (rmohanr) > [mailto:rmohanr@cisco.com] > > > > > >>>>>>>>> Sent: 03 April 2011 18:13 > > > > > >>>>>>>>> To: Scott Orton; Elwell, John; Charles Eckel > > (eckelcu); > > > > > >>>>>>>>> Parthasarathi R (partr); siprec@ietf.org > > > > > >>>>>>>>> Subject: RE: [siprec] comments on > > > > draft-ram-siprec-metadata- > > > > > 04 > > > > > >>>>>>>>> > > > > > >>>>>>>>> Scott, > > > > > >>>>>>>>> > > > > > >>>>>>>>> I am ok to make this change to the model. I would > like > > to > > > > > >>>>>>> hear from > > > > > >>>>>>>>> others if they have any issues in incorporating > > > > this change > > > > > in > > > > > >>>> the > > > > > >>>>>>>>> model. > > > > > >>>>>>>>> > > > > > >>>>>>>>> The updated portion of the model will look like > > > > > >>>>>>>>> > > > > > >>>>>>>>> > > > > > >>>>>>>>> +-------------------------------+ 1 > > > > > >>>>>>>>> | Recording Session (RS) |--------------- > + > > > > > >>>>>>>>> +-------------------------------+ > | > > > > > >>>>>>>>> | 1..* |1..* > | > > > > > >>>>>>>>> | | > | > > > > > >>>>>>>>> | 0..* |0..* > | > > > > > >>>>>>>>> +--------------+ +-----------------+ > | > > > > > >>>>>>>>> |Communication | | Communication | 1 > | > > > > > >>>>>>>>> | Session (CS) |----------| Session (CS) |--- > | > > > > > >>>>>>>>> | Group |0..1 1..*| > > > > | | 0..* > > > > > >>>>>>> +----------+ > > > > > >>>>>>>>> +--------------+ +-----------------+ > > > > > >>>>>>> |------|Extension > > > > > >>>>>>> | > > > > > >>>>>>>>> 1| | 0..* |1..* > | > > > > > >>>> | Data > > > > > >>>>>>> | > > > > > >>>>>>>>> | | 2..* |0..* > | > > > > > >>>>>>> +----------+ > > > > > >>>>>>>>> 0..*| > > > > > >>>>>>>>> +---------+ > > > > > >>>>>>>>> |Extension| > > > > > >>>>>>>>> | Data | > > > > > >>>>>>>>> +---------+ > > > > > >>>>>>>>> > > > > > >>>>>>>>> The only change in the association is : > > > > > >>>>>>>>> A CS MUST be associated with zero or one CS-Group > > > > > >>>>>>>>> > > > > > >>>>>>>>> Rest of the associations remain same. Further the > > > > association > > > > > >>>>>>>>> between CS and RS remains same as what is between CS- > > > Group > > > > > and > > > > > >>>> RS. > > > > > >>>>>>>>> > > > > > >>>>>>>>> Comments ? > > > > > >>>>>>>>> > > > > > >>>>>>>>> Regards, > > > > > >>>>>>>>> Ram > > > > > >>>>>>>>> > > > > > >>>>>>>>>> -----Original Message----- > > > > > >>>>>>>>>> From: siprec-bounces@ietf.org > > > > > >>>>>>> [mailto:siprec-bounces@ietf.org] On > > > > > >>>>>>>>>> Behalf Of Scott Orton > > > > > >>>>>>>>>> Sent: Friday, April 01, 2011 12:18 AM > > > > > >>>>>>>>>> To: Elwell, John; Charles Eckel (eckelcu); > > > > Parthasarathi R > > > > > >>>>>>> (partr); > > > > > >>>>>>>>>> siprec@ietf.org > > > > > >>>>>>>>>> Subject: Re: [siprec] comments on > > > > > >> draft-ram-siprec-metadata-04 > > > > > >>>>>>>>>> > > > > > >>>>>>>>>> John, > > > > > >>>>>>>>>> Thanks for the information. > > > > > >>>>>>>>>> > > > > > >>>>>>>>>> In that case I would like to see the > > CS group be > > > > > >>>>>>> made optional. > > > > > >>>>>>>>>> Rather than the CS pointing to the CS Group, I would > > > like > > > > to > > > > > >>>>>>>> suggest > > > > > >>>>>>>>>> that the CS point to the RS and have the CS > > group stand > > > > > >>>>>>>>> alone where it > > > > > >>>>>>>>>> would just have its own ID and then a list of CS ids > > > > > >>>> that belong > > > > > >>>>>>> to > > > > > >>>>>>>>> the > > > > > >>>>>>>>>> group. > > > > > >>>>>>>>>> > > > > > >>>>>>>>>> Scott > > > > > >>>>>>>>>> > > > > > >>>>>>>>>> -----Original Message----- > > > > > >>>>>>>>>> From: Elwell, John > > > > > >> [mailto:john.elwell@siemens-enterprise.com] > > > > > >>>>>>>>>> Sent: Thursday, March 31, 2011 11:50 AM > > > > > >>>>>>>>>> To: Scott Orton; Charles Eckel (eckelcu); > > Parthasarathi > > > > > >>>>>>> R (partr); > > > > > >>>>>>>>>> siprec@ietf.org > > > > > >>>>>>>>>> Subject: RE: [siprec] comments on > > > > > >> draft-ram-siprec-metadata-04 > > > > > >>>>>>>>>> > > > > > >>>>>>>>>> Scott, > > > > > >>>>>>>>>> > > > > > >>>>>>>>>> Some folks wanted to be able to group related > > > > CSs together > > > > > >>>>>>>>> (e.g., a CS > > > > > >>>>>>>>>> between a customer and an agent and a second CS > > > > > >>>>>>> resulting from the > > > > > >>>>>>>>>> customer being transferred to a second agent). I > will > > > > > >>>>>>> leave it to > > > > > >>>>>>>>> those > > > > > >>>>>>>>>> folks to add to this. > > > > > >>>>>>>>>> > > > > > >>>>>>>>>> John (chair hat on) > > > > > >>>>>>>>>> > > > > > >>>>>>>>>> > > > > > >>>>>>>>>>> -----Original Message----- > > > > > >>>>>>>>>>> From: Scott Orton [mailto:sorton@broadsoft.com] > > > > > >>>>>>>>>>> Sent: 31 March 2011 17:43 > > > > > >>>>>>>>>>> To: Elwell, John; Charles Eckel (eckelcu); > > > > Parthasarathi R > > > > > >>>>>>>>>>> (partr); siprec@ietf.org > > > > > >>>>>>>>>>> Subject: RE: [siprec] comments on > > > > > >>>> draft-ram-siprec-metadata-04 > > > > > >>>>>>>>>>> > > > > > >>>>>>>>>>> John, Charles, Partha, > > > > > >>>>>>>>>>> I have a question. What is the purpose of the > > > > > >> CS Group? I > > > > > >>>> do > > > > > >>>>>>>>>>> not see it adding anything to the metadata. To me > it > > > > > >>>> seems that > > > > > >>>>>>>>>>> the whole purpose of the metadata is to describe > the > > > > > >>>> recording > > > > > >>>>>>>>>>> session to the SRS. Looking at the > > requirements I see > > 3 > > > > > >>>>>>>>>>> relationships that the spec is attempting > > to describe: > > > > > >>>>>>>>>>> > > > > > >>>>>>>>>>> A one to one relationship - one > > communication session > > > to > > > > > one > > > > > >>>>>>>>>>> recording session A one to many relationship - one > > > > > >>>> communication > > > > > >>>>>>>>>>> session with multiple Recording sessions > > > > > >>>>>>>>>>> - one > > Recording session > > > > > >>>> made up of > > > > > >>>>>>>>>>> multiple communications sessions > > > > > >>>>>>>>>>> > > > > > >>>>>>>>>>> The current metadata format allows all of > > these and I > > > do > > > > > not > > > > > >>>> see > > > > > >>>>>>>>>>> what the group is adding. > > > > > >>>>>>>>>>> > > > > > >>>>>>>>>>> Regards, > > > > > >>>>>>>>>>> Scott > > > > > >>>>>>>>>>> > > > > > >>>>>>> > > > > > >>>>>> _______________________________________________ > > > > > >>>>>> siprec mailing 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 Wed Apr 20 12:52:15 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D6785E06A4 for ; Wed, 20 Apr 2011 12:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.328 X-Spam-Level: X-Spam-Status: No, score=-10.328 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i5Vfrulf7Mqa for ; Wed, 20 Apr 2011 12:52:14 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfc.amsl.com (Postfix) with ESMTP id 700FCE0669 for ; Wed, 20 Apr 2011 12:52:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=5892; q=dns/txt; s=iport; t=1303329134; x=1304538734; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=Fr0N0IvkU7056cCDsGWTMD0z/P8c2GfQrd7q4yfuYE8=; b=bkn0hjxx5UaMnoJBqubw2X9m0giePkIYeye1WjoPos7ePY+ypI4KPkui uECnAMoAW7Aq63Ep+jCDEeIwQsbua0FPKAoM+qJCbx887efCUge26qrjQ bwQH24wkwHe/Nk9pAxGJCoJjiM1LaaBuED0FJEwC3GcN5YMLf4F8zYqsX g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkgBAMc4r02rRDoG/2dsb2JhbACXOI4Kd6o6nHiFcQSFdIw0 X-IronPort-AV: E=Sophos;i="4.64,247,1301875200"; d="scan'208";a="341546502" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-2.cisco.com with ESMTP; 20 Apr 2011 19:52:13 +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 p3KJqDvr014244; Wed, 20 Apr 2011 19:52:13 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, 20 Apr 2011 12:52:13 -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, 20 Apr 2011 12:52:11 -0700 Message-ID: In-Reply-To: <07465C1D981ABC41A344374066AE1A2C38AB73DB0C@TLVMBX01.nice.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] last call comment on draft-ietf-siprec-req-09 Thread-Index: Acv/WE7qVPT9M8C8TDSzvuOG1YS4LQADyO4QAACXe0AACpFtgA== References: <4DAED483.6080703@cisco.com> <07465C1D981ABC41A344374066AE1A2C38AB73DB0C@TLVMBX01.nice.com> From: "Charles Eckel (eckelcu)" To: "Leon Portman" , "Elwell, John" , "Paul Kyzivat (pkyzivat)" , X-OriginalArrivalTime: 20 Apr 2011 19:52:13.0724 (UTC) FILETIME=[71A78DC0:01CBFF94] Subject: Re: [siprec] last call comment on draft-ietf-siprec-req-09 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 20 Apr 2011 19:52:16 -0000 Works for me. This addresses my concern and I agree that no new requirements or modifications to requirements are necessary for this from my perspective. Cheers, Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Leon Portman > Sent: Wednesday, April 20, 2011 7:52 AM > To: Elwell, John; Paul Kyzivat (pkyzivat); siprec@ietf.org > Subject: Re: [siprec] last call comment on draft-ietf-siprec-req-09 >=20 > +1 >=20 > The question is if it is more metadata requirement than the mechanism requirement. >=20 > Leon >=20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > Sent: Wednesday, April 20, 2011 5:46 PM > To: Paul Kyzivat; siprec@ietf.org > Subject: Re: [siprec] last call comment on draft-ietf-siprec-req-09 >=20 > I pretty much agree with what Paul and others have said in response to Charles. The RS really > represents the SIP dialog, and associated media, between an SRC and an SRS. If two or more SRCs want > to contribute to the same recording, there are a number of possibilities: > - Have a unique recording ID - this is not an identifier for the RS but for the recording. > - If the different SRCs are all recording parts of the same CS, a unique CS ID or some other unique > attribute of the CS would serve the purpose. > - If the different SRCs are all recording different CSs from the same CS group, a unique CS Group ID > would serve the purpose. > All of these are likely to require some means of communication between the SRCs, typically on the > signalling path of the CS, but that has been ruled out of scope for this WG (various proposals for > session identifiers are kicking around in DISPATCH). >=20 > Anyway, this is getting in the realm of solution, and the question to Charles is whether anything > needs to be added to or changed in the Requirements document to cover his concern. >=20 > John >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > > Sent: 20 April 2011 13:42 > > To: siprec@ietf.org > > Subject: Re: [siprec] last call comment on draft-ietf-siprec-req-09 > > > > IMO the RS is synonymous with the dialog between the SRC and the SRS, > > and so fundamentally there is only one SRC and one SRS per RS. > > > > If there happen to be two SRCs in the same CS, and they establish RS1 > > and RS2 to the *same* SRS, then it would be nice if the SRS could > > recognize that they are talking about the same CS. We early on ruled > > it out of scope, but I would like to provide at least some basics to > > facilitate that in the mechanism if it isn't too much trouble. > > > > My thought here is that we at least draw the IDs from the same space, > > so its *possible* for the two SRCs to provide the same ID for the CS. > > That doesn't make it *easy* because the two SRCs would have to > > collaborate and share the ID before that could happen. But at least it > > would be *possible*. If we use a separate ID namespace for each RS > > that it would fundamentally be impossible. > > > > Thanks, > > Paul > > > > On 4/19/2011 7:33 PM, Charles Eckel (eckelcu) wrote: > > > I raised this comment previously, but it was not clear to me that we > > > reached a conclusion. As it reads today, it is not clear to me if > > > multiple SRCs per RS is supported. As I understand it, there may be > > > multiple RSs per SRS, but only one SRS per RS. The question > > I have is: > > > > > > Q1. Is there a similar restriction of one SRC per RS? > > > > > > We could: > > > A1. State the limitation of one SRC per RS. > > > A2. Add a requirement that multiple SRCs per RS be supported. > > > A3. Do nothing and leave it to interpretation. > > > > > > I am not happy with A3, and I previously was assuming A2. I could be > > > convinced to go with A1. > > > I see supporting multiple SRCs as being useful in > > distributed recording > > > scenarios in which there is not a single B2BUA or > > conference server or > > > UA that is entirely responsible of the recording. For > > example, a peer to > > > peer SIP network in which case the peers each decide whether or not > > > their input should be recorded? Or a meeting with multiple > > presenters in > > > which each presenter sends their own contributions to be > > recorded? Are > > > such cases intentionally left out of scope? > > > > > > I can see use cases in which multiple parties might want to > > have their > > > own recording of the same call/meeting, perhaps to record > > it from their > > > perspective or to have their permissions and preferences > > associated with > > > the recording. This lends itself nicely to the single SRC > > per RS model. > > > But other scenarios exist, for scalability, or geographic > > distribution, > > > or other reasons, in which allowing multiple SRCs to contribute to a > > > single RS would be useful. > > > > > > Support for multiple SRCs definitely increases the > > complexity. Perhaps > > > it is worth it, perhaps not. I would like to hear what others think. > > > > > > Thanks, > > > Charles > > > _______________________________________________ > > > siprec mailing list > > > siprec@ietf.org > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > > > _______________________________________________ > siprec mailing 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 Apr 20 23:31:09 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 518D4E06AA for ; Wed, 20 Apr 2011 23:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.114 X-Spam-Level: X-Spam-Status: No, score=-105.114 tagged_above=-999 required=5 tests=[AWL=1.485, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H4Xsl9jVxKsr for ; Wed, 20 Apr 2011 23:31:08 -0700 (PDT) Received: from mail216.messagelabs.com (mail216.messagelabs.com [85.158.143.99]) by ietfc.amsl.com (Postfix) with SMTP id 21F5CE069C for ; Wed, 20 Apr 2011 23:31:07 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-3.tower-216.messagelabs.com!1303367466!2884863!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 26625 invoked from network); 21 Apr 2011 06:31:06 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-3.tower-216.messagelabs.com with SMTP; 21 Apr 2011 06:31:06 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 1778D23F03E2; Thu, 21 Apr 2011 08:31:06 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 21 Apr 2011 08:31:06 +0200 From: "Elwell, John" To: "Ram Mohan R (rmohanr)" , "Paul Kyzivat (pkyzivat)" Date: Thu, 21 Apr 2011 08:31:05 +0200 Thread-Topic: Does MS have life outside a particular CS? (was RE: [siprec] comments on draft-ram-siprec-metadata-04) Thread-Index: Acv+pbws7MwochNUSB2j8RZ3ismj6AAAQrXwACiVZgAABfyA0AACLm6QAASWOmAAG+JhEA== Message-ID: References: <21866C7FE177A4449B9136B5B24B1B130BC011290A@EXMBXCLUS01.citservers.local><21866C7FE177A4449B9136B5B24B1B130BC011294A@EXMBXCLUS01.citservers.local><35BCE99A477D6A4986FB2216D8CF2CFD05DD8C0C@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD05EF92EF@XMB-BGL-417.cisco.com> <4D9CBD8C.4010901@cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD06133966@XMB-BGL-417.cisco.com> <4DAD8A5F.4040506@cisco.com> <4DADA8E6.9010006@cisco.com> <35BCE99A477D 6A4986F B 2216D8CF2C FD06133A56@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD06133DD4@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD06133E6B@XMB-BGL-417.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD06133E6B@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 Cc: "siprec@ietf.org" Subject: [siprec] Does MS have life outside a particular CS? (was RE: comments on draft-ram-siprec-metadata-04) X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 21 Apr 2011 06:31:09 -0000 =20 > -----Original Message----- > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com]=20 > Sent: 20 April 2011 18:08 > To: Elwell, John; Paul Kyzivat (pkyzivat) > Cc: Parthasarathi R (partr); siprec@ietf.org > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 >=20 > Hi John, >=20 > Please see inline [RAM] >=20 > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Wednesday, April 20, 2011 8:19 PM > > To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > Cc: Parthasarathi R (partr); siprec@ietf.org > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > > Sent: 20 April 2011 14:52 > > > To: Elwell, John; Paul Kyzivat (pkyzivat) > > > Cc: Parthasarathi R (partr); siprec@ietf.org > > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > > > > > John, > > > > > > I agree with you that normal cases RS will remain at least for the > > > duration of CS. However it is common to have use cases where > > recording > > > is done for first few mins of a CS and then stopped,=20 > re-started at a > > > later point (e.g Recording of a company meeting where you may want > to > > > record only portions of meeting). > > > > > > In any case, the point I like to high light here is, MS=20 > block could > > be > > > common across RS and even across CS[ due to consult=20 > transfer e.t.c]. > > > These use cases indicate the need to have a unique ID for MS block > > > (similar to the UUID that we have defined in format) as we > > > cannot depend > > > on neither CS ID or RS ID. > > [JRE] I am having a hard time understanding the concept of a single > > Media Stream that survives across multiple CSs. For example, in the > > case of transfer, I would have thought new Media Streams would be > > created. >=20 > [RAM] > Here is my thoughts.=20 > 1) There can be multiple RS per CS=20 > RS1 --- CS1--MS1 > RS2----CS1--MS1 > Examples are partial recording of CS (like recording parts of meeting, > redundant recording where there are multiple SRCs recording=20 > the same CS) [JRE] Agreed. In this case MS1 is local to CS1. >=20 > 2) There can be same Media Stream across multiple CS.=20 > RS1--- CS1--- MS1 > RS2--CS2--MS1 > Examples are Multicast MoH played to multiple end points who are > potentially part of disjoint CSs where each CS is recorded as part of > separate RS. >=20 > Of course the above is arguable where the stream is same or different. > My view is since the UA (that supplies the Multicast MoH) and=20 > its media > are same across all CS, I think it can be represented as same=20 > MS block. [JRE] I would argue these are different MSs. I agree that a medium such as = music on hold might be sent, in synch, to multiple participants in multiple= CSs. In that particular situation there might be some efficiency saving by= calling it the same MS. However, I would suggest (although this is not my = field of expertise) it would make life a lot harder for the SRS and its dat= abase. I would have expected to want to record a complete CS (all its parti= cipants and media streams) as a complete recording, which could be deleted= , copied, and so on without having to go looking for other objects that com= plete that recording and are shared with other recordings. For example, if = you delete a recording, you would want to delete all its MSs, but not those= used by other recordings, although you would need a garbage collection mec= hanism to delete an MS recording when it is no longer used by any CS record= ings. Rather ugly. Making a MS local to a CS would simplify all this. >=20 >=20 > However it is still possible to treat each as separate stream in the > model, in which case the information that it is the same MS=20 > played by a > UA to different CS will be lost. I don't know if there is an=20 > interest to > capture this level of detail and if it is of any use to SRS. [JRE] I assume what you are saying here is not that information will be los= t, but that you will be unable to tell, without doing a comparison, whether= two different MSs played to participants in two different CSs are identica= l or not for the particular time span that is common. I don't see where suc= h a requirement would come from. John (as individual) From mperumal@cisco.com Thu Apr 21 04:44:50 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id AD2C3E0748; Thu, 21 Apr 2011 04:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.174 X-Spam-Level: X-Spam-Status: No, score=-10.174 tagged_above=-999 required=5 tests=[AWL=0.425, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qkfj-veM24a2; Thu, 21 Apr 2011 04:44:49 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfc.amsl.com (Postfix) with ESMTP id 8A03EE06DA; Thu, 21 Apr 2011 04:44:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=10560; q=dns/txt; s=iport; t=1303386288; x=1304595888; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=ER0mNLYMUtQSPJT9wInos3ls+PM80cq62b0pbd8GYYU=; b=TiN+HLSmTze3eW35tyHGwbYB+WA4R/7DEdAufiGIbwWA2XU9mWIa4G2Y HDRPeY3cYhvNFGbzZxW0Y237Vvm1PbLEc9uqcFSLbn/80z1kVY/3ptmaY AUz64iVYl7F+1Z/Fx2+acqOETqgNiAtiNcKJEC/IjRV20psJbsGe0guO3 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsAAHEXsE2Q/khMgWdsb2JhbACXQY4HFAEBFiYlqBecUYIig1QEhXKMRQ X-IronPort-AV: E=Sophos;i="4.64,251,1301875200"; d="scan'208";a="26604637" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 21 Apr 2011 11:44:47 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3LBiiEn015210; Thu, 21 Apr 2011 11:44:46 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Apr 2011 17:14:45 +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, 21 Apr 2011 17:14:43 +0530 Message-ID: <1D062974A4845E4D8A343C6538049202054256F5@XMB-BGL-414.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Last Call: (Use CasesandRequirements for SIP-based MediaRecording (SIPREC)) toInformational RFC Thread-Index: Acv0WYBeRuGjGNBtTZSHeqn78QP5xwGEv6YwAAlHtwAAAvtH0AABcMXAAAdJn6AAAIZ7cAAHjozgABTz8IABOK4eoA== References: <20110406125020.17538.70016.idtracker@localhost><1D062974A4845E4D8A343C65380492020533BB70@XMB-BGL-414.cisco.com><07465C1D981ABC41A344374066AE1A2C38AB73D00B@TLVMBX01.nice.com> <07465C1D981ABC41A344374066AE1A2C38AB73D110@TLVMBX01.nice.com> <35BCE99A477D6A4986FB2216D8CF2CFD06009D00@XMB-BGL-417.cisco.com> <1D062974A4845E4D8A343C65380492020533BD38@XMB-BGL-414.cisco.com> From: "Muthu ArulMozhi Perumal (mperumal)" To: "Elwell, John" , "Ram Mohan R (rmohanr)" , "Leon Portman" , X-OriginalArrivalTime: 21 Apr 2011 11:44:45.0701 (UTC) FILETIME=[82E32B50:01CC0019] Cc: siprec@ietf.org Subject: Re: [siprec] Last Call: (Use CasesandRequirements for SIP-based MediaRecording (SIPREC)) toInformational RFC X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 21 Apr 2011 11:44:50 -0000 +1 I would suggest a small change to REQ-022 that John has drafted below to make it more explicit: =20 REQ-022 The mechanism MUST provide means for facilitating the following either at storage or at playback: a. Synchronization among the recorded media streams and=20 b. Synchronization of the recorded media streams and metadata. Muthu |-----Original Message----- |From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] |Sent: Friday, April 15, 2011 11:53 AM |To: Muthu ArulMozhi Perumal (mperumal); Ram Mohan R (rmohanr); Leon Portman; ietf@ietf.org |Cc: siprec@ietf.org |Subject: RE: [siprec] Last Call: (Use CasesandRequirements for SIP-based |MediaRecording (SIPREC)) toInformational RFC | |So perhaps if we replace REQ-022 and REQ-023 with the requirement that Muthu has proposed and one |further requirement, e.g.: | |"REQ-022 The mechanism MUST provide means for facilitating synchronization of the |recorded media streams and metadata either at storage or at playback. | |REQ-023 The mechanism MUST provide means for relating recordings to wall clock time." | |John (as individual) | |> -----Original Message----- |> From: Muthu ArulMozhi Perumal (mperumal) [mailto:mperumal@cisco.com] |> Sent: 14 April 2011 21:42 |> To: Ram Mohan R (rmohanr); Leon Portman; Elwell, John; ietf@ietf.org |> Cc: siprec@ietf.org |> Subject: RE: [siprec] Last Call: |> (Use Cases andRequirements for |> SIP-based MediaRecording (SIPREC)) toInformational RFC |> |> I agree with John that these seem more like part of a solution rather |> than actual requirements. In addition, sending the wallclock time at |> media start/end alone may not suffice for achieving inter-media |> synchronization and playback, instead we may need to send the |> wallclock |> time periodically, like RTCP. For e.g, if there is a codec |> renegotiation |> in CS the RTP timestamp can restart from a random value. If silence |> suppression is enabled there would be gaps in the RTP timestamp. |> |> These are things that need to be discussed as part of the solution -- |> the requirement itself should be generic enough, like what I |> described. |> REQ-022 and REQ-023 we have doesn't seem to clearly indicate the |> purpose. |> |> Muthu |> |> |-----Original Message----- |> |From: Ram Mohan R (rmohanr) |> |Sent: Thursday, April 14, 2011 10:13 PM |> |To: Leon Portman; Elwell, John; Muthu ArulMozhi Perumal (mperumal); |> ietf@ietf.org |> |Cc: siprec@ietf.org |> |Subject: RE: [siprec] Last Call: (Use |> Cases andRequirements for SIP- |> |based MediaRecording (SIPREC)) toInformational RFC |> | |> |We already have attributes Start-Time / End-time in Media Stream |> block. This is for the same purpose |> |to indicate the wall clock time for start/end of media. |> | |> |Ram |> | |> |> -----Original Message----- |> |> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On |> |> Behalf Of Leon Portman |> |> Sent: Thursday, April 14, 2011 9:57 PM |> |> To: Elwell, John; Muthu ArulMozhi Perumal (mperumal); ietf@ietf.org |> |> Cc: siprec@ietf.org |> |> Subject: Re: [siprec] Last Call: (Use |> |> Cases andRequirements for SIP-based MediaRecording (SIPREC)) |> |> toInformational RFC |> |> |> |> I am not sure that having wall clock only for CS start is enough, |> |> especially for partial metadata update. I will prefer to have on |> media |> |> level |> |> |> |> Leon |> |> |> |> -----Original Message----- |> |> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] |> |> Sent: Thursday, April 14, 2011 3:58 PM |> |> To: Leon Portman; Muthu ArulMozhi Perumal (mperumal); ietf@ietf.org |> |> Cc: siprec@ietf.org |> |> Subject: RE: [siprec] Last Call: |> (Use |> |> Cases andRequirements for SIP-based Media Recording (SIPREC)) |> |> toInformational RFC |> |> |> |> Understood, but if we have wall clock time for the start of a CS, |> |> wouldn't that be sufficient? The new requirement would cover |> |> synchronization of all media start/stops relative to that time. |> |> |> |> John (as individual) |> |> |> |> |> |> > -----Original Message----- |> |> > From: Leon Portman [mailto:Leon.Portman@nice.com] |> |> > Sent: 14 April 2011 13:19 |> |> > To: Elwell, John; Muthu ArulMozhi Perumal (mperumal); |> ietf@ietf.org |> |> > Cc: siprec@ietf.org |> |> > Subject: RE: [siprec] Last Call: |> |> > (Use Cases andRequirements for |> |> > SIP-based Media Recording (SIPREC)) toInformational RFC |> |> > |> |> > Actually REQ-022 and REQ-023 describing not only requirement to |> |> > synchronize between different media streams but more importantly |> |> > ability to relate them to real world (wall) clock. It is not only |> |> > important to playback them correctly but also to know when it was |> |> > said. |> |> > One example is continue trading after closing hour (even for one |> |> > second is not allowed) |> |> > |> |> > And if these media are synchronized to wall clock then they are |> also |> |> > synchronized between them thus I am not sure if we need this |> |> > additional requirement. |> |> > |> |> > Thanks |> |> > |> |> > Leon |> |> > |> |> > -----Original Message----- |> |> > From: siprec-bounces@ietf.org |> |> > [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John |> |> > Sent: Thursday, April 14, 2011 1:54 PM |> |> > To: Muthu ArulMozhi Perumal (mperumal); ietf@ietf.org |> |> > Cc: siprec@ietf.org |> |> > Subject: Re: [siprec] Last Call: |> |> > (Use Cases andRequirements for |> |> > SIP-based Media Recording (SIPREC)) toInformational RFC |> |> > |> |> > |> |> > |> |> > |> |> > > -----Original Message----- |> |> > > From: siprec-bounces@ietf.org |> |> > > [mailto:siprec-bounces@ietf.org] On Behalf Of Muthu |> |> > ArulMozhi Perumal |> |> > > (mperumal) |> |> > > Sent: 14 April 2011 07:34 |> |> > > To: ietf@ietf.org |> |> > > Cc: siprec@ietf.org |> |> > > Subject: Re: [siprec] Last Call: |> |> > > (Use Cases andRequirements for |> |> > > SIP-based Media Recording (SIPREC)) toInformational RFC |> |> > > |> |> > > I've one major comment. It draft discusses synchronization |> |> > between the |> |> > > recorded media streams and synchronized playback, which |> |> > seem important |> |> > > for certain applications: |> |> > > |> |> > > |> |> > > Some applications require the recording of more than one |> |> > media stream, |> |> > > possibly of different types. Media are synchronized, either |> |> > at storage |> |> > > or at playback. |> |> > > |> |> > > |> |> > > However, in the requirements section it doesn't seem |> REQ-022 and |> |> > > REQ-023 are all that are need and sufficient to |> achieve this with |> |> > > needed precision. So, I would suggest adding another |> requirement |> as |> |> > > follows: |> |> > > The mechanism MUST provide means for facilitating |> |> > synchronization of |> |> > > the recorded media streams and metadata either at storage or at |> |> > > playback. |> |> > > This includes, but not limited to, the information |> needed as per |> |> > > REQ-022 and REQ-023. |> |> > [JRE] This seems a reasonable addition. I wonder if the new |> |> > requirement (first sentence only) is sufficient as a |> |> > **replacement** for REQ-022 and REQ-023. On reading REQ-022 and |> |> > REQ-023 again, it is not so clear what their purpose |> was, and they |> |> > seem to be more like a solution than a requirement. |> |> > One purpose would certainly be that covered by Muthu's new |> |> > requirement. Was there any other purpose? |> |> > |> |> > John |> |> > |> |> > > |> |> > > A nitpick: |> |> > > Use Case 8 |> |> > > In cases where calls inside or between branches must |> be recorded, |> a |> |> > > centralized recording system in data centers together with |> |> > telephony |> |> > > infrastructure (e.g. PBX) me deployed. |> |> > > |> |> > > s/me/may be |> |> > > |> |> > > Muthu |> |> > > |> |> > > |-----Original Message----- |> |> > > |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] |> On |> |> > > Behalf Of The IESG |> |> > > |Sent: Wednesday, April 06, 2011 6:20 PM |> |> > > |To: IETF-Announce |> |> > > |Cc: siprec@ietf.org |> |> > > |Subject: [siprec] Last Call: |> |> > > (Use Cases |> |> > > andRequirements for SIP-based |> |> > > |Media Recording (SIPREC)) toInformational RFC |> |> > > | |> |> > > | |> |> > > |The IESG has received a request from the SIP Recording WG |> |> > (siprec) to |> |> > > |consider the following document: |> |> > > |- 'Use Cases and Requirements for SIP-based Media |> |> > Recording (SIPREC)' |> |> > > | as an Informational RFC |> |> > > | |> |> > > |The IESG plans to make a decision in the next few weeks, |> |> > and solicits |> |> > > |final comments on this action. Please send substantive |> |> > > comments to the |> |> > > |ietf@ietf.org mailing lists by 2011-04-20. Exceptionally, |> |> > > comments may |> |> > > be |> |> > > |sent to iesg@ietf.org instead. In either case, please |> retain the |> |> > > |beginning of the Subject line to allow automated sorting. |> |> > > | |> |> > > |The file can be obtained via |> |> > > |http://datatracker.ietf.org/doc/draft-ietf-siprec-req/ |> |> > > | |> |> > > |IESG discussion can be tracked via |> |> > > |http://datatracker.ietf.org/doc/draft-ietf-siprec-req/ |> |> > > | |> |> > > | |> |> > > | |> |> > > |No IPR declarations have been submitted directly on this I-D. |> |> > > |_______________________________________________ |> |> > > |siprec mailing 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 partr@cisco.com Thu Apr 21 06:24:44 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A5F60E0689 for ; Thu, 21 Apr 2011 06:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.111 X-Spam-Level: X-Spam-Status: No, score=-10.111 tagged_above=-999 required=5 tests=[AWL=0.488, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztU934qs6I6y for ; Thu, 21 Apr 2011 06:24:43 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfc.amsl.com (Postfix) with ESMTP id 12B18E0665 for ; Thu, 21 Apr 2011 06:24:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=6664; q=dns/txt; s=iport; t=1303392283; x=1304601883; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=biNsxdyAh84Skdv4QxetmF77OUJubjB8z1+LZdX3FHY=; b=JwEVx9+MCRQyxkNVVDG9FmvaiuYiq95pdveIi9kWZwS0SnhncReTyg/S UCMMdoTrLJXHt+YyUOjfS4hM2an5dh9PcE03LIvZ0MgwUSQeNvrENOO2z ZvFNbR9k7u717XyvhW6hfFeLb/SXHNyOWdSka97ebh6sjLvklqlI+eaV2 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwAABwvsE2Q/khRgWdsb2JhbACXQY4HFAEBFiYliHCfJ5xdhXYEhXKMRQ X-IronPort-AV: E=Sophos;i="4.64,251,1301875200"; d="scan'208";a="84586720" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 21 Apr 2011 13:24:41 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3LDOe6O009529; Thu, 21 Apr 2011 13:24:41 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Apr 2011 18:54:39 +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, 21 Apr 2011 18:54:39 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Does MS have life outside a particular CS? (was RE: [siprec] comments on draft-ram-siprec-metadata-04) Thread-Index: Acv+pbws7MwochNUSB2j8RZ3ismj6AAAQrXwACiVZgAABfyA0AACLm6QAASWOmAAG+JhEAANxV4A References: <21866C7FE177A4449B9136B5B24B1B130BC011290A@EXMBXCLUS01.citservers.local><21866C7FE177A4449B9136B5B24B1B130BC011294A@EXMBXCLUS01.citservers.local><35BCE99A477D6A4986FB2216D8CF2CFD05DD8C0C@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD05EF92EF@XMB-BGL-417.cisco.com> <4D9CBD8C.4010901@cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD06133966@XMB-BGL-417.cisco.com> <4DAD8A5F.4040506@cisco.com> <4DADA8E6.9010006@cisco.com> <35BCE99A477D 6A4986 F B 2216D8CF 2CFD06133A56@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD06133DD4@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD06133E6B@XMB-BGL-417.cisco.com> From: "Parthasarathi R (partr)" To: "Elwell, John" , "Ram Mohan R (rmohanr)" , "Paul Kyzivat (pkyzivat)" X-OriginalArrivalTime: 21 Apr 2011 13:24:39.0911 (UTC) FILETIME=[77B70770:01CC0027] Cc: siprec@ietf.org Subject: Re: [siprec] Does MS have life outside a particular CS? (was RE: comments on draft-ram-siprec-metadata-04) X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 21 Apr 2011 13:24:44 -0000 John, I could think of one usecase wherein MS is outside CS but within single RS. The usecase is multiple CS within single RS and MS. The usecase is as follows: B2BUA acts as SRC. A, B, C are participants within single B2BUA. A creates single RS for a CSG. 1) A calls B through B2BUA. B2BUA creates RS towards SRS with CSG1, CS1, MS1 (A's media stream), MS2 (B's media stream), Participant1 as A & Participant2 as B. 2) B connects with C through B2BUA 3) B transfer the call of A & B to C using REFER, B2BUA converts REFER to RE-INVITE towards A & C and A & C are connected. B2BUA updates RS with CS2, Participant1 as A & participant2 as C, MS1(A's media stream), MS2(C's media stream). There is no update on RS1, CSG1, MS1, MS2. MS2 will become MS2 with the new association and in terms of format, it will associate with tag. In the above scenario, MS have life outside CS but it is within RS. The unique id shall be within RS scope as mentioned in IETF-80 meeting. But in another situation, MS is outside the scope of RS but within CS and the usecase is Multiple RS for single CS, details are as follows: A, B are pariticipants. A acts as SRC which tear down RS whenever hold happens & creates new RS when resume happens. 1) A calls B. A creates RS1 towards SRS with CS1, MS1 (A's media stream), MS2 (B's Media stream),Participant1 as A & Participant2 as B. 2) A put B on hold. A tear down RS1. 3) A resume B. A creates RS2 towards SRS with CS1, MS1 (A's media stream), MS2 (B's Media stream),Participant1 as A & Participant2 as B Here MS1 & MS2 needs to be same across RS to group media streams correctly. Please let me know your opinion here. Having said that MS have life outside a particular CS, I create separate thread within unique how it shall be handled.=20 Thanks Partha -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 Sent: Thursday, April 21, 2011 12:01 PM To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) Cc: Parthasarathi R (partr); siprec@ietf.org Subject: Does MS have life outside a particular CS? (was RE: [siprec] comments on draft-ram-siprec-metadata-04) =20 > -----Original Message----- > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > Sent: 20 April 2011 18:08 > To: Elwell, John; Paul Kyzivat (pkyzivat) > Cc: Parthasarathi R (partr); siprec@ietf.org > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 >=20 > Hi John, >=20 > Please see inline [RAM] >=20 > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Wednesday, April 20, 2011 8:19 PM > > To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > Cc: Parthasarathi R (partr); siprec@ietf.org > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > > Sent: 20 April 2011 14:52 > > > To: Elwell, John; Paul Kyzivat (pkyzivat) > > > Cc: Parthasarathi R (partr); siprec@ietf.org > > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > > > > > John, > > > > > > I agree with you that normal cases RS will remain at least for the > > > duration of CS. However it is common to have use cases where > > recording > > > is done for first few mins of a CS and then stopped, > re-started at a > > > later point (e.g Recording of a company meeting where you may want > to > > > record only portions of meeting). > > > > > > In any case, the point I like to high light here is, MS > block could > > be > > > common across RS and even across CS[ due to consult > transfer e.t.c]. > > > These use cases indicate the need to have a unique ID for MS block > > > (similar to the UUID that we have defined in format) as we cannot=20 > > > depend on neither CS ID or RS ID. > > [JRE] I am having a hard time understanding the concept of a single=20 > > Media Stream that survives across multiple CSs. For example, in the=20 > > case of transfer, I would have thought new Media Streams would be=20 > > created. >=20 > [RAM] > Here is my thoughts.=20 > 1) There can be multiple RS per CS > RS1 --- CS1--MS1 > RS2----CS1--MS1 > Examples are partial recording of CS (like recording parts of meeting, > redundant recording where there are multiple SRCs recording the same=20 > CS) [JRE] Agreed. In this case MS1 is local to CS1. >=20 > 2) There can be same Media Stream across multiple CS.=20 > RS1--- CS1--- MS1 > RS2--CS2--MS1 > Examples are Multicast MoH played to multiple end points who are=20 > potentially part of disjoint CSs where each CS is recorded as part of=20 > separate RS. >=20 > Of course the above is arguable where the stream is same or different. > My view is since the UA (that supplies the Multicast MoH) and its=20 > media are same across all CS, I think it can be represented as same MS > block. [JRE] I would argue these are different MSs. I agree that a medium such as music on hold might be sent, in synch, to multiple participants in multiple CSs. In that particular situation there might be some efficiency saving by calling it the same MS. However, I would suggest (although this is not my field of expertise) it would make life a lot harder for the SRS and its database. I would have expected to want to record a complete CS (all its participants and media streams) as a complete recording, which could be deleted, copied, and so on without having to go looking for other objects that complete that recording and are shared with other recordings. For example, if you delete a recording, you would want to delete all its MSs, but not those used by other recordings, although you would need a garbage collection mechanism to delete an MS recording when it is no longer used by any CS recordings. Rather ugly. Making a MS local to a CS would simplify all this. >=20 >=20 > However it is still possible to treat each as separate stream in the=20 > model, in which case the information that it is the same MS played by=20 > a UA to different CS will be lost. I don't know if there is an=20 > interest to capture this level of detail and if it is of any use to=20 > SRS. [JRE] I assume what you are saying here is not that information will be lost, but that you will be unable to tell, without doing a comparison, whether two different MSs played to participants in two different CSs are identical or not for the particular time span that is common. I don't see where such a requirement would come from. John (as individual) From partr@cisco.com Thu Apr 21 06:51:03 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 030F0E0689; Thu, 21 Apr 2011 06:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.133 X-Spam-Level: X-Spam-Status: No, score=-10.133 tagged_above=-999 required=5 tests=[AWL=0.466, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMDSSzKE5ae1; Thu, 21 Apr 2011 06:51:01 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfc.amsl.com (Postfix) with ESMTP id 8C116E00BE; Thu, 21 Apr 2011 06:51:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=11874; q=dns/txt; s=iport; t=1303393860; x=1304603460; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=mLN8YjXKoTsmdriLg7gN1Te9u/NqXoPw9J8AbF+B1F0=; b=IZoxgAPrLS8jdrnPZrE6uQ5BWE58lEB7oA/rkYjmWNVI/lgMkvOEFbBK qCqMw0cNNYmiYUF7GPeIUiC2pqi0/2LXV52Se6vyS5lPsa07/V6WNt3FT Pf0/igbbz3fGr6x/qNPMQeRUo3DJnlNeVzFD4PILEfi2lGoy0i7YM0FVj Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwAAP00sE2Q/khMgWdsb2JhbACXQI4HFAEBFiYlqCCcWoIig1QEhXKMRQ X-IronPort-AV: E=Sophos;i="4.64,251,1301875200"; d="scan'208";a="84591744" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 21 Apr 2011 13:50:59 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3LDoweN019868; Thu, 21 Apr 2011 13:50:59 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Apr 2011 19:20:58 +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, 21 Apr 2011 19:20:57 +0530 Message-ID: In-Reply-To: <1D062974A4845E4D8A343C6538049202054256F5@XMB-BGL-414.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Last Call:(Use CasesandRequirements forSIP-based MediaRecording (SIPREC)) toInformational RFC Thread-Index: Acv0WYBeRuGjGNBtTZSHeqn78QP5xwGEv6YwAAlHtwAAAvtH0AABcMXAAAdJn6AAAIZ7cAAHjozgABTz8IABOK4eoAAEuXiw References: <20110406125020.17538.70016.idtracker@localhost><1D062974A4845E4D8A343C65380492020533BB70@XMB-BGL-414.cisco.com><07465C1D981ABC41A344374066AE1A2C38AB73D00B@TLVMBX01.nice.com><07465C1D981ABC41A344374066AE1A2C38AB73D110@TLVMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD06009D00@XMB-BGL-417.cisco.com><1D062974A4845E4D8A343C65380492020533BD38@XMB-BGL-414.cisco.com> <1D062974A4845E4D8A343C6538049202054256F5@XMB-BGL-414.cisco.com> From: "Parthasarathi R (partr)" To: "Muthu ArulMozhi Perumal (mperumal)" , "Elwell, John" , "Ram Mohan R (rmohanr)" , "Leon Portman" , X-OriginalArrivalTime: 21 Apr 2011 13:50:58.0124 (UTC) FILETIME=[246738C0:01CC002B] Cc: siprec@ietf.org Subject: Re: [siprec] Last Call:(Use CasesandRequirements forSIP-based MediaRecording (SIPREC)) toInformational RFC X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 21 Apr 2011 13:51:03 -0000 Muthu/John, I will prefer to have "a" and "b" as separate requirement as "a" is related to RTP & its model, needs more discussion whereas "b" will be related to SIPREC metadata model which will be addressed by the current mechanism of start/stop time of media stream block. REQ-022: The mechanism MUST provide means for facilitating synchronization of the recorded media streams and metadata. REQ-xxx: The mechanism MUST provide means for facilitating synchronization among the recorded media streams Apart from this, I'm interested to know whether John's Req-023 requirement in the below mail will be solved by the current proposed REQ-xxx.=20 Thanks Partha=20 -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Muthu ArulMozhi Perumal (mperumal) Sent: Thursday, April 21, 2011 5:15 PM To: Elwell, John; Ram Mohan R (rmohanr); Leon Portman; ietf@ietf.org Cc: siprec@ietf.org Subject: Re: [siprec] Last Call:(Use CasesandRequirements forSIP-based MediaRecording (SIPREC)) toInformational RFC +1 I would suggest a small change to REQ-022 that John has drafted below to make it more explicit: =20 REQ-022 The mechanism MUST provide means for facilitating the following either at storage or at playback: a. Synchronization among the recorded media streams and b. Synchronization of the recorded media streams and metadata. Muthu |-----Original Message----- |From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] |Sent: Friday, April 15, 2011 11:53 AM |To: Muthu ArulMozhi Perumal (mperumal); Ram Mohan R (rmohanr); Leon Portman; ietf@ietf.org |Cc: siprec@ietf.org |Subject: RE: [siprec] Last Call: (Use CasesandRequirements for SIP-based |MediaRecording (SIPREC)) toInformational RFC | |So perhaps if we replace REQ-022 and REQ-023 with the requirement that Muthu has proposed and one |further requirement, e.g.: | |"REQ-022 The mechanism MUST provide means for facilitating synchronization of the |recorded media streams and metadata either at storage or at playback. | |REQ-023 The mechanism MUST provide means for relating recordings to wall clock time." | |John (as individual) | |> -----Original Message----- |> From: Muthu ArulMozhi Perumal (mperumal) [mailto:mperumal@cisco.com] |> Sent: 14 April 2011 21:42 |> To: Ram Mohan R (rmohanr); Leon Portman; Elwell, John; ietf@ietf.org |> Cc: siprec@ietf.org |> Subject: RE: [siprec] Last Call: |> (Use Cases andRequirements for=20 |> SIP-based MediaRecording (SIPREC)) toInformational RFC |> |> I agree with John that these seem more like part of a solution rather |> than actual requirements. In addition, sending the wallclock time at=20 |> media start/end alone may not suffice for achieving inter-media=20 |> synchronization and playback, instead we may need to send the=20 |> wallclock time periodically, like RTCP. For e.g, if there is a codec=20 |> renegotiation in CS the RTP timestamp can restart from a random=20 |> value. If silence suppression is enabled there would be gaps in the=20 |> RTP timestamp. |> |> These are things that need to be discussed as part of the solution -- |> the requirement itself should be generic enough, like what I=20 |> described. |> REQ-022 and REQ-023 we have doesn't seem to clearly indicate the=20 |> purpose. |> |> Muthu |> |> |-----Original Message----- |> |From: Ram Mohan R (rmohanr) |> |Sent: Thursday, April 14, 2011 10:13 PM |> |To: Leon Portman; Elwell, John; Muthu ArulMozhi Perumal (mperumal); |> ietf@ietf.org |> |Cc: siprec@ietf.org |> |Subject: RE: [siprec] Last Call: (Use |> Cases andRequirements for SIP- |> |based MediaRecording (SIPREC)) toInformational RFC |> | |> |We already have attributes Start-Time / End-time in Media Stream |> block. This is for the same purpose |> |to indicate the wall clock time for start/end of media. |> | |> |Ram |> | |> |> -----Original Message----- |> |> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 |> |> Behalf Of Leon Portman |> |> Sent: Thursday, April 14, 2011 9:57 PM |> |> To: Elwell, John; Muthu ArulMozhi Perumal (mperumal); ietf@ietf.org |> |> Cc: siprec@ietf.org |> |> Subject: Re: [siprec] Last Call: (Use |> |> Cases andRequirements for SIP-based MediaRecording (SIPREC))=20 |> |> toInformational RFC |> |> |> |> I am not sure that having wall clock only for CS start is enough,=20 |> |> especially for partial metadata update. I will prefer to have on |> media |> |> level |> |> |> |> Leon |> |> |> |> -----Original Message----- |> |> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] |> |> Sent: Thursday, April 14, 2011 3:58 PM |> |> To: Leon Portman; Muthu ArulMozhi Perumal (mperumal); ietf@ietf.org |> |> Cc: siprec@ietf.org |> |> Subject: RE: [siprec] Last Call: |> (Use |> |> Cases andRequirements for SIP-based Media Recording (SIPREC))=20 |> |> toInformational RFC |> |> |> |> Understood, but if we have wall clock time for the start of a CS,=20 |> |> wouldn't that be sufficient? The new requirement would cover=20 |> |> synchronization of all media start/stops relative to that time. |> |> |> |> John (as individual) |> |> |> |> |> |> > -----Original Message----- |> |> > From: Leon Portman [mailto:Leon.Portman@nice.com] |> |> > Sent: 14 April 2011 13:19 |> |> > To: Elwell, John; Muthu ArulMozhi Perumal (mperumal); |> ietf@ietf.org |> |> > Cc: siprec@ietf.org |> |> > Subject: RE: [siprec] Last Call: |> |> > (Use Cases andRequirements for=20 |> |> > SIP-based Media Recording (SIPREC)) toInformational RFC |> |> > |> |> > Actually REQ-022 and REQ-023 describing not only requirement to=20 |> |> > synchronize between different media streams but more importantly |> |> > ability to relate them to real world (wall) clock. It is not only |> |> > important to playback them correctly but also to know when it was |> |> > said. |> |> > One example is continue trading after closing hour (even for one |> |> > second is not allowed) |> |> > |> |> > And if these media are synchronized to wall clock then they are |> also |> |> > synchronized between them thus I am not sure if we need this=20 |> |> > additional requirement. |> |> > |> |> > Thanks |> |> > |> |> > Leon |> |> > |> |> > -----Original Message----- |> |> > From: siprec-bounces@ietf.org |> |> > [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John |> |> > Sent: Thursday, April 14, 2011 1:54 PM |> |> > To: Muthu ArulMozhi Perumal (mperumal); ietf@ietf.org |> |> > Cc: siprec@ietf.org |> |> > Subject: Re: [siprec] Last Call: |> |> > (Use Cases andRequirements for=20 |> |> > SIP-based Media Recording (SIPREC)) toInformational RFC |> |> > |> |> > |> |> > |> |> > |> |> > > -----Original Message----- |> |> > > From: siprec-bounces@ietf.org |> |> > > [mailto:siprec-bounces@ietf.org] On Behalf Of Muthu |> |> > ArulMozhi Perumal |> |> > > (mperumal) |> |> > > Sent: 14 April 2011 07:34 |> |> > > To: ietf@ietf.org |> |> > > Cc: siprec@ietf.org |> |> > > Subject: Re: [siprec] Last Call: |> |> > > (Use Cases andRequirements for=20 |> |> > > SIP-based Media Recording (SIPREC)) toInformational RFC |> |> > > |> |> > > I've one major comment. It draft discusses synchronization |> |> > between the |> |> > > recorded media streams and synchronized playback, which |> |> > seem important |> |> > > for certain applications: |> |> > > |> |> > > |> |> > > Some applications require the recording of more than one |> |> > media stream, |> |> > > possibly of different types. Media are synchronized, either |> |> > at storage |> |> > > or at playback. |> |> > > |> |> > > |> |> > > However, in the requirements section it doesn't seem |> REQ-022 and |> |> > > REQ-023 are all that are need and sufficient to |> achieve this with |> |> > > needed precision. So, I would suggest adding another |> requirement |> as |> |> > > follows: |> |> > > The mechanism MUST provide means for facilitating |> |> > synchronization of |> |> > > the recorded media streams and metadata either at storage or at |> |> > > playback. |> |> > > This includes, but not limited to, the information |> needed as per |> |> > > REQ-022 and REQ-023. |> |> > [JRE] This seems a reasonable addition. I wonder if the new=20 |> |> > requirement (first sentence only) is sufficient as a |> |> > **replacement** for REQ-022 and REQ-023. On reading REQ-022 and |> |> > REQ-023 again, it is not so clear what their purpose |> was, and they |> |> > seem to be more like a solution than a requirement. |> |> > One purpose would certainly be that covered by Muthu's new=20 |> |> > requirement. Was there any other purpose? |> |> > |> |> > John |> |> > |> |> > > |> |> > > A nitpick: |> |> > > Use Case 8 |> |> > > In cases where calls inside or between branches must |> be recorded, |> a |> |> > > centralized recording system in data centers together with |> |> > telephony |> |> > > infrastructure (e.g. PBX) me deployed. |> |> > > |> |> > > s/me/may be |> |> > > |> |> > > Muthu |> |> > > |> |> > > |-----Original Message----- |> |> > > |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] |> On |> |> > > Behalf Of The IESG |> |> > > |Sent: Wednesday, April 06, 2011 6:20 PM |> |> > > |To: IETF-Announce |> |> > > |Cc: siprec@ietf.org |> |> > > |Subject: [siprec] Last Call: |> |> > > (Use Cases |> |> > > andRequirements for SIP-based |> |> > > |Media Recording (SIPREC)) toInformational RFC |> |> > > | |> |> > > | |> |> > > |The IESG has received a request from the SIP Recording WG |> |> > (siprec) to |> |> > > |consider the following document: |> |> > > |- 'Use Cases and Requirements for SIP-based Media |> |> > Recording (SIPREC)' |> |> > > | as an Informational RFC |> |> > > | |> |> > > |The IESG plans to make a decision in the next few weeks, |> |> > and solicits |> |> > > |final comments on this action. Please send substantive |> |> > > comments to the |> |> > > |ietf@ietf.org mailing lists by 2011-04-20. Exceptionally, |> |> > > comments may |> |> > > be |> |> > > |sent to iesg@ietf.org instead. In either case, please |> retain the |> |> > > |beginning of the Subject line to allow automated sorting. |> |> > > | |> |> > > |The file can be obtained via |> |> > > |http://datatracker.ietf.org/doc/draft-ietf-siprec-req/ |> |> > > | |> |> > > |IESG discussion can be tracked via=20 |> |> > > |http://datatracker.ietf.org/doc/draft-ietf-siprec-req/ |> |> > > | |> |> > > | |> |> > > | |> |> > > |No IPR declarations have been submitted directly on this I-D. |> |> > > |_______________________________________________ |> |> > > |siprec mailing list |> |> > > |siprec@ietf.org |> |> > > |https://www.ietf.org/mailman/listinfo/siprec |> |> > > _______________________________________________ |> |> > > siprec mailing list |> |> > > siprec@ietf.org |> |> > > https://www.ietf.org/mailman/listinfo/siprec |> |> > > |> |> > _______________________________________________ |> |> > siprec mailing list |> |> > siprec@ietf.org |> |> > https://www.ietf.org/mailman/listinfo/siprec |> |> > |> |> _______________________________________________ |> |> siprec mailing list |> |> siprec@ietf.org |> |> https://www.ietf.org/mailman/listinfo/siprec |> _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From Leon.Portman@nice.com Thu Apr 21 06:54:08 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 3F4F3E076F; Thu, 21 Apr 2011 06:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IKsdFUxl7MmJ; Thu, 21 Apr 2011 06:54:06 -0700 (PDT) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfc.amsl.com (Postfix) with ESMTP id 3C091E077A; Thu, 21 Apr 2011 06:54:06 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Thu, 21 Apr 2011 16:54:04 +0300 From: Leon Portman To: "Parthasarathi R (partr)" , "Muthu ArulMozhi Perumal (mperumal)" , "Elwell, John" , "Ram Mohan R (rmohanr)" , "ietf@ietf.org" Date: Thu, 21 Apr 2011 16:54:03 +0300 Thread-Topic: [siprec] Last Call:(Use CasesandRequirements forSIP-based MediaRecording (SIPREC)) toInformational RFC Thread-Index: Acv0WYBeRuGjGNBtTZSHeqn78QP5xwGEv6YwAAlHtwAAAvtH0AABcMXAAAdJn6AAAIZ7cAAHjozgABTz8IABOK4eoAAEuXiwAABUl5A= Message-ID: <07465C1D981ABC41A344374066AE1A2C38AB73DDF5@TLVMBX01.nice.com> References: <20110406125020.17538.70016.idtracker@localhost><1D062974A4845E4D8A343C65380492020533BB70@XMB-BGL-414.cisco.com><07465C1D981ABC41A344374066AE1A2C38AB73D00B@TLVMBX01.nice.com><07465C1D981ABC41A344374066AE1A2C38AB73D110@TLVMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD06009D00@XMB-BGL-417.cisco.com><1D062974A4845E4D8A343C65380492020533BD38@XMB-BGL-414.cisco.com> <1D062974A4845E4D8A343C6538049202054256F5@XMB-BGL-414.cisco.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] Last Call:(Use CasesandRequirements forSIP-based MediaRecording (SIPREC)) toInformational RFC X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 21 Apr 2011 13:54:08 -0000 I agree, we should have dedicated wall clock requirement Leon -----Original Message----- From: Parthasarathi R (partr) [mailto:partr@cisco.com]=20 Sent: Thursday, April 21, 2011 4:51 PM To: Muthu ArulMozhi Perumal (mperumal); Elwell, John; Ram Mohan R (rmohanr)= ; Leon Portman; ietf@ietf.org Cc: siprec@ietf.org Subject: RE: [siprec] Last Call:(Use Casesand= Requirements forSIP-based MediaRecording (SIPREC)) toInformational RFC Muthu/John, I will prefer to have "a" and "b" as separate requirement as "a" is related= to RTP & its model, needs more discussion whereas "b" will be related to S= IPREC metadata model which will be addressed by the current mechanism of st= art/stop time of media stream block. REQ-022: The mechanism MUST provide means for facilitating synchronization = of the recorded media streams and metadata. REQ-xxx: The mechanism MUST provide means for facilitating synchronization = among the recorded media streams Apart from this, I'm interested to know whether John's Req-023 requirement = in the below mail will be solved by the current proposed REQ-xxx.=20 Thanks Partha=20 -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Muthu ArulMozhi Perumal (mperumal) Sent: Thursday, April 21, 2011 5:15 PM To: Elwell, John; Ram Mohan R (rmohanr); Leon Portman; ietf@ietf.org Cc: siprec@ietf.org Subject: Re: [siprec] Last Call:(Use CasesandRequirements forSIP-based MediaRecording (SIPREC)) toInformational = RFC +1 I would suggest a small change to REQ-022 that John has drafted below to ma= ke it more explicit: =20 REQ-022 The mechanism MUST provide means for facilitating the following eit= her at storage or at playback: a. Synchronization among the recorded media streams and b. Synchronization of the recorded media streams and metadata. Muthu |-----Original Message----- |From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] |Sent: Friday, April 15, 2011 11:53 AM |To: Muthu ArulMozhi Perumal (mperumal); Ram Mohan R (rmohanr); Leon Portman; ietf@ietf.org |Cc: siprec@ietf.org |Subject: RE: [siprec] Last Call: (Use CasesandRequirements for SIP-based |MediaRecording (SIPREC)) toInformational RFC | |So perhaps if we replace REQ-022 and REQ-023 with the requirement that Muthu has proposed and one |further requirement, e.g.: | |"REQ-022 The mechanism MUST provide means for facilitating synchronization of the |recorded media streams and metadata either at storage or at playback. | |REQ-023 The mechanism MUST provide means for relating recordings to wall clock time." | |John (as individual) | |> -----Original Message----- |> From: Muthu ArulMozhi Perumal (mperumal) [mailto:mperumal@cisco.com] |> Sent: 14 April 2011 21:42 |> To: Ram Mohan R (rmohanr); Leon Portman; Elwell, John; ietf@ietf.org |> Cc: siprec@ietf.org |> Subject: RE: [siprec] Last Call: |> (Use Cases andRequirements for=20 |> SIP-based MediaRecording (SIPREC)) toInformational RFC |> |> I agree with John that these seem more like part of a solution rather |> than actual requirements. In addition, sending the wallclock time at=20 |> media start/end alone may not suffice for achieving inter-media=20 |> synchronization and playback, instead we may need to send the=20 |> wallclock time periodically, like RTCP. For e.g, if there is a codec=20 |> renegotiation in CS the RTP timestamp can restart from a random=20 |> value. If silence suppression is enabled there would be gaps in the=20 |> RTP timestamp. |> |> These are things that need to be discussed as part of the solution -- |> the requirement itself should be generic enough, like what I=20 |> described. |> REQ-022 and REQ-023 we have doesn't seem to clearly indicate the=20 |> purpose. |> |> Muthu |> |> |-----Original Message----- |> |From: Ram Mohan R (rmohanr) |> |Sent: Thursday, April 14, 2011 10:13 PM |> |To: Leon Portman; Elwell, John; Muthu ArulMozhi Perumal (mperumal); |> ietf@ietf.org |> |Cc: siprec@ietf.org |> |Subject: RE: [siprec] Last Call: (Use |> Cases andRequirements for SIP- |> |based MediaRecording (SIPREC)) toInformational RFC |> | |> |We already have attributes Start-Time / End-time in Media Stream |> block. This is for the same purpose |> |to indicate the wall clock time for start/end of media. |> | |> |Ram |> | |> |> -----Original Message----- |> |> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 |> |> Behalf Of Leon Portman |> |> Sent: Thursday, April 14, 2011 9:57 PM |> |> To: Elwell, John; Muthu ArulMozhi Perumal (mperumal); ietf@ietf.org |> |> Cc: siprec@ietf.org |> |> Subject: Re: [siprec] Last Call: (Use |> |> Cases andRequirements for SIP-based MediaRecording (SIPREC))=20 |> |> toInformational RFC |> |> |> |> I am not sure that having wall clock only for CS start is enough,=20 |> |> especially for partial metadata update. I will prefer to have on |> media |> |> level |> |> |> |> Leon |> |> |> |> -----Original Message----- |> |> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] |> |> Sent: Thursday, April 14, 2011 3:58 PM |> |> To: Leon Portman; Muthu ArulMozhi Perumal (mperumal); ietf@ietf.org |> |> Cc: siprec@ietf.org |> |> Subject: RE: [siprec] Last Call: |> (Use |> |> Cases andRequirements for SIP-based Media Recording (SIPREC))=20 |> |> toInformational RFC |> |> |> |> Understood, but if we have wall clock time for the start of a CS,=20 |> |> wouldn't that be sufficient? The new requirement would cover=20 |> |> synchronization of all media start/stops relative to that time. |> |> |> |> John (as individual) |> |> |> |> |> |> > -----Original Message----- |> |> > From: Leon Portman [mailto:Leon.Portman@nice.com] |> |> > Sent: 14 April 2011 13:19 |> |> > To: Elwell, John; Muthu ArulMozhi Perumal (mperumal); |> ietf@ietf.org |> |> > Cc: siprec@ietf.org |> |> > Subject: RE: [siprec] Last Call: |> |> > (Use Cases andRequirements for=20 |> |> > SIP-based Media Recording (SIPREC)) toInformational RFC |> |> > |> |> > Actually REQ-022 and REQ-023 describing not only requirement to=20 |> |> > synchronize between different media streams but more importantly |> |> > ability to relate them to real world (wall) clock. It is not only |> |> > important to playback them correctly but also to know when it was |> |> > said. |> |> > One example is continue trading after closing hour (even for one |> |> > second is not allowed) |> |> > |> |> > And if these media are synchronized to wall clock then they are |> also |> |> > synchronized between them thus I am not sure if we need this=20 |> |> > additional requirement. |> |> > |> |> > Thanks |> |> > |> |> > Leon |> |> > |> |> > -----Original Message----- |> |> > From: siprec-bounces@ietf.org |> |> > [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John |> |> > Sent: Thursday, April 14, 2011 1:54 PM |> |> > To: Muthu ArulMozhi Perumal (mperumal); ietf@ietf.org |> |> > Cc: siprec@ietf.org |> |> > Subject: Re: [siprec] Last Call: |> |> > (Use Cases andRequirements for=20 |> |> > SIP-based Media Recording (SIPREC)) toInformational RFC |> |> > |> |> > |> |> > |> |> > |> |> > > -----Original Message----- |> |> > > From: siprec-bounces@ietf.org |> |> > > [mailto:siprec-bounces@ietf.org] On Behalf Of Muthu |> |> > ArulMozhi Perumal |> |> > > (mperumal) |> |> > > Sent: 14 April 2011 07:34 |> |> > > To: ietf@ietf.org |> |> > > Cc: siprec@ietf.org |> |> > > Subject: Re: [siprec] Last Call: |> |> > > (Use Cases andRequirements for=20 |> |> > > SIP-based Media Recording (SIPREC)) toInformational RFC |> |> > > |> |> > > I've one major comment. It draft discusses synchronization |> |> > between the |> |> > > recorded media streams and synchronized playback, which |> |> > seem important |> |> > > for certain applications: |> |> > > |> |> > > |> |> > > Some applications require the recording of more than one |> |> > media stream, |> |> > > possibly of different types. Media are synchronized, either |> |> > at storage |> |> > > or at playback. |> |> > > |> |> > > |> |> > > However, in the requirements section it doesn't seem |> REQ-022 and |> |> > > REQ-023 are all that are need and sufficient to |> achieve this with |> |> > > needed precision. So, I would suggest adding another |> requirement |> as |> |> > > follows: |> |> > > The mechanism MUST provide means for facilitating |> |> > synchronization of |> |> > > the recorded media streams and metadata either at storage or at |> |> > > playback. |> |> > > This includes, but not limited to, the information |> needed as per |> |> > > REQ-022 and REQ-023. |> |> > [JRE] This seems a reasonable addition. I wonder if the new=20 |> |> > requirement (first sentence only) is sufficient as a |> |> > **replacement** for REQ-022 and REQ-023. On reading REQ-022 and |> |> > REQ-023 again, it is not so clear what their purpose |> was, and they |> |> > seem to be more like a solution than a requirement. |> |> > One purpose would certainly be that covered by Muthu's new=20 |> |> > requirement. Was there any other purpose? |> |> > |> |> > John |> |> > |> |> > > |> |> > > A nitpick: |> |> > > Use Case 8 |> |> > > In cases where calls inside or between branches must |> be recorded, |> a |> |> > > centralized recording system in data centers together with |> |> > telephony |> |> > > infrastructure (e.g. PBX) me deployed. |> |> > > |> |> > > s/me/may be |> |> > > |> |> > > Muthu |> |> > > |> |> > > |-----Original Message----- |> |> > > |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] |> On |> |> > > Behalf Of The IESG |> |> > > |Sent: Wednesday, April 06, 2011 6:20 PM |> |> > > |To: IETF-Announce |> |> > > |Cc: siprec@ietf.org |> |> > > |Subject: [siprec] Last Call: |> |> > > (Use Cases |> |> > > andRequirements for SIP-based |> |> > > |Media Recording (SIPREC)) toInformational RFC |> |> > > | |> |> > > | |> |> > > |The IESG has received a request from the SIP Recording WG |> |> > (siprec) to |> |> > > |consider the following document: |> |> > > |- 'Use Cases and Requirements for SIP-based Media |> |> > Recording (SIPREC)' |> |> > > | as an Informational RFC |> |> > > | |> |> > > |The IESG plans to make a decision in the next few weeks, |> |> > and solicits |> |> > > |final comments on this action. Please send substantive |> |> > > comments to the |> |> > > |ietf@ietf.org mailing lists by 2011-04-20. Exceptionally, |> |> > > comments may |> |> > > be |> |> > > |sent to iesg@ietf.org instead. In either case, please |> retain the |> |> > > |beginning of the Subject line to allow automated sorting. |> |> > > | |> |> > > |The file can be obtained via |> |> > > |http://datatracker.ietf.org/doc/draft-ietf-siprec-req/ |> |> > > | |> |> > > |IESG discussion can be tracked via=20 |> |> > > |http://datatracker.ietf.org/doc/draft-ietf-siprec-req/ |> |> > > | |> |> > > | |> |> > > | |> |> > > |No IPR declarations have been submitted directly on this I-D. |> |> > > |_______________________________________________ |> |> > > |siprec mailing 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 Thu Apr 21 08:42:06 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 18878E07EA for ; Thu, 21 Apr 2011 08:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.133 X-Spam-Level: X-Spam-Status: No, score=-105.133 tagged_above=-999 required=5 tests=[AWL=1.466, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sORJ3reVwt0I for ; Thu, 21 Apr 2011 08:42:04 -0700 (PDT) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfc.amsl.com (Postfix) with SMTP id 5EA98E07DD for ; Thu, 21 Apr 2011 08:42:04 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1303400519!37987728!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 24740 invoked from network); 21 Apr 2011 15:41:59 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-2.tower-27.messagelabs.com with SMTP; 21 Apr 2011 15:41:59 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 3F6A11EB83E1; Thu, 21 Apr 2011 17:42:03 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 21 Apr 2011 17:42:03 +0200 From: "Elwell, John" To: "Parthasarathi R (partr)" , "Ram Mohan R (rmohanr)" , "Paul Kyzivat (pkyzivat)" Date: Thu, 21 Apr 2011 17:42:01 +0200 Thread-Topic: Does MS have life outside a particular CS? (was RE: [siprec] comments on draft-ram-siprec-metadata-04) Thread-Index: Acv+pbws7MwochNUSB2j8RZ3ismj6AAAQrXwACiVZgAABfyA0AACLm6QAASWOmAAG+JhEAANxV4AAAViIkA= Message-ID: References: <21866C7FE177A4449B9136B5B24B1B130BC011290A@EXMBXCLUS01.citservers.local><21866C7FE177A4449B9136B5B24B1B130BC011294A@EXMBXCLUS01.citservers.local><35BCE99A477D6A4986FB2216D8CF2CFD05DD8C0C@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD05EF92EF@XMB-BGL-417.cisco.com> <4D9CBD8C.4010901@cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD06133966@XMB-BGL-417.cisco.com> <4DAD8A5F.4040506@cisco.com> <4DADA8E6.9010006@cisco.com> <35BCE99A477D 6A4986 F B 2216D8CF 2CFD06133A56@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD06133DD4@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD06133E6B@XMB-BGL-417.cisco.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] Does MS have life outside a particular CS? (was RE: comments on draft-ram-siprec-metadata-04) X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 21 Apr 2011 15:42:06 -0000 Partha,=20 > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com]=20 > Sent: 21 April 2011 14:25 > To: Elwell, John; Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > Cc: siprec@ietf.org > Subject: RE: Does MS have life outside a particular CS? (was=20 > RE: [siprec] comments on draft-ram-siprec-metadata-04) >=20 > John, >=20 > I could think of one usecase wherein MS is outside CS but=20 > within single > RS. The usecase is multiple CS within single RS and MS. The=20 > usecase is > as follows: >=20 > B2BUA acts as SRC. A, B, C are participants within single B2BUA. A > creates single RS for a CSG. >=20 > 1) A calls B through B2BUA. B2BUA creates RS towards SRS with=20 > CSG1, CS1, > MS1 (A's media stream), MS2 (B's media stream), Participant1 as A & > Participant2 as B. [JRE] Why two media streams? Why not a single MS, with both A and B sending= and receiving that MS? > 2) B connects with C through B2BUA > 3) B transfer the call of A & B to C using REFER, B2BUA converts REFER > to RE-INVITE towards A & C and A & C are connected. B2BUA updates RS > with CS2, Participant1 as A & participant2 as C, MS1(A's=20 > media stream), > MS2(C's media stream). [JRE] I would have expected, from my understanding of the metadata model, t= hat the CS2 would have a new MS, with both A and B sending and receiving th= at new MS. > There is no update on RS1, CSG1, MS1, MS2. MS2 > will become MS2 with the new association and in terms of=20 > format, it will > associate with tag. >=20 > In the above scenario, MS have life outside CS but it is=20 > within RS.=20 [JRE] I can see how it COULD work like that, but it is not intuitive. To me= , a new CS means the existing media stream stops and a new media stream is = created. > The > unique id shall be within RS scope as mentioned in IETF-80=20 > meeting. But > in another situation, MS is outside the scope of RS but within CS and > the usecase is Multiple RS for single CS, details are as follows: >=20 > A, B are pariticipants. A acts as SRC which tear down RS whenever hold > happens & creates new RS when resume happens. >=20 > 1) A calls B. A creates RS1 towards SRS with CS1, MS1 (A's media > stream), MS2 (B's Media stream),Participant1 as A & Participant2 as B. [JRE] Again, I would model this as a single MS, to which both A and B contr= ibute. > 2) A put B on hold. A tear down RS1. > 3) A resume B. A creates RS2 towards SRS with CS1, MS1 (A's media > stream), MS2 (B's Media stream),Participant1 as A & Participant2 as B >=20 > Here MS1 & MS2 needs to be same across RS to group media streams > correctly. Please let me know your opinion here. [JRE] Although I disagree that we have two Media Streams here, I do agree t= hat the single Media Stream could be considered to survive the hold/resume,= and hence survive from RS1 to RS2. But the MS is within the context of the= same CS (CS1), and therefore this is outside the scope of this particular = thread, which is asking whether an MS can have a life outside a particular = CS. In this case the MS continues to be associated with the CS, so I don't = have a problem with that. So you have failed to convince me that an MS needs to have a life outside a= CS. John (as individual) >=20 > Having said that MS have life outside a particular CS, I=20 > create separate > thread within unique how it shall be handled.=20 >=20 > Thanks > Partha >=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > Sent: Thursday, April 21, 2011 12:01 PM > To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > Cc: Parthasarathi R (partr); siprec@ietf.org > Subject: Does MS have life outside a particular CS? (was RE: [siprec] > comments on draft-ram-siprec-metadata-04) >=20 > =20 >=20 > > -----Original Message----- > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > Sent: 20 April 2011 18:08 > > To: Elwell, John; Paul Kyzivat (pkyzivat) > > Cc: Parthasarathi R (partr); siprec@ietf.org > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > >=20 > > Hi John, > >=20 > > Please see inline [RAM] > >=20 > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > Sent: Wednesday, April 20, 2011 8:19 PM > > > To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > > Cc: Parthasarathi R (partr); siprec@ietf.org > > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > >=20 > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > > > Sent: 20 April 2011 14:52 > > > > To: Elwell, John; Paul Kyzivat (pkyzivat) > > > > Cc: Parthasarathi R (partr); siprec@ietf.org > > > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > > > > > > > John, > > > > > > > > I agree with you that normal cases RS will remain at=20 > least for the >=20 > > > > duration of CS. However it is common to have use cases where > > > recording > > > > is done for first few mins of a CS and then stopped, > > re-started at a > > > > later point (e.g Recording of a company meeting where=20 > you may want > > to > > > > record only portions of meeting). > > > > > > > > In any case, the point I like to high light here is, MS > > block could > > > be > > > > common across RS and even across CS[ due to consult > > transfer e.t.c]. > > > > These use cases indicate the need to have a unique ID=20 > for MS block >=20 > > > > (similar to the UUID that we have defined in format) as=20 > we cannot=20 > > > > depend on neither CS ID or RS ID. > > > [JRE] I am having a hard time understanding the concept=20 > of a single=20 > > > Media Stream that survives across multiple CSs. For=20 > example, in the=20 > > > case of transfer, I would have thought new Media Streams would be=20 > > > created. > >=20 > > [RAM] > > Here is my thoughts.=20 > > 1) There can be multiple RS per CS > > RS1 --- CS1--MS1 > > RS2----CS1--MS1 > > Examples are partial recording of CS (like recording parts=20 > of meeting, >=20 > > redundant recording where there are multiple SRCs recording=20 > the same=20 > > CS) > [JRE] Agreed. In this case MS1 is local to CS1. >=20 > >=20 > > 2) There can be same Media Stream across multiple CS.=20 > > RS1--- CS1--- MS1 > > RS2--CS2--MS1 > > Examples are Multicast MoH played to multiple end points who are=20 > > potentially part of disjoint CSs where each CS is recorded=20 > as part of=20 > > separate RS. > >=20 > > Of course the above is arguable where the stream is same or=20 > different. > > My view is since the UA (that supplies the Multicast MoH) and its=20 > > media are same across all CS, I think it can be represented=20 > as same MS >=20 > > block. > [JRE] I would argue these are different MSs. I agree that a=20 > medium such > as music on hold might be sent, in synch, to multiple participants in > multiple CSs. In that particular situation there might be some > efficiency saving by calling it the same MS. However, I would suggest > (although this is not my field of expertise) it would make life a lot > harder for the SRS and its database. I would have expected to want to > record a complete CS (all its participants and media streams) as a > complete recording, which could be deleted, copied, and so on without > having to go looking for other objects that complete that=20 > recording and > are shared with other recordings. For example, if you delete a > recording, you would want to delete all its MSs, but not those used by > other recordings, although you would need a garbage=20 > collection mechanism > to delete an MS recording when it is no longer used by any CS > recordings. Rather ugly. Making a MS local to a CS would simplify all > this. >=20 > >=20 > >=20 > > However it is still possible to treat each as separate=20 > stream in the=20 > > model, in which case the information that it is the same MS=20 > played by=20 > > a UA to different CS will be lost. I don't know if there is an=20 > > interest to capture this level of detail and if it is of any use to=20 > > SRS. > [JRE] I assume what you are saying here is not that=20 > information will be > lost, but that you will be unable to tell, without doing a comparison, > whether two different MSs played to participants in two different CSs > are identical or not for the particular time span that is common. I > don't see where such a requirement would come from. >=20 > John (as individual) >=20 > = From john.elwell@siemens-enterprise.com Thu Apr 21 08:44:50 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 46540E07C5; Thu, 21 Apr 2011 08:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.152 X-Spam-Level: X-Spam-Status: No, score=-105.152 tagged_above=-999 required=5 tests=[AWL=1.447, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8bCcgogiWOUW; Thu, 21 Apr 2011 08:44:48 -0700 (PDT) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfc.amsl.com (Postfix) with SMTP id 14C1AE065C; Thu, 21 Apr 2011 08:44:47 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1303400685!20452180!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 22270 invoked from network); 21 Apr 2011 15:44:45 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-11.tower-27.messagelabs.com with SMTP; 21 Apr 2011 15:44:45 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 505241EB83F2; Thu, 21 Apr 2011 17:44:47 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 21 Apr 2011 17:44:47 +0200 From: "Elwell, John" To: Leon Portman , "Parthasarathi R (partr)" , "Muthu ArulMozhi Perumal (mperumal)" , "Ram Mohan R (rmohanr)" , "ietf@ietf.org" Date: Thu, 21 Apr 2011 17:44:46 +0200 Thread-Topic: [siprec] Last Call:(Use CasesandRequirements forSIP-based MediaRecording (SIPREC)) toInformational RFC Thread-Index: Acv0WYBeRuGjGNBtTZSHeqn78QP5xwGEv6YwAAlHtwAAAvtH0AABcMXAAAdJn6AAAIZ7cAAHjozgABTz8IABOK4eoAAEuXiwAABUl5AAA9OvcA== Message-ID: References: <20110406125020.17538.70016.idtracker@localhost><1D062974A4845E4D8A343C65380492020533BB70@XMB-BGL-414.cisco.com><07465C1D981ABC41A344374066AE1A2C38AB73D00B@TLVMBX01.nice.com><07465C1D981ABC41A344374066AE1A2C38AB73D110@TLVMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD06009D00@XMB-BGL-417.cisco.com><1D062974A4845E4D8A343C65380492020533BD38@XMB-BGL-414.cisco.com> <1D062974A4845E4D8A343C6538049202054256F5@XMB-BGL-414.cisco.com> <07465C1D981ABC41A344374066AE1A2C38AB73DDF5@TLVMBX01.nice.com> In-Reply-To: <07465C1D981ABC41A344374066AE1A2C38AB73DDF5@TLVMBX01.nice.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] Last Call:(Use CasesandRequirements forSIP-based MediaRecording (SIPREC)) toInformational RFC X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 21 Apr 2011 15:44:50 -0000 I like the separated REQ-022 and REQ-xxx. In accordance with previous discu= ssions, I think we need REQ-023 too. John (as individual) > -----Original Message----- > From: Leon Portman [mailto:Leon.Portman@nice.com]=20 > Sent: 21 April 2011 14:54 > To: Parthasarathi R (partr); Muthu ArulMozhi Perumal=20 > (mperumal); Elwell, John; Ram Mohan R (rmohanr); ietf@ietf.org > Cc: siprec@ietf.org > Subject: RE: [siprec] Last=20 > Call:(Use CasesandRequirements=20 > forSIP-based MediaRecording (SIPREC)) toInformational RFC >=20 > I agree, we should have dedicated wall clock requirement >=20 > Leon >=20 > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com]=20 > Sent: Thursday, April 21, 2011 4:51 PM > To: Muthu ArulMozhi Perumal (mperumal); Elwell, John; Ram=20 > Mohan R (rmohanr); Leon Portman; ietf@ietf.org > Cc: siprec@ietf.org > Subject: RE: [siprec] Last=20 > Call:(Use CasesandRequirements=20 > forSIP-based MediaRecording (SIPREC)) toInformational RFC >=20 > Muthu/John, >=20 > I will prefer to have "a" and "b" as separate requirement as=20 > "a" is related to RTP & its model, needs more discussion=20 > whereas "b" will be related to SIPREC metadata model which=20 > will be addressed by the current mechanism of start/stop time=20 > of media stream block. >=20 > REQ-022: The mechanism MUST provide means for facilitating=20 > synchronization of the recorded media streams and metadata. >=20 > REQ-xxx: The mechanism MUST provide means for facilitating=20 > synchronization among the recorded media streams >=20 > Apart from this, I'm interested to know whether John's=20 > Req-023 requirement in the below mail will be solved by the=20 > current proposed REQ-xxx.=20 >=20 > Thanks > Partha=20 >=20 > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Muthu ArulMozhi=20 > Perumal (mperumal) > Sent: Thursday, April 21, 2011 5:15 PM > To: Elwell, John; Ram Mohan R (rmohanr); Leon Portman; ietf@ietf.org > Cc: siprec@ietf.org > Subject: Re: [siprec] Last Call:(Use > CasesandRequirements forSIP-based MediaRecording (SIPREC))=20 > toInformational RFC >=20 > +1 >=20 > I would suggest a small change to REQ-022 that John has=20 > drafted below to make it more explicit: > =20 > REQ-022 The mechanism MUST provide means for facilitating the=20 > following either at storage or at playback: > a. Synchronization among the recorded media streams and b. > Synchronization of the recorded media streams and metadata. >=20 > Muthu >=20 > |-----Original Message----- > |From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > |Sent: Friday, April 15, 2011 11:53 AM > |To: Muthu ArulMozhi Perumal (mperumal); Ram Mohan R (rmohanr); Leon > Portman; ietf@ietf.org > |Cc: siprec@ietf.org > |Subject: RE: [siprec] Last Call: (Use > CasesandRequirements for SIP-based > |MediaRecording (SIPREC)) toInformational RFC > | > |So perhaps if we replace REQ-022 and REQ-023 with the=20 > requirement that > Muthu has proposed and one > |further requirement, e.g.: > | > |"REQ-022 The mechanism MUST provide means for facilitating > synchronization of the > |recorded media streams and metadata either at storage or at playback. > | > |REQ-023 The mechanism MUST provide means for relating recordings to > wall clock time." > | > |John (as individual) > | > |> -----Original Message----- > |> From: Muthu ArulMozhi Perumal (mperumal)=20 > [mailto:mperumal@cisco.com] > |> Sent: 14 April 2011 21:42 > |> To: Ram Mohan R (rmohanr); Leon Portman; Elwell, John;=20 > ietf@ietf.org > |> Cc: siprec@ietf.org > |> Subject: RE: [siprec] Last Call: > |> (Use Cases andRequirements for=20 > |> SIP-based MediaRecording (SIPREC)) toInformational RFC > |> > |> I agree with John that these seem more like part of a=20 > solution rather >=20 > |> than actual requirements. In addition, sending the=20 > wallclock time at=20 > |> media start/end alone may not suffice for achieving inter-media=20 > |> synchronization and playback, instead we may need to send the=20 > |> wallclock time periodically, like RTCP. For e.g, if there=20 > is a codec=20 > |> renegotiation in CS the RTP timestamp can restart from a random=20 > |> value. If silence suppression is enabled there would be=20 > gaps in the=20 > |> RTP timestamp. > |> > |> These are things that need to be discussed as part of the=20 > solution -- >=20 > |> the requirement itself should be generic enough, like what I=20 > |> described. > |> REQ-022 and REQ-023 we have doesn't seem to clearly indicate the=20 > |> purpose. > |> > |> Muthu > |> > |> |-----Original Message----- > |> |From: Ram Mohan R (rmohanr) > |> |Sent: Thursday, April 14, 2011 10:13 PM > |> |To: Leon Portman; Elwell, John; Muthu ArulMozhi Perumal=20 > (mperumal); > |> ietf@ietf.org > |> |Cc: siprec@ietf.org > |> |Subject: RE: [siprec] Last Call:=20 > (Use > |> Cases andRequirements for SIP- > |> |based MediaRecording (SIPREC)) toInformational RFC > |> | > |> |We already have attributes Start-Time / End-time in Media Stream > |> block. This is for the same purpose > |> |to indicate the wall clock time for start/end of media. > |> | > |> |Ram > |> | > |> |> -----Original Message----- > |> |> From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On=20 > |> |> Behalf Of Leon Portman > |> |> Sent: Thursday, April 14, 2011 9:57 PM > |> |> To: Elwell, John; Muthu ArulMozhi Perumal (mperumal); > ietf@ietf.org > |> |> Cc: siprec@ietf.org > |> |> Subject: Re: [siprec] Last Call: > (Use > |> |> Cases andRequirements for SIP-based MediaRecording (SIPREC))=20 > |> |> toInformational RFC > |> |> > |> |> I am not sure that having wall clock only for CS start=20 > is enough,=20 > |> |> especially for partial metadata update. I will prefer to have on > |> media > |> |> level > |> |> > |> |> Leon > |> |> > |> |> -----Original Message----- > |> |> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > |> |> Sent: Thursday, April 14, 2011 3:58 PM > |> |> To: Leon Portman; Muthu ArulMozhi Perumal (mperumal); > ietf@ietf.org > |> |> Cc: siprec@ietf.org > |> |> Subject: RE: [siprec] Last Call: > |> (Use > |> |> Cases andRequirements for SIP-based Media Recording (SIPREC))=20 > |> |> toInformational RFC > |> |> > |> |> Understood, but if we have wall clock time for the=20 > start of a CS,=20 > |> |> wouldn't that be sufficient? The new requirement would cover=20 > |> |> synchronization of all media start/stops relative to that time. > |> |> > |> |> John (as individual) > |> |> > |> |> > |> |> > -----Original Message----- > |> |> > From: Leon Portman [mailto:Leon.Portman@nice.com] > |> |> > Sent: 14 April 2011 13:19 > |> |> > To: Elwell, John; Muthu ArulMozhi Perumal (mperumal); > |> ietf@ietf.org > |> |> > Cc: siprec@ietf.org > |> |> > Subject: RE: [siprec] Last Call: > |> |> > (Use Cases andRequirements for=20 > |> |> > SIP-based Media Recording (SIPREC)) toInformational RFC > |> |> > > |> |> > Actually REQ-022 and REQ-023 describing not only=20 > requirement to=20 > |> |> > synchronize between different media streams but more=20 > importantly >=20 > |> |> > ability to relate them to real world (wall) clock. It is not > only > |> |> > important to playback them correctly but also to know when it > was > |> |> > said. > |> |> > One example is continue trading after closing hour=20 > (even for one >=20 > |> |> > second is not allowed) > |> |> > > |> |> > And if these media are synchronized to wall clock=20 > then they are > |> also > |> |> > synchronized between them thus I am not sure if we need this=20 > |> |> > additional requirement. > |> |> > > |> |> > Thanks > |> |> > > |> |> > Leon > |> |> > > |> |> > -----Original Message----- > |> |> > From: siprec-bounces@ietf.org > |> |> > [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > |> |> > Sent: Thursday, April 14, 2011 1:54 PM > |> |> > To: Muthu ArulMozhi Perumal (mperumal); ietf@ietf.org > |> |> > Cc: siprec@ietf.org > |> |> > Subject: Re: [siprec] Last Call: > |> |> > (Use Cases andRequirements for=20 > |> |> > SIP-based Media Recording (SIPREC)) toInformational RFC > |> |> > > |> |> > > |> |> > > |> |> > > |> |> > > -----Original Message----- > |> |> > > From: siprec-bounces@ietf.org > |> |> > > [mailto:siprec-bounces@ietf.org] On Behalf Of Muthu > |> |> > ArulMozhi Perumal > |> |> > > (mperumal) > |> |> > > Sent: 14 April 2011 07:34 > |> |> > > To: ietf@ietf.org > |> |> > > Cc: siprec@ietf.org > |> |> > > Subject: Re: [siprec] Last Call: > |> |> > > (Use Cases=20 > andRequirements for=20 > |> |> > > SIP-based Media Recording (SIPREC)) toInformational RFC > |> |> > > > |> |> > > I've one major comment. It draft discusses synchronization > |> |> > between the > |> |> > > recorded media streams and synchronized playback, which > |> |> > seem important > |> |> > > for certain applications: > |> |> > > > |> |> > > > |> |> > > Some applications require the recording of more than one > |> |> > media stream, > |> |> > > possibly of different types. Media are synchronized, either > |> |> > at storage > |> |> > > or at playback. > |> |> > > > |> |> > > > |> |> > > However, in the requirements section it doesn't seem > |> REQ-022 and > |> |> > > REQ-023 are all that are need and sufficient to > |> achieve this with > |> |> > > needed precision. So, I would suggest adding another > |> requirement > |> as > |> |> > > follows: > |> |> > > The mechanism MUST provide means for facilitating > |> |> > synchronization of > |> |> > > the recorded media streams and metadata either at storage or > at > |> |> > > playback. > |> |> > > This includes, but not limited to, the information > |> needed as per > |> |> > > REQ-022 and REQ-023. > |> |> > [JRE] This seems a reasonable addition. I wonder if the new=20 > |> |> > requirement (first sentence only) is sufficient as a > |> |> > **replacement** for REQ-022 and REQ-023. On reading=20 > REQ-022 and > |> |> > REQ-023 again, it is not so clear what their purpose > |> was, and they > |> |> > seem to be more like a solution than a requirement. > |> |> > One purpose would certainly be that covered by Muthu's new=20 > |> |> > requirement. Was there any other purpose? > |> |> > > |> |> > John > |> |> > > |> |> > > > |> |> > > A nitpick: > |> |> > > Use Case 8 > |> |> > > In cases where calls inside or between branches must > |> be recorded, > |> a > |> |> > > centralized recording system in data centers together with > |> |> > telephony > |> |> > > infrastructure (e.g. PBX) me deployed. > |> |> > > > |> |> > > s/me/may be > |> |> > > > |> |> > > Muthu > |> |> > > > |> |> > > |-----Original Message----- > |> |> > > |From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] > |> On > |> |> > > Behalf Of The IESG > |> |> > > |Sent: Wednesday, April 06, 2011 6:20 PM > |> |> > > |To: IETF-Announce > |> |> > > |Cc: siprec@ietf.org > |> |> > > |Subject: [siprec] Last Call: > |> |> > > (Use Cases > |> |> > > andRequirements for SIP-based > |> |> > > |Media Recording (SIPREC)) toInformational RFC > |> |> > > | > |> |> > > | > |> |> > > |The IESG has received a request from the SIP Recording WG > |> |> > (siprec) to > |> |> > > |consider the following document: > |> |> > > |- 'Use Cases and Requirements for SIP-based Media > |> |> > Recording (SIPREC)' > |> |> > > | as an Informational RFC > |> |> > > | > |> |> > > |The IESG plans to make a decision in the next few weeks, > |> |> > and solicits > |> |> > > |final comments on this action. Please send substantive > |> |> > > comments to the > |> |> > > |ietf@ietf.org mailing lists by 2011-04-20. Exceptionally, > |> |> > > comments may > |> |> > > be > |> |> > > |sent to iesg@ietf.org instead. In either case, please > |> retain the > |> |> > > |beginning of the Subject line to allow automated sorting. > |> |> > > | > |> |> > > |The file can be obtained via > |> |> > > |http://datatracker.ietf.org/doc/draft-ietf-siprec-req/ > |> |> > > | > |> |> > > |IESG discussion can be tracked via=20 > |> |> > > |http://datatracker.ietf.org/doc/draft-ietf-siprec-req/ > |> |> > > | > |> |> > > | > |> |> > > | > |> |> > > |No IPR declarations have been submitted directly=20 > on this I-D. > |> |> > > |_______________________________________________ > |> |> > > |siprec mailing 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 mperumal@cisco.com Thu Apr 21 08:57:50 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 60068E07C7; Thu, 21 Apr 2011 08:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.044 X-Spam-Level: X-Spam-Status: No, score=-9.044 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_00=-2.599, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W0uM9CxJxhCx; Thu, 21 Apr 2011 08:57:48 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfc.amsl.com (Postfix) with ESMTP id 896CAE065C; Thu, 21 Apr 2011 08:57:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=14565; q=dns/txt; s=iport; t=1303401467; x=1304611067; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=7WL/QxFAAeysO0Agg6So5vwAaAI/RF8NVyx6aLnIC08=; b=dmnUElo2qRhlE7xjfP6D6TdFFG9SP9vzvqplZDLp/eRvKrgNXfGoQZbV Z+f2CxLyfNm8P/xzDwVGA1CapY0orsBHOfawgYuyOQ25cVeFW13qPB8mf 1tWOkn9NNk83YrXozdjGZhrC42y0LtOaMPhE4ZuHPOzUQcTIMcdtCIe9d Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwAADJTsE2Q/khMgWdsb2JhbACXQI4HFAEBFiYliHCeUJxegiKDVASFcoxF X-IronPort-AV: E=Sophos;i="4.64,252,1301875200"; d="scan'208";a="26642991" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 21 Apr 2011 15:57:46 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3LFvf4R022603; Thu, 21 Apr 2011 15:57:46 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Apr 2011 21:27:44 +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, 21 Apr 2011 21:27:42 +0530 Message-ID: <1D062974A4845E4D8A343C653804920205425772@XMB-BGL-414.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Last Call:(UseCasesandRequirements forSIP-based MediaRecording (SIPREC)) toInformational RFC Thread-Index: Acv0WYBeRuGjGNBtTZSHeqn78QP5xwGEv6YwAAlHtwAAAvtH0AABcMXAAAdJn6AAAIZ7cAAHjozgABTz8IABOK4eoAAEuXiwAABUl5AAA9OvcAAAHn0A References: <20110406125020.17538.70016.idtracker@localhost><1D062974A4845E4D8A343C65380492020533BB70@XMB-BGL-414.cisco.com><07465C1D981ABC41A344374066AE1A2C38AB73D00B@TLVMBX01.nice.com><07465C1D981ABC41A344374066AE1A2C38AB73D110@TLVMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD06009D00@XMB-BGL-417.cisco.com><1D062974A4845E4D8A343C65380492020533BD38@XMB-BGL-414.cisco.com> <1D062974A4845E4D8A343C6538049202054256F5@XMB-BGL-414.cisco.com> <07465C1D981ABC41A344374066AE1A2C38AB73DDF5@TLVMBX01.nice.com> From: "Muthu ArulMozhi Perumal (mperumal)" To: "Elwell, John" , "Leon Portman" , "Parthasarathi R (partr)" , "Ram Mohan R (rmohanr)" , X-OriginalArrivalTime: 21 Apr 2011 15:57:44.0051 (UTC) FILETIME=[D9E39430:01CC003C] Cc: siprec@ietf.org Subject: Re: [siprec] Last Call:(UseCasesandRequirements forSIP-based MediaRecording (SIPREC)) toInformational RFC X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 21 Apr 2011 15:57:50 -0000 I am fine with separated REQ-022 and REQ-xxx. Though the solution for REQ-022 and REQ-xxx could be based on the wallclock time, having an explicit REQ-023 looks fine from a requirements perspective. Muthu |-----Original Message----- |From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] |Sent: Thursday, April 21, 2011 9:15 PM |To: Leon Portman; Parthasarathi R (partr); Muthu ArulMozhi Perumal (mperumal); Ram Mohan R (rmohanr); |ietf@ietf.org |Cc: siprec@ietf.org |Subject: RE: [siprec] Last Call:(UseCasesandRequirements forSIP-based |MediaRecording (SIPREC)) toInformational RFC | |I like the separated REQ-022 and REQ-xxx. In accordance with previous discussions, I think we need |REQ-023 too. | |John (as individual) | |> -----Original Message----- |> From: Leon Portman [mailto:Leon.Portman@nice.com] |> Sent: 21 April 2011 14:54 |> To: Parthasarathi R (partr); Muthu ArulMozhi Perumal |> (mperumal); Elwell, John; Ram Mohan R (rmohanr); ietf@ietf.org |> Cc: siprec@ietf.org |> Subject: RE: [siprec] Last |> Call:(Use CasesandRequirements |> forSIP-based MediaRecording (SIPREC)) toInformational RFC |> |> I agree, we should have dedicated wall clock requirement |> |> Leon |> |> -----Original Message----- |> From: Parthasarathi R (partr) [mailto:partr@cisco.com] |> Sent: Thursday, April 21, 2011 4:51 PM |> To: Muthu ArulMozhi Perumal (mperumal); Elwell, John; Ram |> Mohan R (rmohanr); Leon Portman; ietf@ietf.org |> Cc: siprec@ietf.org |> Subject: RE: [siprec] Last |> Call:(Use CasesandRequirements |> forSIP-based MediaRecording (SIPREC)) toInformational RFC |> |> Muthu/John, |> |> I will prefer to have "a" and "b" as separate requirement as |> "a" is related to RTP & its model, needs more discussion |> whereas "b" will be related to SIPREC metadata model which |> will be addressed by the current mechanism of start/stop time |> of media stream block. |> |> REQ-022: The mechanism MUST provide means for facilitating |> synchronization of the recorded media streams and metadata. |> |> REQ-xxx: The mechanism MUST provide means for facilitating |> synchronization among the recorded media streams |> |> Apart from this, I'm interested to know whether John's |> Req-023 requirement in the below mail will be solved by the |> current proposed REQ-xxx. |> |> Thanks |> Partha |> |> -----Original Message----- |> From: siprec-bounces@ietf.org |> [mailto:siprec-bounces@ietf.org] On Behalf Of Muthu ArulMozhi |> Perumal (mperumal) |> Sent: Thursday, April 21, 2011 5:15 PM |> To: Elwell, John; Ram Mohan R (rmohanr); Leon Portman; ietf@ietf.org |> Cc: siprec@ietf.org |> Subject: Re: [siprec] Last Call:(Use |> CasesandRequirements forSIP-based MediaRecording (SIPREC)) |> toInformational RFC |> |> +1 |> |> I would suggest a small change to REQ-022 that John has |> drafted below to make it more explicit: |> |> REQ-022 The mechanism MUST provide means for facilitating the |> following either at storage or at playback: |> a. Synchronization among the recorded media streams and b. |> Synchronization of the recorded media streams and metadata. |> |> Muthu |> |> |-----Original Message----- |> |From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] |> |Sent: Friday, April 15, 2011 11:53 AM |> |To: Muthu ArulMozhi Perumal (mperumal); Ram Mohan R (rmohanr); Leon |> Portman; ietf@ietf.org |> |Cc: siprec@ietf.org |> |Subject: RE: [siprec] Last Call: (Use |> CasesandRequirements for SIP-based |> |MediaRecording (SIPREC)) toInformational RFC |> | |> |So perhaps if we replace REQ-022 and REQ-023 with the |> requirement that |> Muthu has proposed and one |> |further requirement, e.g.: |> | |> |"REQ-022 The mechanism MUST provide means for facilitating |> synchronization of the |> |recorded media streams and metadata either at storage or at playback. |> | |> |REQ-023 The mechanism MUST provide means for relating recordings to |> wall clock time." |> | |> |John (as individual) |> | |> |> -----Original Message----- |> |> From: Muthu ArulMozhi Perumal (mperumal) |> [mailto:mperumal@cisco.com] |> |> Sent: 14 April 2011 21:42 |> |> To: Ram Mohan R (rmohanr); Leon Portman; Elwell, John; |> ietf@ietf.org |> |> Cc: siprec@ietf.org |> |> Subject: RE: [siprec] Last Call: |> |> (Use Cases andRequirements for |> |> SIP-based MediaRecording (SIPREC)) toInformational RFC |> |> |> |> I agree with John that these seem more like part of a |> solution rather |> |> |> than actual requirements. In addition, sending the |> wallclock time at |> |> media start/end alone may not suffice for achieving inter-media |> |> synchronization and playback, instead we may need to send the |> |> wallclock time periodically, like RTCP. For e.g, if there |> is a codec |> |> renegotiation in CS the RTP timestamp can restart from a random |> |> value. If silence suppression is enabled there would be |> gaps in the |> |> RTP timestamp. |> |> |> |> These are things that need to be discussed as part of the |> solution -- |> |> |> the requirement itself should be generic enough, like what I |> |> described. |> |> REQ-022 and REQ-023 we have doesn't seem to clearly indicate the |> |> purpose. |> |> |> |> Muthu |> |> |> |> |-----Original Message----- |> |> |From: Ram Mohan R (rmohanr) |> |> |Sent: Thursday, April 14, 2011 10:13 PM |> |> |To: Leon Portman; Elwell, John; Muthu ArulMozhi Perumal |> (mperumal); |> |> ietf@ietf.org |> |> |Cc: siprec@ietf.org |> |> |Subject: RE: [siprec] Last Call: |> (Use |> |> Cases andRequirements for SIP- |> |> |based MediaRecording (SIPREC)) toInformational RFC |> |> | |> |> |We already have attributes Start-Time / End-time in Media Stream |> |> block. This is for the same purpose |> |> |to indicate the wall clock time for start/end of media. |> |> | |> |> |Ram |> |> | |> |> |> -----Original Message----- |> |> |> From: siprec-bounces@ietf.org |> [mailto:siprec-bounces@ietf.org] On |> |> |> Behalf Of Leon Portman |> |> |> Sent: Thursday, April 14, 2011 9:57 PM |> |> |> To: Elwell, John; Muthu ArulMozhi Perumal (mperumal); |> ietf@ietf.org |> |> |> Cc: siprec@ietf.org |> |> |> Subject: Re: [siprec] Last Call: |> (Use |> |> |> Cases andRequirements for SIP-based MediaRecording (SIPREC)) |> |> |> toInformational RFC |> |> |> |> |> |> I am not sure that having wall clock only for CS start |> is enough, |> |> |> especially for partial metadata update. I will prefer to have on |> |> media |> |> |> level |> |> |> |> |> |> Leon |> |> |> |> |> |> -----Original Message----- |> |> |> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] |> |> |> Sent: Thursday, April 14, 2011 3:58 PM |> |> |> To: Leon Portman; Muthu ArulMozhi Perumal (mperumal); |> ietf@ietf.org |> |> |> Cc: siprec@ietf.org |> |> |> Subject: RE: [siprec] Last Call: |> |> (Use |> |> |> Cases andRequirements for SIP-based Media Recording (SIPREC)) |> |> |> toInformational RFC |> |> |> |> |> |> Understood, but if we have wall clock time for the |> start of a CS, |> |> |> wouldn't that be sufficient? The new requirement would cover |> |> |> synchronization of all media start/stops relative to that time. |> |> |> |> |> |> John (as individual) |> |> |> |> |> |> |> |> |> > -----Original Message----- |> |> |> > From: Leon Portman [mailto:Leon.Portman@nice.com] |> |> |> > Sent: 14 April 2011 13:19 |> |> |> > To: Elwell, John; Muthu ArulMozhi Perumal (mperumal); |> |> ietf@ietf.org |> |> |> > Cc: siprec@ietf.org |> |> |> > Subject: RE: [siprec] Last Call: |> |> |> > (Use Cases andRequirements for |> |> |> > SIP-based Media Recording (SIPREC)) toInformational RFC |> |> |> > |> |> |> > Actually REQ-022 and REQ-023 describing not only |> requirement to |> |> |> > synchronize between different media streams but more |> importantly |> |> |> |> > ability to relate them to real world (wall) clock. It is not |> only |> |> |> > important to playback them correctly but also to know when it |> was |> |> |> > said. |> |> |> > One example is continue trading after closing hour |> (even for one |> |> |> |> > second is not allowed) |> |> |> > |> |> |> > And if these media are synchronized to wall clock |> then they are |> |> also |> |> |> > synchronized between them thus I am not sure if we need this |> |> |> > additional requirement. |> |> |> > |> |> |> > Thanks |> |> |> > |> |> |> > Leon |> |> |> > |> |> |> > -----Original Message----- |> |> |> > From: siprec-bounces@ietf.org |> |> |> > [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John |> |> |> > Sent: Thursday, April 14, 2011 1:54 PM |> |> |> > To: Muthu ArulMozhi Perumal (mperumal); ietf@ietf.org |> |> |> > Cc: siprec@ietf.org |> |> |> > Subject: Re: [siprec] Last Call: |> |> |> > (Use Cases andRequirements for |> |> |> > SIP-based Media Recording (SIPREC)) toInformational RFC |> |> |> > |> |> |> > |> |> |> > |> |> |> > |> |> |> > > -----Original Message----- |> |> |> > > From: siprec-bounces@ietf.org |> |> |> > > [mailto:siprec-bounces@ietf.org] On Behalf Of Muthu |> |> |> > ArulMozhi Perumal |> |> |> > > (mperumal) |> |> |> > > Sent: 14 April 2011 07:34 |> |> |> > > To: ietf@ietf.org |> |> |> > > Cc: siprec@ietf.org |> |> |> > > Subject: Re: [siprec] Last Call: |> |> |> > > (Use Cases |> andRequirements for |> |> |> > > SIP-based Media Recording (SIPREC)) toInformational RFC |> |> |> > > |> |> |> > > I've one major comment. It draft discusses synchronization |> |> |> > between the |> |> |> > > recorded media streams and synchronized playback, which |> |> |> > seem important |> |> |> > > for certain applications: |> |> |> > > |> |> |> > > |> |> |> > > Some applications require the recording of more than one |> |> |> > media stream, |> |> |> > > possibly of different types. Media are synchronized, either |> |> |> > at storage |> |> |> > > or at playback. |> |> |> > > |> |> |> > > |> |> |> > > However, in the requirements section it doesn't seem |> |> REQ-022 and |> |> |> > > REQ-023 are all that are need and sufficient to |> |> achieve this with |> |> |> > > needed precision. So, I would suggest adding another |> |> requirement |> |> as |> |> |> > > follows: |> |> |> > > The mechanism MUST provide means for facilitating |> |> |> > synchronization of |> |> |> > > the recorded media streams and metadata either at storage or |> at |> |> |> > > playback. |> |> |> > > This includes, but not limited to, the information |> |> needed as per |> |> |> > > REQ-022 and REQ-023. |> |> |> > [JRE] This seems a reasonable addition. I wonder if the new |> |> |> > requirement (first sentence only) is sufficient as a |> |> |> > **replacement** for REQ-022 and REQ-023. On reading |> REQ-022 and |> |> |> > REQ-023 again, it is not so clear what their purpose |> |> was, and they |> |> |> > seem to be more like a solution than a requirement. |> |> |> > One purpose would certainly be that covered by Muthu's new |> |> |> > requirement. Was there any other purpose? |> |> |> > |> |> |> > John |> |> |> > |> |> |> > > |> |> |> > > A nitpick: |> |> |> > > Use Case 8 |> |> |> > > In cases where calls inside or between branches must |> |> be recorded, |> |> a |> |> |> > > centralized recording system in data centers together with |> |> |> > telephony |> |> |> > > infrastructure (e.g. PBX) me deployed. |> |> |> > > |> |> |> > > s/me/may be |> |> |> > > |> |> |> > > Muthu |> |> |> > > |> |> |> > > |-----Original Message----- |> |> |> > > |From: siprec-bounces@ietf.org |> [mailto:siprec-bounces@ietf.org] |> |> On |> |> |> > > Behalf Of The IESG |> |> |> > > |Sent: Wednesday, April 06, 2011 6:20 PM |> |> |> > > |To: IETF-Announce |> |> |> > > |Cc: siprec@ietf.org |> |> |> > > |Subject: [siprec] Last Call: |> |> |> > > (Use Cases |> |> |> > > andRequirements for SIP-based |> |> |> > > |Media Recording (SIPREC)) toInformational RFC |> |> |> > > | |> |> |> > > | |> |> |> > > |The IESG has received a request from the SIP Recording WG |> |> |> > (siprec) to |> |> |> > > |consider the following document: |> |> |> > > |- 'Use Cases and Requirements for SIP-based Media |> |> |> > Recording (SIPREC)' |> |> |> > > | as an Informational RFC |> |> |> > > | |> |> |> > > |The IESG plans to make a decision in the next few weeks, |> |> |> > and solicits |> |> |> > > |final comments on this action. Please send substantive |> |> |> > > comments to the |> |> |> > > |ietf@ietf.org mailing lists by 2011-04-20. Exceptionally, |> |> |> > > comments may |> |> |> > > be |> |> |> > > |sent to iesg@ietf.org instead. In either case, please |> |> retain the |> |> |> > > |beginning of the Subject line to allow automated sorting. |> |> |> > > | |> |> |> > > |The file can be obtained via |> |> |> > > |http://datatracker.ietf.org/doc/draft-ietf-siprec-req/ |> |> |> > > | |> |> |> > > |IESG discussion can be tracked via |> |> |> > > |http://datatracker.ietf.org/doc/draft-ietf-siprec-req/ |> |> |> > > | |> |> |> > > | |> |> |> > > | |> |> |> > > |No IPR declarations have been submitted directly |> on this I-D. |> |> |> > > |_______________________________________________ |> |> |> > > |siprec mailing 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 partr@cisco.com Thu Apr 21 09:20:08 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D0D84E0663 for ; Thu, 21 Apr 2011 09:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.153 X-Spam-Level: X-Spam-Status: No, score=-10.153 tagged_above=-999 required=5 tests=[AWL=0.446, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHVTniWj7d2X for ; Thu, 21 Apr 2011 09:20:07 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfc.amsl.com (Postfix) with ESMTP id C852BE065C for ; Thu, 21 Apr 2011 09:20:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=10284; q=dns/txt; s=iport; t=1303402806; x=1304612406; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=hJePwwk7GHqoJslazQgWZnqEcU9DT/d6Ol3ksfuYGeI=; b=O+civOjpvCg6nO5/+KiXQnqkbmodo3kzB8khW07MLYqHYzX8to/UzhMJ 42NmEz2ZueEhket7ao8rPJFg9L6y8VAIOXAYBIIfesnVwcXcbc9igTMqU OSnLFoFDGt+Ly4IqjcGMURIoeGJZMTb24CJtm+pIdU8W3LBmszgjMrzVl I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwAACNYsE2Q/khLgWdsb2JhbACXQI4HFAEBFiYliHCebZxZhXYEhXKMRQ X-IronPort-AV: E=Sophos;i="4.64,252,1301875200"; d="scan'208";a="84616781" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 21 Apr 2011 16:20:06 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3LGK4Su003075; Thu, 21 Apr 2011 16:20:05 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Apr 2011 21:50:04 +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, 21 Apr 2011 21:50:03 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Does MS have life outside a particular CS? (was RE: [siprec] comments on draft-ram-siprec-metadata-04) Thread-Index: Acv+pbws7MwochNUSB2j8RZ3ismj6AAAQrXwACiVZgAABfyA0AACLm6QAASWOmAAG+JhEAANxV4AAAViIkAAARvLsA== References: <21866C7FE177A4449B9136B5B24B1B130BC011290A@EXMBXCLUS01.citservers.local><21866C7FE177A4449B9136B5B24B1B130BC011294A@EXMBXCLUS01.citservers.local><35BCE99A477D6A4986FB2216D8CF2CFD05DD8C0C@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD05EF92EF@XMB-BGL-417.cisco.com> <4D9CBD8C.4010901@cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD06133966@XMB-BGL-417.cisco.com> <4DAD8A5F.4040506@cisco.com> <4DADA8E6.9010006@cisco.com> <35BCE99A477D 6A498 6 F B 2216D8 CF2CFD06133A56@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD06133DD4@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD06133E6B@XMB-BGL-417.cisco.com> From: "Parthasarathi R (partr)" To: "Elwell, John" , "Ram Mohan R (rmohanr)" , "Paul Kyzivat (pkyzivat)" X-OriginalArrivalTime: 21 Apr 2011 16:20:04.0541 (UTC) FILETIME=[F8E21ED0:01CC003F] Cc: siprec@ietf.org Subject: Re: [siprec] Does MS have life outside a particular CS? (was RE: comments on draft-ram-siprec-metadata-04) X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 21 Apr 2011 16:20:09 -0000 John, Please read inline. Thanks Partha=20 -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 Sent: Thursday, April 21, 2011 9:12 PM To: Parthasarathi R (partr); Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) Cc: siprec@ietf.org Subject: RE: Does MS have life outside a particular CS? (was RE: [siprec] comments on draft-ram-siprec-metadata-04) Partha,=20 > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > Sent: 21 April 2011 14:25 > To: Elwell, John; Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > Cc: siprec@ietf.org > Subject: RE: Does MS have life outside a particular CS? (was > RE: [siprec] comments on draft-ram-siprec-metadata-04) >=20 > John, >=20 > I could think of one usecase wherein MS is outside CS but within=20 > single RS. The usecase is multiple CS within single RS and MS. The=20 > usecase is as follows: >=20 > B2BUA acts as SRC. A, B, C are participants within single B2BUA. A=20 > creates single RS for a CSG. >=20 > 1) A calls B through B2BUA. B2BUA creates RS towards SRS with CSG1,=20 > CS1, > MS1 (A's media stream), MS2 (B's media stream), Participant1 as A & > Participant2 as B. [JRE] Why two media streams? Why not a single MS, with both A and B sending and receiving that MS? The media streams are un-mixed, MS1 points to RTP from A through label attribute in MS1 SDP, MS2 points to RTP from B through label attribute in MS2 SDP > 2) B connects with C through B2BUA > 3) B transfer the call of A & B to C using REFER, B2BUA converts REFER > to RE-INVITE towards A & C and A & C are connected. B2BUA updates RS=20 > with CS2, Participant1 as A & participant2 as C, MS1(A's media=20 > stream), MS2(C's media stream). [JRE] I would have expected, from my understanding of the metadata model, that the CS2 would have a new MS, with both A and B sending and receiving that new MS. It is not mandatory because participant information will be updated and pointing to the same m-line in RS with same label attribute. >From SRS perspective, the same media stream with the update in the participant name only. Say MS2 is stored as one record with B as participant for T0 to T1 timelines and C as participant from T1 to T2. > There is no update on RS1, CSG1, MS1, MS2. MS2 will become MS2 with=20 > the new association and in terms of format, it will associate with=20 > tag. >=20 > In the above scenario, MS have life outside CS but it is within RS. [JRE] I can see how it COULD work like that, but it is not intuitive.=20 In SIPREC solution, UPDATE message with CS2(session element) , participant "C" element are received in SRS. This partial update of UPDATE helps to make this scenario work. There is no change in term stream element or RS SDP To me, a new CS means the existing media stream stops and a new media stream is created. I'm interested knowing whether you propose that MS MUST stop in case CS ends and the above scenario is outside the scope of SIPREC? > The > unique id shall be within RS scope as mentioned in IETF-80 meeting.=20 > But in another situation, MS is outside the scope of RS but within CS=20 > and the usecase is Multiple RS for single CS, details are as follows: >=20 > A, B are pariticipants. A acts as SRC which tear down RS whenever hold > happens & creates new RS when resume happens. >=20 > 1) A calls B. A creates RS1 towards SRS with CS1, MS1 (A's media=20 > stream), MS2 (B's Media stream),Participant1 as A & Participant2 as B. [JRE] Again, I would model this as a single MS, to which both A and B contribute. Again, unmixed stream from A and B > 2) A put B on hold. A tear down RS1. > 3) A resume B. A creates RS2 towards SRS with CS1, MS1 (A's media=20 > stream), MS2 (B's Media stream),Participant1 as A & Participant2 as B >=20 > Here MS1 & MS2 needs to be same across RS to group media streams=20 > correctly. Please let me know your opinion here. [JRE] Although I disagree that we have two Media Streams here, I do agree that the single Media Stream could be considered to survive the hold/resume, and hence survive from RS1 to RS2. But the MS is within the context of the same CS (CS1), and therefore this is outside the scope of this particular thread, which is asking whether an MS can have a life outside a particular CS. In this case the MS continues to be associated with the CS, so I don't have a problem with that. I have 2nd example to illustrate MS have life outside RS. So you have failed to convince me that an MS needs to have a life outside a CS. In case the above scenario-1 way of recording is outside the scope of SIPREC, I agree with you that MS does not have life outside a particular CS =20 John (as individual) >=20 > Having said that MS have life outside a particular CS, I create=20 > separate thread within unique how it shall be handled. >=20 > Thanks > Partha >=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Thursday, April 21, 2011 12:01 PM > To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > Cc: Parthasarathi R (partr); siprec@ietf.org > Subject: Does MS have life outside a particular CS? (was RE: [siprec]=20 > comments on draft-ram-siprec-metadata-04) >=20 > =20 >=20 > > -----Original Message----- > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > Sent: 20 April 2011 18:08 > > To: Elwell, John; Paul Kyzivat (pkyzivat) > > Cc: Parthasarathi R (partr); siprec@ietf.org > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > >=20 > > Hi John, > >=20 > > Please see inline [RAM] > >=20 > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > Sent: Wednesday, April 20, 2011 8:19 PM > > > To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > > Cc: Parthasarathi R (partr); siprec@ietf.org > > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > >=20 > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > > > Sent: 20 April 2011 14:52 > > > > To: Elwell, John; Paul Kyzivat (pkyzivat) > > > > Cc: Parthasarathi R (partr); siprec@ietf.org > > > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > > > > > > > John, > > > > > > > > I agree with you that normal cases RS will remain at > least for the >=20 > > > > duration of CS. However it is common to have use cases where > > > recording > > > > is done for first few mins of a CS and then stopped, > > re-started at a > > > > later point (e.g Recording of a company meeting where > you may want > > to > > > > record only portions of meeting). > > > > > > > > In any case, the point I like to high light here is, MS > > block could > > > be > > > > common across RS and even across CS[ due to consult > > transfer e.t.c]. > > > > These use cases indicate the need to have a unique ID > for MS block >=20 > > > > (similar to the UUID that we have defined in format) as > we cannot > > > > depend on neither CS ID or RS ID. > > > [JRE] I am having a hard time understanding the concept > of a single > > > Media Stream that survives across multiple CSs. For > example, in the > > > case of transfer, I would have thought new Media Streams would be=20 > > > created. > >=20 > > [RAM] > > Here is my thoughts.=20 > > 1) There can be multiple RS per CS > > RS1 --- CS1--MS1 > > RS2----CS1--MS1 > > Examples are partial recording of CS (like recording parts > of meeting, >=20 > > redundant recording where there are multiple SRCs recording > the same > > CS) > [JRE] Agreed. In this case MS1 is local to CS1. >=20 > >=20 > > 2) There can be same Media Stream across multiple CS.=20 > > RS1--- CS1--- MS1 > > RS2--CS2--MS1 > > Examples are Multicast MoH played to multiple end points who are=20 > > potentially part of disjoint CSs where each CS is recorded > as part of > > separate RS. > >=20 > > Of course the above is arguable where the stream is same or > different. > > My view is since the UA (that supplies the Multicast MoH) and its=20 > > media are same across all CS, I think it can be represented > as same MS >=20 > > block. > [JRE] I would argue these are different MSs. I agree that a medium=20 > such as music on hold might be sent, in synch, to multiple=20 > participants in multiple CSs. In that particular situation there might > be some efficiency saving by calling it the same MS. However, I would=20 > suggest (although this is not my field of expertise) it would make=20 > life a lot harder for the SRS and its database. I would have expected=20 > to want to record a complete CS (all its participants and media=20 > streams) as a complete recording, which could be deleted, copied, and > so on without having to go looking for other objects that complete=20 > that recording and are shared with other recordings. For example, if=20 > you delete a recording, you would want to delete all its MSs, but not=20 > those used by other recordings, although you would need a garbage=20 > collection mechanism to delete an MS recording when it is no longer=20 > used by any CS recordings. Rather ugly. Making a MS local to a CS=20 > would simplify all this. >=20 > >=20 > >=20 > > However it is still possible to treat each as separate > stream in the > > model, in which case the information that it is the same MS > played by > > a UA to different CS will be lost. I don't know if there is an=20 > > interest to capture this level of detail and if it is of any use to=20 > > SRS. > [JRE] I assume what you are saying here is not that information will=20 > be lost, but that you will be unable to tell, without doing a=20 > comparison, whether two different MSs played to participants in two=20 > different CSs are identical or not for the particular time span that=20 > is common. I don't see where such a requirement would come from. >=20 > John (as individual) >=20 >=20 From john.elwell@siemens-enterprise.com Thu Apr 21 13:18:19 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A0917E06D9 for ; Thu, 21 Apr 2011 13:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.171 X-Spam-Level: X-Spam-Status: No, score=-105.171 tagged_above=-999 required=5 tests=[AWL=1.428, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9J6e8RLBkpI6 for ; Thu, 21 Apr 2011 13:18:18 -0700 (PDT) Received: from mail174.messagelabs.com (mail174.messagelabs.com [85.158.138.51]) by ietfc.amsl.com (Postfix) with SMTP id 701A0E067D for ; Thu, 21 Apr 2011 13:18:17 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1303417096!17727455!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 4790 invoked from network); 21 Apr 2011 20:18:16 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-13.tower-174.messagelabs.com with SMTP; 21 Apr 2011 20:18:16 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 0294C23F03DB; Thu, 21 Apr 2011 22:18:16 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 21 Apr 2011 22:18:16 +0200 From: "Elwell, John" To: "Parthasarathi R (partr)" , "Ram Mohan R (rmohanr)" , "Paul Kyzivat (pkyzivat)" Date: Thu, 21 Apr 2011 22:18:14 +0200 Thread-Topic: Does MS have life outside a particular CS? (was RE: [siprec] comments on draft-ram-siprec-metadata-04) Thread-Index: Acv+pbws7MwochNUSB2j8RZ3ismj6AAAQrXwACiVZgAABfyA0AACLm6QAASWOmAAG+JhEAANxV4AAAViIkAAARvLsAAHbbeQ Message-ID: References: <21866C7FE177A4449B9136B5B24B1B130BC011290A@EXMBXCLUS01.citservers.local><21866C7FE177A4449B9136B5B24B1B130BC011294A@EXMBXCLUS01.citservers.local><35BCE99A477D6A4986FB2216D8CF2CFD05DD8C0C@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD05EF92EF@XMB-BGL-417.cisco.com> <4D9CBD8C.4010901@cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD06133966@XMB-BGL-417.cisco.com> <4DAD8A5F.4040506@cisco.com> <4DADA8E6.9010006@cisco.com> <35BCE99A477D 6A498 6 F B 2216D8 CF2CFD06133A56@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD06133DD4@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD06133E6B@XMB-BGL-417.cisco.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] Does MS have life outside a particular CS? (was RE: comments on draft-ram-siprec-metadata-04) X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 21 Apr 2011 20:18:19 -0000 =20 > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com]=20 > Sent: 21 April 2011 17:20 > To: Elwell, John; Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > Cc: siprec@ietf.org > Subject: RE: Does MS have life outside a particular CS? (was=20 > RE: [siprec] comments on draft-ram-siprec-metadata-04) >=20 > John, >=20 > Please read inline. >=20 > Thanks > Partha=20 >=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > Sent: Thursday, April 21, 2011 9:12 PM > To: Parthasarathi R (partr); Ram Mohan R (rmohanr); Paul Kyzivat > (pkyzivat) > Cc: siprec@ietf.org > Subject: RE: Does MS have life outside a particular CS? (was RE: > [siprec] comments on draft-ram-siprec-metadata-04) >=20 > Partha,=20 >=20 > > -----Original Message----- > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > Sent: 21 April 2011 14:25 > > To: Elwell, John; Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > Cc: siprec@ietf.org > > Subject: RE: Does MS have life outside a particular CS? (was > > RE: [siprec] comments on draft-ram-siprec-metadata-04) > >=20 > > John, > >=20 > > I could think of one usecase wherein MS is outside CS but within=20 > > single RS. The usecase is multiple CS within single RS and MS. The=20 > > usecase is as follows: > >=20 > > B2BUA acts as SRC. A, B, C are participants within single B2BUA. A=20 > > creates single RS for a CSG. > >=20 > > 1) A calls B through B2BUA. B2BUA creates RS towards SRS with CSG1,=20 > > CS1, > > MS1 (A's media stream), MS2 (B's media stream), Participant1 as A & > > Participant2 as B. > [JRE] Why two media streams? Why not a single MS, with both A and B > sending and receiving that MS? > The media streams are un-mixed, MS1 points to RTP from A > through label attribute in MS1 SDP, MS2 points to RTP from B through > label attribute in MS2 SDP [JRE] Reading the metadata model again, I think it does seem to imply two M= edia Stream objects if the two directions for a 2-party call are sent unmix= ed (as two m-lines in the RS SDP), so I will concede that we have two Media= Stream objects here. I had been thinking of a slightly different model, wh= ere there is one Media Stream, but associations between the Media Stream an= d Participants pointed to different m-lines in the RS SDP. >=20 > > 2) B connects with C through B2BUA > > 3) B transfer the call of A & B to C using REFER, B2BUA=20 > converts REFER >=20 > > to RE-INVITE towards A & C and A & C are connected. B2BUA=20 > updates RS=20 > > with CS2, Participant1 as A & participant2 as C, MS1(A's media=20 > > stream), MS2(C's media stream). > [JRE] I would have expected, from my understanding of the metadata > model, that the CS2 would have a new MS, with both A and B sending and > receiving that new MS. >=20 > It is not mandatory because participant information will be > updated and pointing to the same m-line in RS with same label=20 > attribute. > From SRS perspective, the same media stream with the update in the > participant name only. Say MS2 is stored as one record with B as > participant for T0 to T1 timelines and C as participant from T1 to T2. > [JRE] Or alternatively it could be modelled that when a new CS starts there= is a new Media Stream object, still pointing to the same m-line in the RS = SDP. This would avoid the need for a Media Stream object to survive beyond = the lifetime of a CS, and therefore allow local identification. While there= is no CS in progress, the m-line would be disabled (port 0) and would not = be referenced by any Media Stream. >=20 > > There is no update on RS1, CSG1, MS1, MS2. MS2 will become MS2 with=20 > > the new association and in terms of format, it will associate with=20 > > tag. > >=20 > > In the above scenario, MS have life outside CS but it is within RS. > [JRE] I can see how it COULD work like that, but it is not intuitive.=20 >=20 > In SIPREC solution, UPDATE message with CS2(session=20 > element) , > participant "C" element are received in SRS. This partial update of > UPDATE helps to make this scenario work. There is no change in term > stream element or RS SDP >=20 > To me, a new CS means the existing media stream stops and a new media > stream is created. >=20 > I'm interested knowing whether you propose that MS=20 > MUST stop in > case CS ends and the above scenario is outside the scope of SIPREC? > >=20 > > The > > unique id shall be within RS scope as mentioned in IETF-80 meeting.=20 > > But in another situation, MS is outside the scope of RS but=20 > within CS=20 > > and the usecase is Multiple RS for single CS, details are=20 > as follows: > >=20 > > A, B are pariticipants. A acts as SRC which tear down RS=20 > whenever hold >=20 > > happens & creates new RS when resume happens. > >=20 > > 1) A calls B. A creates RS1 towards SRS with CS1, MS1 (A's media=20 > > stream), MS2 (B's Media stream),Participant1 as A &=20 > Participant2 as B. > [JRE] Again, I would model this as a single MS, to which both A and B > contribute. > Again, unmixed stream from A and B > > 2) A put B on hold. A tear down RS1. > > 3) A resume B. A creates RS2 towards SRS with CS1, MS1 (A's media=20 > > stream), MS2 (B's Media stream),Participant1 as A &=20 > Participant2 as B > >=20 > > Here MS1 & MS2 needs to be same across RS to group media streams=20 > > correctly. Please let me know your opinion here. >=20 > [JRE] Although I disagree that we have two Media Streams here, I do > agree that the single Media Stream could be considered to survive the > hold/resume, and hence survive from RS1 to RS2. But the MS is=20 > within the > context of the same CS (CS1), and therefore this is outside=20 > the scope of > this particular thread, which is asking whether an MS can have a life > outside a particular CS. In this case the MS continues to be=20 > associated > with the CS, so I don't have a problem with that. >=20 > I have 2nd example to illustrate MS have life outside RS. > >=20 > So you have failed to convince me that an MS needs to have a life > outside a CS. >=20 > In case the above scenario-1 way of recording is outside the > scope of SIPREC, I agree with you that MS does not have life outside a > particular CS =20 [JRE] I assume you are talking about the call transfer case. I am not sayin= g that use case is outside the scope of SIPREC. I am just saying that it ca= n be modelled a different way, which may be advantageous in terms of the nu= mber of globally unique identifiers needed. John (as individual) >=20 > John (as individual) >=20 >=20 > >=20 > > Having said that MS have life outside a particular CS, I create=20 > > separate thread within unique how it shall be handled. > >=20 > > Thanks > > Partha > >=20 > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Thursday, April 21, 2011 12:01 PM > > To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > Cc: Parthasarathi R (partr); siprec@ietf.org > > Subject: Does MS have life outside a particular CS? (was=20 > RE: [siprec]=20 > > comments on draft-ram-siprec-metadata-04) > >=20 > > =20 > >=20 > > > -----Original Message----- > > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > > Sent: 20 April 2011 18:08 > > > To: Elwell, John; Paul Kyzivat (pkyzivat) > > > Cc: Parthasarathi R (partr); siprec@ietf.org > > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > >=20 > > > Hi John, > > >=20 > > > Please see inline [RAM] > > >=20 > > > > -----Original Message----- > > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > Sent: Wednesday, April 20, 2011 8:19 PM > > > > To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > > > Cc: Parthasarathi R (partr); siprec@ietf.org > > > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > > >=20 > > > >=20 > > > >=20 > > > > > -----Original Message----- > > > > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > > > > Sent: 20 April 2011 14:52 > > > > > To: Elwell, John; Paul Kyzivat (pkyzivat) > > > > > Cc: Parthasarathi R (partr); siprec@ietf.org > > > > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > > > > > > > > > John, > > > > > > > > > > I agree with you that normal cases RS will remain at > > least for the > >=20 > > > > > duration of CS. However it is common to have use cases where > > > > recording > > > > > is done for first few mins of a CS and then stopped, > > > re-started at a > > > > > later point (e.g Recording of a company meeting where > > you may want > > > to > > > > > record only portions of meeting). > > > > > > > > > > In any case, the point I like to high light here is, MS > > > block could > > > > be > > > > > common across RS and even across CS[ due to consult > > > transfer e.t.c]. > > > > > These use cases indicate the need to have a unique ID > > for MS block > >=20 > > > > > (similar to the UUID that we have defined in format) as > > we cannot > > > > > depend on neither CS ID or RS ID. > > > > [JRE] I am having a hard time understanding the concept > > of a single > > > > Media Stream that survives across multiple CSs. For > > example, in the > > > > case of transfer, I would have thought new Media=20 > Streams would be=20 > > > > created. > > >=20 > > > [RAM] > > > Here is my thoughts.=20 > > > 1) There can be multiple RS per CS > > > RS1 --- CS1--MS1 > > > RS2----CS1--MS1 > > > Examples are partial recording of CS (like recording parts > > of meeting, > >=20 > > > redundant recording where there are multiple SRCs recording > > the same > > > CS) > > [JRE] Agreed. In this case MS1 is local to CS1. > >=20 > > >=20 > > > 2) There can be same Media Stream across multiple CS.=20 > > > RS1--- CS1--- MS1 > > > RS2--CS2--MS1 > > > Examples are Multicast MoH played to multiple end points who are=20 > > > potentially part of disjoint CSs where each CS is recorded > > as part of > > > separate RS. > > >=20 > > > Of course the above is arguable where the stream is same or > > different. > > > My view is since the UA (that supplies the Multicast MoH) and its=20 > > > media are same across all CS, I think it can be represented > > as same MS > >=20 > > > block. > > [JRE] I would argue these are different MSs. I agree that a medium=20 > > such as music on hold might be sent, in synch, to multiple=20 > > participants in multiple CSs. In that particular situation=20 > there might >=20 > > be some efficiency saving by calling it the same MS.=20 > However, I would=20 > > suggest (although this is not my field of expertise) it would make=20 > > life a lot harder for the SRS and its database. I would=20 > have expected=20 > > to want to record a complete CS (all its participants and media=20 > > streams) as a complete recording, which could be deleted,=20 > copied, and >=20 > > so on without having to go looking for other objects that complete=20 > > that recording and are shared with other recordings. For=20 > example, if=20 > > you delete a recording, you would want to delete all its=20 > MSs, but not=20 > > those used by other recordings, although you would need a garbage=20 > > collection mechanism to delete an MS recording when it is no longer=20 > > used by any CS recordings. Rather ugly. Making a MS local to a CS=20 > > would simplify all this. > >=20 > > >=20 > > >=20 > > > However it is still possible to treat each as separate > > stream in the > > > model, in which case the information that it is the same MS > > played by > > > a UA to different CS will be lost. I don't know if there is an=20 > > > interest to capture this level of detail and if it is of=20 > any use to=20 > > > SRS. > > [JRE] I assume what you are saying here is not that=20 > information will=20 > > be lost, but that you will be unable to tell, without doing a=20 > > comparison, whether two different MSs played to participants in two=20 > > different CSs are identical or not for the particular time=20 > span that=20 > > is common. I don't see where such a requirement would come from. > >=20 > > John (as individual) > >=20 > >=20 > = From partr@cisco.com Mon Apr 25 07:35:08 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CFABFE06F5 for ; Mon, 25 Apr 2011 07:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.171 X-Spam-Level: X-Spam-Status: No, score=-10.171 tagged_above=-999 required=5 tests=[AWL=0.427, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3x9NlbPNyhO0 for ; Mon, 25 Apr 2011 07:35:07 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfc.amsl.com (Postfix) with ESMTP id 22251E073F for ; Mon, 25 Apr 2011 07:35:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=7171; q=dns/txt; s=iport; t=1303742107; x=1304951707; h=mime-version:subject:date:message-id:from:to; bh=kSqspiDoOdcqH1aG1SSQ9vtwZa3W8UxHqfXL1xS9Sy4=; b=dQOQgiDFCucd6IUsWE8ENtvTaCjt87Hi34rx0BXMg4qTCn20mxQmyrFx oxkqMBmIslcNCiVlBJ52QE9/8ZEu86ueoHez1aKoT7IhvKOFD1+yAgSNp TiejofE0umvM26yfh9CZxfc3yVs+qJ+J7P0cBmSnLeskD9Ibd1/Uhbypy U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicEAH2FtU2Q/khMgWdsb2JhbAClNBQBARYmJaVRnBqFdgSFdIxQ X-IronPort-AV: E=Sophos;i="4.64,265,1301875200"; d="scan'208,217";a="27032020" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 25 Apr 2011 14:35:05 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3PEZ308002027 for ; Mon, 25 Apr 2011 14:35:05 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 25 Apr 2011 20:05:04 +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_01CC0355.F78A442D" Date: Mon, 25 Apr 2011 20:05:04 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RS to CS relationship as an attribute in Recording block Thread-Index: AcwDVfcxwzzkvJ9VQsOCC7hSyh5X7A== From: "Parthasarathi R (partr)" To: X-OriginalArrivalTime: 25 Apr 2011 14:35:04.0781 (UTC) FILETIME=[F79607D0:01CC0355] Subject: [siprec] RS to CS relationship as an attribute in Recording block X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 25 Apr 2011 14:35:09 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC0355.F78A442D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, =20 The context for this attribute is whether globally unique id is required in each metadata block or whether it is required only in some of the block only. One of the compelling reason for globally unique id is because of the complex relationship between RS and CS which is not currently passed from SRC to SRS. I'm trying to find whether passing the information will reduce the complexity of globally unique id in some blocks. =20 In case RS to CS relationship between SRC & SRS, there is a possibility of three types and they are as follows: =20 1) One RS to one CS: Simple mechanism and every CS is directly mapped to RS. Here, RS needs to be global unique id whereas those block is not required to be global. =20 2) One RS to many CS: Usecases are as follows: a) Persistent recording=20 b) Recording with single CSG =20 Here as well, RS needs to be global unique id whereas those block is not required to be global. =20 3) Many RS to one CS:=20 Use case are as follows: a) start/stop recording session during single CS.=20 Here. RS needs global unique id as well as CS needs global unique id. Please note that this mechanism will not co-exist with above two mechanism. =20 The attribute name is recording_type wherein the value of the attributes will be a) one_rs_one_cs b) one_rs_many_cs c) many_rs_one_cs =20 By knowing this attribute, SRS will be able to manage unique-id and its scope as SRS aware of SRC mechanism. Say in case of one_rs_many_cs SRC, media stream (MS) will never exceed RS wherein in case of many_rs_one_cs, MS will never exceed CS and in both scenario, MS is local to RS or CS. Please let me know whether it is worth to add this attribute in Metadata model. =20 Thanks Partha ------_=_NextPart_001_01CC0355.F78A442D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 all,
 
The = context for this=20 attribute is whether globally unique id is required in each metadata = block or=20 whether it is required only in some of the block only. One of the = compelling=20 reason for globally unique id is because of the complex relationship = between RS=20 and CS which is not currently passed from SRC to SRS. I'm trying to find = whether=20 passing the information will reduce the complexity of globally = unique id in=20 some blocks.
 
In = case RS to CS=20 relationship between SRC & SRS, there is a possibility = of three=20 types and they are as follows:
 
1) One = RS to one CS:=20 Simple mechanism and every CS is directly mapped to RS. Here, RS needs = to=20 be global unique id whereas those block is not required to be=20 global.
 
2) One = RS to many=20 CS:
      Usecases are = as=20 follows:
        =  a)=20 Persistent recording
       &nbs= p; b)=20 Recording with single CSG
 
Here = as well, RS=20 needs to be global unique id whereas those block is not required to be=20 global.
 
3) = Many RS to one=20 CS:
     Use case are as=20 follows:
        =  a)=20 start/stop recording session during single CS.
Here. = RS needs=20 global unique id as well as CS needs global unique id. Please note that = this=20 mechanism will not co-exist with above two = mechanism.
 
The = attribute name=20 is recording_type wherein the value of the attributes will=20 be
a)=20 one_rs_one_cs
b)=20 one_rs_many_cs
c)=20 many_rs_one_cs
 
By = knowing this=20 attribute, SRS will be able to manage unique-id and its scope as SRS = aware of=20 SRC mechanism. Say in case of one_rs_many_cs SRC, media stream (MS) will = never=20 exceed RS wherein in case of many_rs_one_cs, MS will never exceed CS and = in both=20 scenario, MS is local to RS or CS. Please let me know whether it is = worth to add=20 this attribute in Metadata model.
 
Thanks
Partha
------_=_NextPart_001_01CC0355.F78A442D-- From pkyzivat@cisco.com Mon Apr 25 07:57:16 2011 Return-Path: X-Original-To: siprec@ietfc.amsl.com Delivered-To: siprec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C355EE0696 for ; Mon, 25 Apr 2011 07:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.415 X-Spam-Level: X-Spam-Status: No, score=-110.415 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f3ROiF87tLQB for ; Mon, 25 Apr 2011 07:57:16 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfc.amsl.com (Postfix) with ESMTP id 06E82E0682 for ; Mon, 25 Apr 2011 07:57:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=2327; q=dns/txt; s=iport; t=1303743436; x=1304953036; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=9ZRtSWbXGE92ZwDoNn8VSkALGlmMJF9ri/vxlWZHpFY=; b=dDx1qudOwbZyQXM92SeFeopHg2pAfQdbxkR43JljPjaZJsBxR4sakMAU 2OuYCADlOZWqbrGwpxWHxrz7nRFX/TSefMccMJlGvbhqMMsC7/VMqYp8D vvoweWlLUnQLjnqC6uKOJY+lR4Fnc6J8KhIB/BaJnHvqs0EH0STyfAcFk I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AssHAGGLtU2tJXG9/2dsb2JhbACYDI0od6VmnB2FdgSONYQI X-IronPort-AV: E=Sophos;i="4.64,265,1301875200"; d="scan'208";a="343956519" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by sj-iport-2.cisco.com with ESMTP; 25 Apr 2011 14:57:11 +0000 Received: from [161.44.174.124] (dhcp-161-44-174-124.cisco.com [161.44.174.124]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3PEvBNR021219 for ; Mon, 25 Apr 2011 14:57:11 GMT Message-ID: <4DB58BC7.5090603@cisco.com> Date: Mon, 25 Apr 2011 10:57:11 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 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] RS to CS relationship as an attribute in Recording block X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 25 Apr 2011 14:57:16 -0000 Given all the combinations you cite, I'm inclined to simply plan to accommodate many RS to many CS in all cases. Having to specify which type is to be used when establishing the RS seems like a problem waiting to happen. I think the SRC won't always know, or worse - it will think it knows but turn out to be wrong. Thanks, Paul On 4/25/2011 10:35 AM, Parthasarathi R (partr) wrote: > Hi all, > The context for this attribute is whether globally unique id is required > in each metadata block or whether it is required only in some of the > block only. One of the compelling reason for globally unique id is > because of the complex relationship between RS and CS which is not > currently passed from SRC to SRS. I'm trying to find whether passing the > information will reduce the complexity of globally unique id in some blocks. > In case RS to CS relationship between SRC & SRS, there is a possibility > of three types and they are as follows: > 1) One RS to one CS: Simple mechanism and every CS is directly mapped to > RS. Here, RS needs to be global unique id whereas those block is not > required to be global. > 2) One RS to many CS: > Usecases are as follows: > a) Persistent recording > b) Recording with single CSG > Here as well, RS needs to be global unique id whereas those block is not > required to be global. > 3) Many RS to one CS: > Use case are as follows: > a) start/stop recording session during single CS. > Here. RS needs global unique id as well as CS needs global unique id. > Please note that this mechanism will not co-exist with above two mechanism. > The attribute name is recording_type wherein the value of the attributes > will be > a) one_rs_one_cs > b) one_rs_many_cs > c) many_rs_one_cs > By knowing this attribute, SRS will be able to manage unique-id and its > scope as SRS aware of SRC mechanism. Say in case of one_rs_many_cs SRC, > media stream (MS) will never exceed RS wherein in case of > many_rs_one_cs, MS will never exceed CS and in both scenario, MS is > local to RS or CS. Please let me know whether it is worth to add this > attribute in Metadata model. > Thanks > Partha > > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From partr@cisco.com Tue Apr 26 23:30:43 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 A70B8E06CB for ; Tue, 26 Apr 2011 23:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.805 X-Spam-Level: X-Spam-Status: No, score=-9.805 tagged_above=-999 required=5 tests=[AWL=0.794, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 2UsXLZvdoLI6 for ; Tue, 26 Apr 2011 23:30:39 -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 9B4CEE06C9 for ; Tue, 26 Apr 2011 23:30:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=14437; q=dns/txt; s=iport; t=1303885838; x=1305095438; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=XXsH1Hlm/UwBaAjpIqKYXm0Fso6Txz4CviTHhmYJta0=; b=E5Rg5LKt6fDXoF9wT2QFOTaG6x7FwE8nmnP9AhonYixnRS1axdMaGaa1 gy7AM6pxezz3Df9DZl19JQmw6YJyKDgnvI+Lk/AAykaog6kkJoxR7btZu PevAcOVfwdAopcyxpYUCHGKNSrvlIpd2elelLEApKmfYTuEZj22ZPDwYU Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AusAANK2t02Q/khLgWdsb2JhbACXfo1sFAEBFiYliHCeV5xohXYEhX2MY4oY X-IronPort-AV: E=Sophos;i="4.64,273,1301875200"; d="scan'208";a="85425651" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 27 Apr 2011 06:30:37 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3R6U8NX023347; Wed, 27 Apr 2011 06:30:37 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Apr 2011 12:00:29 +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: Wed, 27 Apr 2011 12:00:28 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Does MS have life outside a particular CS? (was RE: [siprec] comments on draft-ram-siprec-metadata-04) Thread-Index: Acv+pbws7MwochNUSB2j8RZ3ismj6AAAQrXwACiVZgAABfyA0AACLm6QAASWOmAAG+JhEAANxV4AAAViIkAAARvLsAAHbbeQAL8Uv5A= References: <21866C7FE177A4449B9136B5B24B1B130BC011290A@EXMBXCLUS01.citservers.local><21866C7FE177A4449B9136B5B24B1B130BC011294A@EXMBXCLUS01.citservers.local><35BCE99A477D6A4986FB2216D8CF2CFD05DD8C0C@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD05EF92EF@XMB-BGL-417.cisco.com> <4D9CBD8C.4010901@cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD06133966@XMB-BGL-417.cisco.com> <4DAD8A5F.4040506@cisco.com> <4DADA8E6.9010006@cisco.com> <35BCE99A477D 6A49 8 6 F B 2216 D8CF2CFD06133A56@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD06133DD4@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD06133E6B@XMB-BGL-417.cisco.com> From: "Parthasarathi R (partr)" To: "Elwell, John" , "Ram Mohan R (rmohanr)" , "Paul Kyzivat (pkyzivat)" X-OriginalArrivalTime: 27 Apr 2011 06:30:29.0433 (UTC) FILETIME=[9A278290:01CC04A4] Cc: siprec@ietf.org Subject: Re: [siprec] Does MS have life outside a particular CS? (was RE: comments on draft-ram-siprec-metadata-04) X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 27 Apr 2011 06:30:43 -0000 John, My intention is show the complexity in the metadata model in the current form. Global unique id solves the issue but let us explore for better optimized solution with more local unique id if any exists. I have created another mail thread for adding the recording type attribute which helps in most of the metadata blocks to have local unique id rather than global unique id. Let us see how others visualize that attribute.=20 IMO, it may better to have globally unique id with the current metadata model attributes. We may be able to add the normative statement that "Media stream (MS) MUST be terminated when CS is terminated" in the metadata but in reality, MS is within the scope of RS which is forced to delete for no reason. These sort will be restrictive for few SRC implementation. For eg: RS may created MS with RSVP which may not prefer to terminate the resource during RS mid-session changes like CS changes even though intermediate time with no media but the above normative statement forces to break those SRC implementation. Please read inline for more comments. Thanks Partha=20 -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 Sent: Friday, April 22, 2011 1:48 AM To: Parthasarathi R (partr); Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) Cc: siprec@ietf.org Subject: RE: Does MS have life outside a particular CS? (was RE: [siprec] comments on draft-ram-siprec-metadata-04) =20 > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > Sent: 21 April 2011 17:20 > To: Elwell, John; Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > Cc: siprec@ietf.org > Subject: RE: Does MS have life outside a particular CS? (was > RE: [siprec] comments on draft-ram-siprec-metadata-04) >=20 > John, >=20 > Please read inline. >=20 > Thanks > Partha >=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Thursday, April 21, 2011 9:12 PM > To: Parthasarathi R (partr); Ram Mohan R (rmohanr); Paul Kyzivat > (pkyzivat) > Cc: siprec@ietf.org > Subject: RE: Does MS have life outside a particular CS? (was RE: > [siprec] comments on draft-ram-siprec-metadata-04) >=20 > Partha, >=20 > > -----Original Message----- > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > Sent: 21 April 2011 14:25 > > To: Elwell, John; Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > Cc: siprec@ietf.org > > Subject: RE: Does MS have life outside a particular CS? (was > > RE: [siprec] comments on draft-ram-siprec-metadata-04) > >=20 > > John, > >=20 > > I could think of one usecase wherein MS is outside CS but within=20 > > single RS. The usecase is multiple CS within single RS and MS. The=20 > > usecase is as follows: > >=20 > > B2BUA acts as SRC. A, B, C are participants within single B2BUA. A=20 > > creates single RS for a CSG. > >=20 > > 1) A calls B through B2BUA. B2BUA creates RS towards SRS with CSG1,=20 > > CS1, > > MS1 (A's media stream), MS2 (B's media stream), Participant1 as A & > > Participant2 as B. > [JRE] Why two media streams? Why not a single MS, with both A and B=20 > sending and receiving that MS? > The media streams are un-mixed, MS1 points to RTP from A=20 > through label attribute in MS1 SDP, MS2 points to RTP from B through=20 > label attribute in MS2 SDP [JRE] Reading the metadata model again, I think it does seem to imply two Media Stream objects if the two directions for a 2-party call are sent unmixed (as two m-lines in the RS SDP), so I will concede that we have two Media Stream objects here. I had been thinking of a slightly different model, where there is one Media Stream, but associations between the Media Stream and Participants pointed to different m-lines in the RS SDP. >=20 > > 2) B connects with C through B2BUA > > 3) B transfer the call of A & B to C using REFER, B2BUA > converts REFER >=20 > > to RE-INVITE towards A & C and A & C are connected. B2BUA > updates RS > > with CS2, Participant1 as A & participant2 as C, MS1(A's media=20 > > stream), MS2(C's media stream). > [JRE] I would have expected, from my understanding of the metadata=20 > model, that the CS2 would have a new MS, with both A and B sending and > receiving that new MS. >=20 > It is not mandatory because participant information will be=20 > updated and pointing to the same m-line in RS with same label=20 > attribute. > From SRS perspective, the same media stream with the update in the=20 > participant name only. Say MS2 is stored as one record with B as=20 > participant for T0 to T1 timelines and C as participant from T1 to T2. > [JRE] Or alternatively it could be modelled that when a new CS starts there is a new Media Stream object, still pointing to the same m-line in the RS SDP. The purpose of unique-id will go for toss here. The same media stream (MS) has unique id "id1" initially and later it will have "id2" which will not be good for replay. Of course, MS life is always within RS in this scenario but not within CS. So, Unique Id within RS will serve the purpose This would avoid the need for a Media Stream object to survive beyond the lifetime of a CS, and therefore allow local identification. While there is no CS in progress, the m-line would be disabled (port 0) and would not be referenced by any Media Stream. RS m-line is not required to 0 because it shall change into "a=3Dinactive" as well. There is no change in the resource reservation = in both SRC and SRS >=20 > > There is no update on RS1, CSG1, MS1, MS2. MS2 will become MS2 with=20 > > the new association and in terms of format, it will associate with=20 > > tag. > >=20 > > In the above scenario, MS have life outside CS but it is within RS. > [JRE] I can see how it COULD work like that, but it is not intuitive.=20 >=20 > In SIPREC solution, UPDATE message with CS2(session > element) , > participant "C" element are received in SRS. This partial update of=20 > UPDATE helps to make this scenario work. There is no change in term=20 > stream element or RS SDP >=20 > To me, a new CS means the existing media stream stops and a new media=20 > stream is created. >=20 > I'm interested knowing whether you propose that MS MUST stop=20 > in case CS ends and the above scenario is outside the scope of SIPREC? > >=20 > > The > > unique id shall be within RS scope as mentioned in IETF-80 meeting.=20 > > But in another situation, MS is outside the scope of RS but > within CS > > and the usecase is Multiple RS for single CS, details are > as follows: > >=20 > > A, B are pariticipants. A acts as SRC which tear down RS > whenever hold >=20 > > happens & creates new RS when resume happens. > >=20 > > 1) A calls B. A creates RS1 towards SRS with CS1, MS1 (A's media=20 > > stream), MS2 (B's Media stream),Participant1 as A & > Participant2 as B. > [JRE] Again, I would model this as a single MS, to which both A and B=20 > contribute. > Again, unmixed stream from A and B > > 2) A put B on hold. A tear down RS1. > > 3) A resume B. A creates RS2 towards SRS with CS1, MS1 (A's media=20 > > stream), MS2 (B's Media stream),Participant1 as A & > Participant2 as B > >=20 > > Here MS1 & MS2 needs to be same across RS to group media streams=20 > > correctly. Please let me know your opinion here. >=20 > [JRE] Although I disagree that we have two Media Streams here, I do=20 > agree that the single Media Stream could be considered to survive the=20 > hold/resume, and hence survive from RS1 to RS2. But the MS is within=20 > the context of the same CS (CS1), and therefore this is outside the=20 > scope of this particular thread, which is asking whether an MS can=20 > have a life outside a particular CS. In this case the MS continues to=20 > be associated with the CS, so I don't have a problem with that. >=20 > I have 2nd example to illustrate MS have life outside RS. > >=20 > So you have failed to convince me that an MS needs to have a life=20 > outside a CS. >=20 > In case the above scenario-1 way of recording is outside the=20 > scope of SIPREC, I agree with you that MS does not have life outside a > particular CS [JRE] I assume you are talking about the call transfer case. I am not saying that use case is outside the scope of SIPREC. I am just saying that it can be modelled a different way, which may be advantageous in terms of the number of globally unique identifiers needed. John (as individual) >=20 > John (as individual) >=20 >=20 > >=20 > > Having said that MS have life outside a particular CS, I create=20 > > separate thread within unique how it shall be handled. > >=20 > > Thanks > > Partha > >=20 > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Thursday, April 21, 2011 12:01 PM > > To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > Cc: Parthasarathi R (partr); siprec@ietf.org > > Subject: Does MS have life outside a particular CS? (was > RE: [siprec] > > comments on draft-ram-siprec-metadata-04) > >=20 > > =20 > >=20 > > > -----Original Message----- > > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > > Sent: 20 April 2011 18:08 > > > To: Elwell, John; Paul Kyzivat (pkyzivat) > > > Cc: Parthasarathi R (partr); siprec@ietf.org > > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > >=20 > > > Hi John, > > >=20 > > > Please see inline [RAM] > > >=20 > > > > -----Original Message----- > > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > Sent: Wednesday, April 20, 2011 8:19 PM > > > > To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > > > Cc: Parthasarathi R (partr); siprec@ietf.org > > > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > > >=20 > > > >=20 > > > >=20 > > > > > -----Original Message----- > > > > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > > > > Sent: 20 April 2011 14:52 > > > > > To: Elwell, John; Paul Kyzivat (pkyzivat) > > > > > Cc: Parthasarathi R (partr); siprec@ietf.org > > > > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > > > > > > > > > John, > > > > > > > > > > I agree with you that normal cases RS will remain at > > least for the > >=20 > > > > > duration of CS. However it is common to have use cases where > > > > recording > > > > > is done for first few mins of a CS and then stopped, > > > re-started at a > > > > > later point (e.g Recording of a company meeting where > > you may want > > > to > > > > > record only portions of meeting). > > > > > > > > > > In any case, the point I like to high light here is, MS > > > block could > > > > be > > > > > common across RS and even across CS[ due to consult > > > transfer e.t.c]. > > > > > These use cases indicate the need to have a unique ID > > for MS block > >=20 > > > > > (similar to the UUID that we have defined in format) as > > we cannot > > > > > depend on neither CS ID or RS ID. > > > > [JRE] I am having a hard time understanding the concept > > of a single > > > > Media Stream that survives across multiple CSs. For > > example, in the > > > > case of transfer, I would have thought new Media > Streams would be > > > > created. > > >=20 > > > [RAM] > > > Here is my thoughts.=20 > > > 1) There can be multiple RS per CS > > > RS1 --- CS1--MS1 > > > RS2----CS1--MS1 > > > Examples are partial recording of CS (like recording parts > > of meeting, > >=20 > > > redundant recording where there are multiple SRCs recording > > the same > > > CS) > > [JRE] Agreed. In this case MS1 is local to CS1. > >=20 > > >=20 > > > 2) There can be same Media Stream across multiple CS.=20 > > > RS1--- CS1--- MS1 > > > RS2--CS2--MS1 > > > Examples are Multicast MoH played to multiple end points who are=20 > > > potentially part of disjoint CSs where each CS is recorded > > as part of > > > separate RS. > > >=20 > > > Of course the above is arguable where the stream is same or > > different. > > > My view is since the UA (that supplies the Multicast MoH) and its=20 > > > media are same across all CS, I think it can be represented > > as same MS > >=20 > > > block. > > [JRE] I would argue these are different MSs. I agree that a medium=20 > > such as music on hold might be sent, in synch, to multiple=20 > > participants in multiple CSs. In that particular situation > there might >=20 > > be some efficiency saving by calling it the same MS.=20 > However, I would > > suggest (although this is not my field of expertise) it would make=20 > > life a lot harder for the SRS and its database. I would > have expected > > to want to record a complete CS (all its participants and media > > streams) as a complete recording, which could be deleted, > copied, and >=20 > > so on without having to go looking for other objects that complete=20 > > that recording and are shared with other recordings. For > example, if > > you delete a recording, you would want to delete all its > MSs, but not > > those used by other recordings, although you would need a garbage=20 > > collection mechanism to delete an MS recording when it is no longer=20 > > used by any CS recordings. Rather ugly. Making a MS local to a CS=20 > > would simplify all this. > >=20 > > >=20 > > >=20 > > > However it is still possible to treat each as separate > > stream in the > > > model, in which case the information that it is the same MS > > played by > > > a UA to different CS will be lost. I don't know if there is an=20 > > > interest to capture this level of detail and if it is of > any use to > > > SRS. > > [JRE] I assume what you are saying here is not that > information will > > be lost, but that you will be unable to tell, without doing a=20 > > comparison, whether two different MSs played to participants in two=20 > > different CSs are identical or not for the particular time > span that > > is common. I don't see where such a requirement would come from. > >=20 > > John (as individual) > >=20 > >=20 >=20 From john.elwell@siemens-enterprise.com Wed Apr 27 01:00: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 2902AE06D1 for ; Wed, 27 Apr 2011 01:00:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.673 X-Spam-Level: X-Spam-Status: No, score=-104.673 tagged_above=-999 required=5 tests=[AWL=1.926, 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 6iCGV7VhG8-b for ; Wed, 27 Apr 2011 01:00:09 -0700 (PDT) Received: from mail174.messagelabs.com (mail174.messagelabs.com [85.158.138.51]) by ietfa.amsl.com (Postfix) with SMTP id B0474E06CC for ; Wed, 27 Apr 2011 01:00:08 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1303891207!18083482!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 8706 invoked from network); 27 Apr 2011 08:00:07 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-7.tower-174.messagelabs.com with SMTP; 27 Apr 2011 08:00:07 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id C43C41EB83E1; Wed, 27 Apr 2011 10:00:07 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 27 Apr 2011 10:00:08 +0200 From: "Elwell, John" To: Paul Kyzivat , "siprec@ietf.org" Date: Wed, 27 Apr 2011 10:00:05 +0200 Thread-Topic: [siprec] RS to CS relationship as an attribute in Recording block Thread-Index: AcwDWRLgHjT1vcDDTPej6dPykApc6QBV5Sag Message-ID: References: <4DB58BC7.5090603@cisco.com> In-Reply-To: <4DB58BC7.5090603@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] RS to CS relationship as an attribute in Recording block X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 27 Apr 2011 08:00:13 -0000 I agree with Paul. Also, it is not at all clear to me why we need any unique identification fo= r the RS - doesn't the SIP dialog identifier achieve this? The RS is only a= vehicle for delivering one or more recordings (media and metadata) to the = SRS, and once the delivered information is stored for future playback, the = delivery mechanism, i.e., the RS identity, is no longer relevant. However, I have a feeling we have been round this loop before, so apologies= if we came to a resolution. John (as individual) =20 > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 25 April 2011 15:57 > To: siprec@ietf.org > Subject: Re: [siprec] RS to CS relationship as an attribute=20 > in Recording block >=20 > Given all the combinations you cite, I'm inclined to simply plan to=20 > accommodate many RS to many CS in all cases. >=20 > Having to specify which type is to be used when establishing the RS=20 > seems like a problem waiting to happen. I think the SRC won't always=20 > know, or worse - it will think it knows but turn out to be wrong. >=20 > Thanks, > Paul >=20 > On 4/25/2011 10:35 AM, Parthasarathi R (partr) wrote: > > Hi all, > > The context for this attribute is whether globally unique=20 > id is required > > in each metadata block or whether it is required only in some of the > > block only. One of the compelling reason for globally unique id is > > because of the complex relationship between RS and CS which is not > > currently passed from SRC to SRS. I'm trying to find=20 > whether passing the > > information will reduce the complexity of globally unique=20 > id in some blocks. > > In case RS to CS relationship between SRC & SRS, there is a=20 > possibility > > of three types and they are as follows: > > 1) One RS to one CS: Simple mechanism and every CS is=20 > directly mapped to > > RS. Here, RS needs to be global unique id whereas those block is not > > required to be global. > > 2) One RS to many CS: > > Usecases are as follows: > > a) Persistent recording > > b) Recording with single CSG > > Here as well, RS needs to be global unique id whereas those=20 > block is not > > required to be global. > > 3) Many RS to one CS: > > Use case are as follows: > > a) start/stop recording session during single CS. > > Here. RS needs global unique id as well as CS needs global=20 > unique id. > > Please note that this mechanism will not co-exist with=20 > above two mechanism. > > The attribute name is recording_type wherein the value of=20 > the attributes > > will be > > a) one_rs_one_cs > > b) one_rs_many_cs > > c) many_rs_one_cs > > By knowing this attribute, SRS will be able to manage=20 > unique-id and its > > scope as SRS aware of SRC mechanism. Say in case of=20 > one_rs_many_cs SRC, > > media stream (MS) will never exceed RS wherein in case of > > many_rs_one_cs, MS will never exceed CS and in both scenario, MS is > > local to RS or CS. Please let me know whether it is worth=20 > to add this > > attribute in Metadata model. > > Thanks > > Partha > > > > > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > = From john.elwell@siemens-enterprise.com Wed Apr 27 01:00: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 35D68E06D6 for ; Wed, 27 Apr 2011 01:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.712 X-Spam-Level: X-Spam-Status: No, score=-104.712 tagged_above=-999 required=5 tests=[AWL=1.887, 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 djXTUIDY3MYd for ; Wed, 27 Apr 2011 01:00:42 -0700 (PDT) Received: from mail216.messagelabs.com (mail216.messagelabs.com [85.158.143.99]) by ietfa.amsl.com (Postfix) with SMTP id 3C8B1E06CC for ; Wed, 27 Apr 2011 01:00:42 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1303891240!3332462!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 17305 invoked from network); 27 Apr 2011 08:00:40 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-9.tower-216.messagelabs.com with SMTP; 27 Apr 2011 08:00:40 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id D66E023F03DB; Wed, 27 Apr 2011 10:00:40 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 27 Apr 2011 10:00:40 +0200 From: "Elwell, John" To: "Parthasarathi R (partr)" , "Ram Mohan R (rmohanr)" , "Paul Kyzivat (pkyzivat)" Date: Wed, 27 Apr 2011 10:00:39 +0200 Thread-Topic: Does MS have life outside a particular CS? (was RE: [siprec] comments on draft-ram-siprec-metadata-04) Thread-Index: Acv+pbws7MwochNUSB2j8RZ3ismj6AAAQrXwACiVZgAABfyA0AACLm6QAASWOmAAG+JhEAANxV4AAAViIkAAARvLsAAHbbeQAL8Uv5AAVkHQQA== Message-ID: References: <21866C7FE177A4449B9136B5B24B1B130BC011290A@EXMBXCLUS01.citservers.local><21866C7FE177A4449B9136B5B24B1B130BC011294A@EXMBXCLUS01.citservers.local><35BCE99A477D6A4986FB2216D8CF2CFD05DD8C0C@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD05EF92EF@XMB-BGL-417.cisco.com> <4D9CBD8C.4010901@cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD06133966@XMB-BGL-417.cisco.com> <4DAD8A5F.4040506@cisco.com> <4DADA8E6.9010006@cisco.com> <35BCE99A477D 6A49 8 6 F B 2216 D8CF2CFD06133A56@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD06133DD4@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD06133E6B@XMB-BGL-417.cisco.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] Does MS have life outside a particular CS? (was RE: comments on draft-ram-siprec-metadata-04) X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 27 Apr 2011 08:00:44 -0000 Partha, You wrote: " The purpose of unique-id will go for toss here. The same media stream (MS) has unique id "id1" initially and later it will have "id2" which will not be good for replay. Of course, MS life is always within RS in this scenario but not within CS. So, Unique Id within RS will serve the purpose " As far as the recording, and therefore the playback, are concerned, these r= eally are two media streams, belonging to two separate CSs. The fact that t= hey happened to be delivered using the same m-line on the same RS is really= irrelevant to what gets recorded and played back. John (as individual) > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > Sent: 27 April 2011 07:30 > To: Elwell, John; Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > Cc: siprec@ietf.org > Subject: RE: Does MS have life outside a particular CS? (was > RE: [siprec] comments on draft-ram-siprec-metadata-04) > > John, > > My intention is show the complexity in the metadata model in > the current > form. Global unique id solves the issue but let us explore for better > optimized solution with more local unique id if any exists. > > I have created another mail thread for adding the recording type > attribute which helps in most of the metadata blocks to have local > unique id rather than global unique id. Let us see how others > visualize > that attribute. > > IMO, it may better to have globally unique id with the > current metadata > model attributes. We may be able to add the normative statement that > "Media stream (MS) MUST be terminated when CS is terminated" in the > metadata but in reality, MS is within the scope of RS which > is forced to > delete for no reason. These sort will be restrictive for few SRC > implementation. For eg: RS may created MS with RSVP which may > not prefer > to terminate the resource during RS mid-session changes like > CS changes > even though intermediate time with no media but the above normative > statement forces to break those SRC implementation. > > Please read inline for more comments. > > Thanks > Partha > > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Friday, April 22, 2011 1:48 AM > To: Parthasarathi R (partr); Ram Mohan R (rmohanr); Paul Kyzivat > (pkyzivat) > Cc: siprec@ietf.org > Subject: RE: Does MS have life outside a particular CS? (was RE: > [siprec] comments on draft-ram-siprec-metadata-04) > > > > > -----Original Message----- > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > Sent: 21 April 2011 17:20 > > To: Elwell, John; Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > Cc: siprec@ietf.org > > Subject: RE: Does MS have life outside a particular CS? (was > > RE: [siprec] comments on draft-ram-siprec-metadata-04) > > > > John, > > > > Please read inline. > > > > Thanks > > Partha > > > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Thursday, April 21, 2011 9:12 PM > > To: Parthasarathi R (partr); Ram Mohan R (rmohanr); Paul Kyzivat > > (pkyzivat) > > Cc: siprec@ietf.org > > Subject: RE: Does MS have life outside a particular CS? (was RE: > > [siprec] comments on draft-ram-siprec-metadata-04) > > > > Partha, > > > > > -----Original Message----- > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > Sent: 21 April 2011 14:25 > > > To: Elwell, John; Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > > Cc: siprec@ietf.org > > > Subject: RE: Does MS have life outside a particular CS? (was > > > RE: [siprec] comments on draft-ram-siprec-metadata-04) > > > > > > John, > > > > > > I could think of one usecase wherein MS is outside CS but within > > > single RS. The usecase is multiple CS within single RS > and MS. The > > > usecase is as follows: > > > > > > B2BUA acts as SRC. A, B, C are participants within single > B2BUA. A > > > creates single RS for a CSG. > > > > > > 1) A calls B through B2BUA. B2BUA creates RS towards SRS > with CSG1, > > > CS1, > > > MS1 (A's media stream), MS2 (B's media stream), > Participant1 as A & > > > Participant2 as B. > > [JRE] Why two media streams? Why not a single MS, with both A and B > > sending and receiving that MS? > > The media streams are un-mixed, MS1 points to RTP from A > > through label attribute in MS1 SDP, MS2 points to RTP from > B through > > label attribute in MS2 SDP > [JRE] Reading the metadata model again, I think it does seem to imply > two Media Stream objects if the two directions for a 2-party call are > sent unmixed (as two m-lines in the RS SDP), so I will concede that we > have two Media Stream objects here. I had been thinking of a slightly > different model, where there is one Media Stream, but associations > between the Media Stream and Participants pointed to different m-lines > in the RS SDP. > > > > > > 2) B connects with C through B2BUA > > > 3) B transfer the call of A & B to C using REFER, B2BUA > > converts REFER > > > > > to RE-INVITE towards A & C and A & C are connected. B2BUA > > updates RS > > > with CS2, Participant1 as A & participant2 as C, MS1(A's media > > > stream), MS2(C's media stream). > > [JRE] I would have expected, from my understanding of the metadata > > model, that the CS2 would have a new MS, with both A and B > sending and > > > receiving that new MS. > > > > It is not mandatory because participant > information will be > > updated and pointing to the same m-line in RS with same label > > attribute. > > From SRS perspective, the same media stream with the update in the > > participant name only. Say MS2 is stored as one record with B as > > participant for T0 to T1 timelines and C as participant > from T1 to T2. > > > [JRE] Or alternatively it could be modelled that when a new CS starts > there is a new Media Stream object, still pointing to the > same m-line in > the RS SDP. > > The purpose of unique-id will go for toss here. The > same media > stream (MS) has unique id "id1" initially and later it will have "id2" > which will not be good for replay. Of course, MS life is always within > RS in this scenario but not within CS. So, Unique Id within RS will > serve the purpose > > This would avoid the need for a Media Stream object to survive beyond > the lifetime of a CS, and therefore allow local identification. While > there is no CS in progress, the m-line would be disabled (port 0) and > would not be referenced by any Media Stream. > > RS m-line is not required to 0 because it shall change into > "a=3Dinactive" as well. There is no change in the resource > reservation in > both SRC and SRS > > > > > > There is no update on RS1, CSG1, MS1, MS2. MS2 will > become MS2 with > > > the new association and in terms of format, it will > associate with > > > tag. > > > > > > In the above scenario, MS have life outside CS but it is > within RS. > > [JRE] I can see how it COULD work like that, but it is not > intuitive. > > > > In SIPREC solution, UPDATE message with CS2(session > > element) , > > participant "C" element are received in SRS. This partial update of > > UPDATE helps to make this scenario work. There is no change in term > > stream element or RS SDP > > > > To me, a new CS means the existing media stream stops and a > new media > > stream is created. > > > > I'm interested knowing whether you propose that MS > MUST stop > > in case CS ends and the above scenario is outside the scope > of SIPREC? > > > > > > > The > > > unique id shall be within RS scope as mentioned in > IETF-80 meeting. > > > But in another situation, MS is outside the scope of RS but > > within CS > > > and the usecase is Multiple RS for single CS, details are > > as follows: > > > > > > A, B are pariticipants. A acts as SRC which tear down RS > > whenever hold > > > > > happens & creates new RS when resume happens. > > > > > > 1) A calls B. A creates RS1 towards SRS with CS1, MS1 (A's media > > > stream), MS2 (B's Media stream),Participant1 as A & > > Participant2 as B. > > [JRE] Again, I would model this as a single MS, to which > both A and B > > contribute. > > Again, unmixed stream from A and B > > > 2) A put B on hold. A tear down RS1. > > > 3) A resume B. A creates RS2 towards SRS with CS1, MS1 (A's media > > > stream), MS2 (B's Media stream),Participant1 as A & > > Participant2 as B > > > > > > Here MS1 & MS2 needs to be same across RS to group media streams > > > correctly. Please let me know your opinion here. > > > > [JRE] Although I disagree that we have two Media Streams here, I do > > agree that the single Media Stream could be considered to > survive the > > hold/resume, and hence survive from RS1 to RS2. But the MS > is within > > the context of the same CS (CS1), and therefore this is outside the > > scope of this particular thread, which is asking whether an MS can > > have a life outside a particular CS. In this case the MS > continues to > > be associated with the CS, so I don't have a problem with that. > > > > I have 2nd example to illustrate MS have life outside RS. > > > > > > So you have failed to convince me that an MS needs to have a life > > outside a CS. > > > > In case the above scenario-1 way of recording is > outside the > > scope of SIPREC, I agree with you that MS does not have > life outside a > > > particular CS > [JRE] I assume you are talking about the call transfer case. I am not > saying that use case is outside the scope of SIPREC. I am just saying > that it can be modelled a different way, which may be advantageous in > terms of the number of globally unique identifiers needed. > > > John (as individual) > > > > > > > John (as individual) > > > > > > > > > > Having said that MS have life outside a particular CS, I create > > > separate thread within unique how it shall be handled. > > > > > > Thanks > > > Partha > > > > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > Sent: Thursday, April 21, 2011 12:01 PM > > > To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > > Cc: Parthasarathi R (partr); siprec@ietf.org > > > Subject: Does MS have life outside a particular CS? (was > > RE: [siprec] > > > comments on draft-ram-siprec-metadata-04) > > > > > > > > > > > > > -----Original Message----- > > > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > > > Sent: 20 April 2011 18:08 > > > > To: Elwell, John; Paul Kyzivat (pkyzivat) > > > > Cc: Parthasarathi R (partr); siprec@ietf.org > > > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > > > > > > > Hi John, > > > > > > > > Please see inline [RAM] > > > > > > > > > -----Original Message----- > > > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > > Sent: Wednesday, April 20, 2011 8:19 PM > > > > > To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > > > > Cc: Parthasarathi R (partr); siprec@ietf.org > > > > > Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > > > > > Sent: 20 April 2011 14:52 > > > > > > To: Elwell, John; Paul Kyzivat (pkyzivat) > > > > > > Cc: Parthasarathi R (partr); siprec@ietf.org > > > > > > Subject: RE: [siprec] comments on > draft-ram-siprec-metadata-04 > > > > > > > > > > > > John, > > > > > > > > > > > > I agree with you that normal cases RS will remain at > > > least for the > > > > > > > > > duration of CS. However it is common to have use cases where > > > > > recording > > > > > > is done for first few mins of a CS and then stopped, > > > > re-started at a > > > > > > later point (e.g Recording of a company meeting where > > > you may want > > > > to > > > > > > record only portions of meeting). > > > > > > > > > > > > In any case, the point I like to high light here is, MS > > > > block could > > > > > be > > > > > > common across RS and even across CS[ due to consult > > > > transfer e.t.c]. > > > > > > These use cases indicate the need to have a unique ID > > > for MS block > > > > > > > > > (similar to the UUID that we have defined in format) as > > > we cannot > > > > > > depend on neither CS ID or RS ID. > > > > > [JRE] I am having a hard time understanding the concept > > > of a single > > > > > Media Stream that survives across multiple CSs. For > > > example, in the > > > > > case of transfer, I would have thought new Media > > Streams would be > > > > > created. > > > > > > > > [RAM] > > > > Here is my thoughts. > > > > 1) There can be multiple RS per CS > > > > RS1 --- CS1--MS1 > > > > RS2----CS1--MS1 > > > > Examples are partial recording of CS (like recording parts > > > of meeting, > > > > > > > redundant recording where there are multiple SRCs recording > > > the same > > > > CS) > > > [JRE] Agreed. In this case MS1 is local to CS1. > > > > > > > > > > > 2) There can be same Media Stream across multiple CS. > > > > RS1--- CS1--- MS1 > > > > RS2--CS2--MS1 > > > > Examples are Multicast MoH played to multiple end > points who are > > > > potentially part of disjoint CSs where each CS is recorded > > > as part of > > > > separate RS. > > > > > > > > Of course the above is arguable where the stream is same or > > > different. > > > > My view is since the UA (that supplies the Multicast > MoH) and its > > > > media are same across all CS, I think it can be represented > > > as same MS > > > > > > > block. > > > [JRE] I would argue these are different MSs. I agree that > a medium > > > such as music on hold might be sent, in synch, to multiple > > > participants in multiple CSs. In that particular situation > > there might > > > > > be some efficiency saving by calling it the same MS. > > However, I would > > > suggest (although this is not my field of expertise) it > would make > > > life a lot harder for the SRS and its database. I would > > have expected > > > to want to record a complete CS (all its participants and media > > > streams) as a complete recording, which could be deleted, > > copied, and > > > > > so on without having to go looking for other objects that > complete > > > that recording and are shared with other recordings. For > > example, if > > > you delete a recording, you would want to delete all its > > MSs, but not > > > those used by other recordings, although you would need a garbage > > > collection mechanism to delete an MS recording when it is > no longer > > > used by any CS recordings. Rather ugly. Making a MS local to a CS > > > would simplify all this. > > > > > > > > > > > > > > > However it is still possible to treat each as separate > > > stream in the > > > > model, in which case the information that it is the same MS > > > played by > > > > a UA to different CS will be lost. I don't know if there is an > > > > interest to capture this level of detail and if it is of > > any use to > > > > SRS. > > > [JRE] I assume what you are saying here is not that > > information will > > > be lost, but that you will be unable to tell, without doing a > > > comparison, whether two different MSs played to > participants in two > > > different CSs are identical or not for the particular time > > span that > > > is common. I don't see where such a requirement would come from. > > > > > > John (as individual) > > > > > > > > > From Leon.Portman@nice.com Wed Apr 27 05:50: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 12BF3E0742 for ; Wed, 27 Apr 2011 05:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Qrx1tbm1Tjp for ; Wed, 27 Apr 2011 05:50:28 -0700 (PDT) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id 61015E06E0 for ; Wed, 27 Apr 2011 05:50:28 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Wed, 27 Apr 2011 15:50:26 +0300 From: Leon Portman To: "Elwell, John" , Paul Kyzivat , "siprec@ietf.org" Date: Wed, 27 Apr 2011 15:50:25 +0300 Thread-Topic: [siprec] RS to CS relationship as an attribute in Recording block Thread-Index: AcwDWRLgHjT1vcDDTPej6dPykApc6QBV5SagAAozkoA= Message-ID: <07465C1D981ABC41A344374066AE1A2C38AB7A1BAB@TLVMBX01.nice.com> References: <4DB58BC7.5090603@cisco.com> In-Reply-To: Accept-Language: en-US, he-IL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, he-IL Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] RS to CS relationship as an attribute in Recording block X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 27 Apr 2011 12:50:33 -0000 I agree with Paul and John. Lets handle the complex case. And I also agree = that RS identity is not important. We have agreed that post CS updating of = metadata is out of scope Leon -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Elwell, John Sent: Wednesday, April 27, 2011 11:00 AM To: Paul Kyzivat; siprec@ietf.org Subject: Re: [siprec] RS to CS relationship as an attribute in Recording bl= ock I agree with Paul. Also, it is not at all clear to me why we need any unique identification fo= r the RS - doesn't the SIP dialog identifier achieve this? The RS is only a= vehicle for delivering one or more recordings (media and metadata) to the = SRS, and once the delivered information is stored for future playback, the = delivery mechanism, i.e., the RS identity, is no longer relevant. However, I have a feeling we have been round this loop before, so apologies= if we came to a resolution. John (as individual) =20 > -----Original Message----- > From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 25 April 2011 15:57 > To: siprec@ietf.org > Subject: Re: [siprec] RS to CS relationship as an attribute in=20 > Recording block >=20 > Given all the combinations you cite, I'm inclined to simply plan to=20 > accommodate many RS to many CS in all cases. >=20 > Having to specify which type is to be used when establishing the RS=20 > seems like a problem waiting to happen. I think the SRC won't always=20 > know, or worse - it will think it knows but turn out to be wrong. >=20 > Thanks, > Paul >=20 > On 4/25/2011 10:35 AM, Parthasarathi R (partr) wrote: > > Hi all, > > The context for this attribute is whether globally unique > id is required > > in each metadata block or whether it is required only in some of the=20 > > block only. One of the compelling reason for globally unique id is=20 > > because of the complex relationship between RS and CS which is not=20 > > currently passed from SRC to SRS. I'm trying to find > whether passing the > > information will reduce the complexity of globally unique > id in some blocks. > > In case RS to CS relationship between SRC & SRS, there is a > possibility > > of three types and they are as follows: > > 1) One RS to one CS: Simple mechanism and every CS is > directly mapped to > > RS. Here, RS needs to be global unique id whereas those block is not=20 > > required to be global. > > 2) One RS to many CS: > > Usecases are as follows: > > a) Persistent recording > > b) Recording with single CSG > > Here as well, RS needs to be global unique id whereas those > block is not > > required to be global. > > 3) Many RS to one CS: > > Use case are as follows: > > a) start/stop recording session during single CS. > > Here. RS needs global unique id as well as CS needs global > unique id. > > Please note that this mechanism will not co-exist with > above two mechanism. > > The attribute name is recording_type wherein the value of > the attributes > > will be > > a) one_rs_one_cs > > b) one_rs_many_cs > > c) many_rs_one_cs > > By knowing this attribute, SRS will be able to manage > unique-id and its > > scope as SRS aware of SRC mechanism. Say in case of > one_rs_many_cs SRC, > > media stream (MS) will never exceed RS wherein in case of=20 > > many_rs_one_cs, MS will never exceed CS and in both scenario, MS is=20 > > local to RS or CS. Please let me know whether it is worth > to add this > > attribute in Metadata model. > > Thanks > > Partha > > > > > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec >=20 _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From Leon.Portman@nice.com Wed Apr 27 06:30:26 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 D3D3BE06EC for ; Wed, 27 Apr 2011 06:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 yWlM++3Lmn-8 for ; Wed, 27 Apr 2011 06:30:25 -0700 (PDT) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id C0C3CE06DD for ; Wed, 27 Apr 2011 06:30:24 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Wed, 27 Apr 2011 16:30:23 +0300 From: Leon Portman To: "siprec@ietf.org" , "Ken Rehor (krehor) (krehor@cisco.com)" , "Elwell, John" Date: Wed, 27 Apr 2011 16:30:23 +0300 Thread-Topic: [siprec] Summary of the changes of draft-ietf-siprec-req-10 - last call Thread-Index: AcwE3y4TqEYV7EYpTvCzQYc4dfJgQw== Message-ID: <07465C1D981ABC41A344374066AE1A2C38AB7A1BEB@TLVMBX01.nice.com> Accept-Language: en-US, he-IL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, he-IL Content-Type: multipart/alternative; boundary="_000_07465C1D981ABC41A344374066AE1A2C38AB7A1BEBTLVMBX01nicec_" MIME-Version: 1.0 Subject: [siprec] Summary of the changes of draft-ietf-siprec-req-10 - last call X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 27 Apr 2011 13:30:27 -0000 --_000_07465C1D981ABC41A344374066AE1A2C38AB7A1BEBTLVMBX01nicec_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Please see below summary of the changes for updated version of the require= ments document. Main changes: 1. Updated REQ-022, 023, 024 (all other numbers are ++, original 22 a= nd 23 removed), thanks to Muthu and John for the text a. REQ-022: The mechanism MUST provide means for facilitating synchro= nization of the recorded media streams and metadata. b. REQ-023: The mechanism MUST provide means for facilitating synchron= ization among the recorded media streams. c. REQ-024: The mechanism MUST provide means for relating recordings = to wall clock time. 2. Use Case 8 - nit pick, thanks to Muthu (me -> may be) a."In cases where calls inside or between branches must be recorded, a cent= ralized recording system in data centers together with telephony infrastruc= ture (e.g. PBX) may be deployed." 3. Proposed additional paragraph in the security section fr= om the security review (not in the text yet, pending WG approval): "Integrity and correctness of the recorded sessions is not ensured by crypt= ographic means to ensure that the CS has not been tampered with. This would= have to be done by organizational and technical controls that prevent tamp= ering with CS participants and SRC." Regards Leon --_000_07465C1D981ABC41A344374066AE1A2C38AB7A1BEBTLVMBX01nicec_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello=

 

Please s= ee below summary of the changes for  updated version of the requiremen= ts document.

 

Main changes:

 =

1.  &n= bsp;    Updat= ed REQ-022, 023, 024 (all other numbers are ++, original 22 and 23 removed)= , thanks to Muthu and John for the text

a.       REQ-022: The mechanism MUST provide mean= s for facilitating synchronization of the recorded media streams and metada= ta.

b. &nbs= p;    REQ-023= : The mechanism MUST provide means for facilitating synchronization among t= he recorded media streams.

c.       <= span dir=3DLTR>REQ-024: The mechanism MUST provide means for relatin= g recordings to wall clock time.

2. Use Case 8 – nit pick, thanks to Muthu (m= e -> may be)

a."In cases where calls inside or between b= ranches must be recorded, a centralized recording system in data centers to= gether with telephony infrastructure (e.g. PBX) may be deployed."=

       = ;         3. Proposed additional pa= ragraph in the security section from the security review (not in the text y= et, pending WG approval):

"Integ= rity and correctness of the recorded sessions is not ensured by cryptograph= ic means to ensure that the CS has not been tampered with. This would have = to be done by organizational and technical controls that prevent tampering = with CS participants and SRC."

<= o:p> 

Regards

 

Leon

 

 

 

= --_000_07465C1D981ABC41A344374066AE1A2C38AB7A1BEBTLVMBX01nicec_-- From pkyzivat@cisco.com Wed Apr 27 06:52: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 16C9EE0766 for ; Wed, 27 Apr 2011 06:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.469 X-Spam-Level: X-Spam-Status: No, score=-110.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 OGl5qnMAWgYr for ; Wed, 27 Apr 2011 06:52:11 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id D4265E0733 for ; Wed, 27 Apr 2011 06:52:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=15540; q=dns/txt; s=iport; t=1303912331; x=1305121931; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=b8Yxz8Nys3h64fbJc9PpKHAo1ByvRggS6cTm2O9Zxfs=; b=NLi6llwtbSbw4JD4iNw7TwxCIUwImXVi/vFGPI640oiN7UoGF4635Fmk dzSeeWxkGbREdo2NFQGOZF2cYJs+9LXPgzqxlDg3pCxwwGo/nw7s/yybF 7nPGtyszJOnj8tzDdWmmpWExVz0eS5G0PPbXZ+CPxIWBY0BpHQjK7a8ga U=; X-IronPort-AV: E=Sophos;i="4.64,274,1301875200"; d="scan'208";a="437362584" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by sj-iport-1.cisco.com with ESMTP; 27 Apr 2011 13:52:11 +0000 Received: from [161.44.174.124] (dhcp-161-44-174-124.cisco.com [161.44.174.124]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3RDqAkN024778; Wed, 27 Apr 2011 13:52:10 GMT Message-ID: <4DB81F8A.8000306@cisco.com> Date: Wed, 27 Apr 2011 09:52:10 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Parthasarathi R (partr)" References: <4DAD8A5F.4040506@cisco.com> <4DADA8E6.9010006@cisco.com> <35BCE99A477D 6A49 8 6 F B 2216 D8CF2CFD06133A56@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD06133DD4@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD06133E6B@XMB-BGL-417.cisco.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] Does MS have life outside a particular CS? (was RE: comments on draft-ram-siprec-metadata-04) X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 27 Apr 2011 13:52:16 -0000 There seems to be some confusion in this discussion about what a MS is. On one hand there is an m-line in the SDP of the RS, and a corresponding RTP stream. On another hand there is an m-line in a CS and a corresponding RTP stream. And then there is an MS described in the metadata conveyed over the RS. And for both of the above, a single m-line might correspond to different RTP streams over time, due to renegotiating the address and/or port of the recipient, or by a different sender sending to the same port. There is a mapping between one or more RTP streams in the CS (or multiple CSs?) and one or more RTP streams in the RS. The metadata hopefully describes that mapping. But perhaps we don't have full agreement on what sorts of mappings are possible. Some that I think we allow are: - one CS RTP stream to one RS RTP stream. - multiple concurrent CS RTP streams mixed to one RS RTP stream - multiple CS RTP streams sequentially mapped to the same RS RTP stream ... Presumably the RTP streams associated with the RS end when the RS ends. That does not necessarily mean that the media stream of a CS also ends at that time. It could be picked up again in a different RS by the same or different SRC. Thanks, Paul On 4/27/2011 2:30 AM, Parthasarathi R (partr) wrote: > John, > > My intention is show the complexity in the metadata model in the current > form. Global unique id solves the issue but let us explore for better > optimized solution with more local unique id if any exists. > > I have created another mail thread for adding the recording type > attribute which helps in most of the metadata blocks to have local > unique id rather than global unique id. Let us see how others visualize > that attribute. > > IMO, it may better to have globally unique id with the current metadata > model attributes. We may be able to add the normative statement that > "Media stream (MS) MUST be terminated when CS is terminated" in the > metadata but in reality, MS is within the scope of RS which is forced to > delete for no reason. These sort will be restrictive for few SRC > implementation. For eg: RS may created MS with RSVP which may not prefer > to terminate the resource during RS mid-session changes like CS changes > even though intermediate time with no media but the above normative > statement forces to break those SRC implementation. > > Please read inline for more comments. > > Thanks > Partha > > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Friday, April 22, 2011 1:48 AM > To: Parthasarathi R (partr); Ram Mohan R (rmohanr); Paul Kyzivat > (pkyzivat) > Cc: siprec@ietf.org > Subject: RE: Does MS have life outside a particular CS? (was RE: > [siprec] comments on draft-ram-siprec-metadata-04) > > > >> -----Original Message----- >> From: Parthasarathi R (partr) [mailto:partr@cisco.com] >> Sent: 21 April 2011 17:20 >> To: Elwell, John; Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) >> Cc: siprec@ietf.org >> Subject: RE: Does MS have life outside a particular CS? (was >> RE: [siprec] comments on draft-ram-siprec-metadata-04) >> >> John, >> >> Please read inline. >> >> Thanks >> Partha >> >> -----Original Message----- >> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >> Sent: Thursday, April 21, 2011 9:12 PM >> To: Parthasarathi R (partr); Ram Mohan R (rmohanr); Paul Kyzivat >> (pkyzivat) >> Cc: siprec@ietf.org >> Subject: RE: Does MS have life outside a particular CS? (was RE: >> [siprec] comments on draft-ram-siprec-metadata-04) >> >> Partha, >> >>> -----Original Message----- >>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] >>> Sent: 21 April 2011 14:25 >>> To: Elwell, John; Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) >>> Cc: siprec@ietf.org >>> Subject: RE: Does MS have life outside a particular CS? (was >>> RE: [siprec] comments on draft-ram-siprec-metadata-04) >>> >>> John, >>> >>> I could think of one usecase wherein MS is outside CS but within >>> single RS. The usecase is multiple CS within single RS and MS. The >>> usecase is as follows: >>> >>> B2BUA acts as SRC. A, B, C are participants within single B2BUA. A >>> creates single RS for a CSG. >>> >>> 1) A calls B through B2BUA. B2BUA creates RS towards SRS with CSG1, >>> CS1, >>> MS1 (A's media stream), MS2 (B's media stream), Participant1 as A& >>> Participant2 as B. >> [JRE] Why two media streams? Why not a single MS, with both A and B >> sending and receiving that MS? >> The media streams are un-mixed, MS1 points to RTP from A >> through label attribute in MS1 SDP, MS2 points to RTP from B through >> label attribute in MS2 SDP > [JRE] Reading the metadata model again, I think it does seem to imply > two Media Stream objects if the two directions for a 2-party call are > sent unmixed (as two m-lines in the RS SDP), so I will concede that we > have two Media Stream objects here. I had been thinking of a slightly > different model, where there is one Media Stream, but associations > between the Media Stream and Participants pointed to different m-lines > in the RS SDP. > >> >>> 2) B connects with C through B2BUA >>> 3) B transfer the call of A& B to C using REFER, B2BUA >> converts REFER >> >>> to RE-INVITE towards A& C and A& C are connected. B2BUA >> updates RS >>> with CS2, Participant1 as A& participant2 as C, MS1(A's media >>> stream), MS2(C's media stream). >> [JRE] I would have expected, from my understanding of the metadata >> model, that the CS2 would have a new MS, with both A and B sending and > >> receiving that new MS. >> >> It is not mandatory because participant information will be >> updated and pointing to the same m-line in RS with same label >> attribute. >> From SRS perspective, the same media stream with the update in the >> participant name only. Say MS2 is stored as one record with B as >> participant for T0 to T1 timelines and C as participant from T1 to T2. >> > [JRE] Or alternatively it could be modelled that when a new CS starts > there is a new Media Stream object, still pointing to the same m-line in > the RS SDP. > > The purpose of unique-id will go for toss here. The same media > stream (MS) has unique id "id1" initially and later it will have "id2" > which will not be good for replay. Of course, MS life is always within > RS in this scenario but not within CS. So, Unique Id within RS will > serve the purpose > > This would avoid the need for a Media Stream object to survive beyond > the lifetime of a CS, and therefore allow local identification. While > there is no CS in progress, the m-line would be disabled (port 0) and > would not be referenced by any Media Stream. > > RS m-line is not required to 0 because it shall change into > "a=inactive" as well. There is no change in the resource reservation in > both SRC and SRS > >> >>> There is no update on RS1, CSG1, MS1, MS2. MS2 will become MS2 with >>> the new association and in terms of format, it will associate with >>> tag. >>> >>> In the above scenario, MS have life outside CS but it is within RS. >> [JRE] I can see how it COULD work like that, but it is not intuitive. >> >> In SIPREC solution, UPDATE message with CS2(session >> element) , >> participant "C" element are received in SRS. This partial update of >> UPDATE helps to make this scenario work. There is no change in term >> stream element or RS SDP >> >> To me, a new CS means the existing media stream stops and a new media >> stream is created. >> >> I'm interested knowing whether you propose that MS MUST stop >> in case CS ends and the above scenario is outside the scope of SIPREC? >> >> >>> The >>> unique id shall be within RS scope as mentioned in IETF-80 meeting. >>> But in another situation, MS is outside the scope of RS but >> within CS >>> and the usecase is Multiple RS for single CS, details are >> as follows: >>> >>> A, B are pariticipants. A acts as SRC which tear down RS >> whenever hold >> >>> happens& creates new RS when resume happens. >>> >>> 1) A calls B. A creates RS1 towards SRS with CS1, MS1 (A's media >>> stream), MS2 (B's Media stream),Participant1 as A& >> Participant2 as B. >> [JRE] Again, I would model this as a single MS, to which both A and B >> contribute. >> Again, unmixed stream from A and B >>> 2) A put B on hold. A tear down RS1. >>> 3) A resume B. A creates RS2 towards SRS with CS1, MS1 (A's media >>> stream), MS2 (B's Media stream),Participant1 as A& >> Participant2 as B >>> >>> Here MS1& MS2 needs to be same across RS to group media streams >>> correctly. Please let me know your opinion here. >> >> [JRE] Although I disagree that we have two Media Streams here, I do >> agree that the single Media Stream could be considered to survive the >> hold/resume, and hence survive from RS1 to RS2. But the MS is within >> the context of the same CS (CS1), and therefore this is outside the >> scope of this particular thread, which is asking whether an MS can >> have a life outside a particular CS. In this case the MS continues to >> be associated with the CS, so I don't have a problem with that. >> >> I have 2nd example to illustrate MS have life outside RS. >> >> >> So you have failed to convince me that an MS needs to have a life >> outside a CS. >> >> In case the above scenario-1 way of recording is outside the >> scope of SIPREC, I agree with you that MS does not have life outside a > >> particular CS > [JRE] I assume you are talking about the call transfer case. I am not > saying that use case is outside the scope of SIPREC. I am just saying > that it can be modelled a different way, which may be advantageous in > terms of the number of globally unique identifiers needed. > > > John (as individual) > > > >> >> John (as individual) >> >> >>> >>> Having said that MS have life outside a particular CS, I create >>> separate thread within unique how it shall be handled. >>> >>> Thanks >>> Partha >>> >>> -----Original Message----- >>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>> Sent: Thursday, April 21, 2011 12:01 PM >>> To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) >>> Cc: Parthasarathi R (partr); siprec@ietf.org >>> Subject: Does MS have life outside a particular CS? (was >> RE: [siprec] >>> comments on draft-ram-siprec-metadata-04) >>> >>> >>> >>>> -----Original Message----- >>>> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] >>>> Sent: 20 April 2011 18:08 >>>> To: Elwell, John; Paul Kyzivat (pkyzivat) >>>> Cc: Parthasarathi R (partr); siprec@ietf.org >>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 >>>> >>>> Hi John, >>>> >>>> Please see inline [RAM] >>>> >>>>> -----Original Message----- >>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>>>> Sent: Wednesday, April 20, 2011 8:19 PM >>>>> To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) >>>>> Cc: Parthasarathi R (partr); siprec@ietf.org >>>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] >>>>>> Sent: 20 April 2011 14:52 >>>>>> To: Elwell, John; Paul Kyzivat (pkyzivat) >>>>>> Cc: Parthasarathi R (partr); siprec@ietf.org >>>>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 >>>>>> >>>>>> John, >>>>>> >>>>>> I agree with you that normal cases RS will remain at >>> least for the >>> >>>>>> duration of CS. However it is common to have use cases where >>>>> recording >>>>>> is done for first few mins of a CS and then stopped, >>>> re-started at a >>>>>> later point (e.g Recording of a company meeting where >>> you may want >>>> to >>>>>> record only portions of meeting). >>>>>> >>>>>> In any case, the point I like to high light here is, MS >>>> block could >>>>> be >>>>>> common across RS and even across CS[ due to consult >>>> transfer e.t.c]. >>>>>> These use cases indicate the need to have a unique ID >>> for MS block >>> >>>>>> (similar to the UUID that we have defined in format) as >>> we cannot >>>>>> depend on neither CS ID or RS ID. >>>>> [JRE] I am having a hard time understanding the concept >>> of a single >>>>> Media Stream that survives across multiple CSs. For >>> example, in the >>>>> case of transfer, I would have thought new Media >> Streams would be >>>>> created. >>>> >>>> [RAM] >>>> Here is my thoughts. >>>> 1) There can be multiple RS per CS >>>> RS1 --- CS1--MS1 >>>> RS2----CS1--MS1 >>>> Examples are partial recording of CS (like recording parts >>> of meeting, >>> >>>> redundant recording where there are multiple SRCs recording >>> the same >>>> CS) >>> [JRE] Agreed. In this case MS1 is local to CS1. >>> >>>> >>>> 2) There can be same Media Stream across multiple CS. >>>> RS1--- CS1--- MS1 >>>> RS2--CS2--MS1 >>>> Examples are Multicast MoH played to multiple end points who are >>>> potentially part of disjoint CSs where each CS is recorded >>> as part of >>>> separate RS. >>>> >>>> Of course the above is arguable where the stream is same or >>> different. >>>> My view is since the UA (that supplies the Multicast MoH) and its >>>> media are same across all CS, I think it can be represented >>> as same MS >>> >>>> block. >>> [JRE] I would argue these are different MSs. I agree that a medium >>> such as music on hold might be sent, in synch, to multiple >>> participants in multiple CSs. In that particular situation >> there might >> >>> be some efficiency saving by calling it the same MS. >> However, I would >>> suggest (although this is not my field of expertise) it would make >>> life a lot harder for the SRS and its database. I would >> have expected >>> to want to record a complete CS (all its participants and media >>> streams) as a complete recording, which could be deleted, >> copied, and >> >>> so on without having to go looking for other objects that complete >>> that recording and are shared with other recordings. For >> example, if >>> you delete a recording, you would want to delete all its >> MSs, but not >>> those used by other recordings, although you would need a garbage >>> collection mechanism to delete an MS recording when it is no longer >>> used by any CS recordings. Rather ugly. Making a MS local to a CS >>> would simplify all this. >>> >>>> >>>> >>>> However it is still possible to treat each as separate >>> stream in the >>>> model, in which case the information that it is the same MS >>> played by >>>> a UA to different CS will be lost. I don't know if there is an >>>> interest to capture this level of detail and if it is of >> any use to >>>> SRS. >>> [JRE] I assume what you are saying here is not that >> information will >>> be lost, but that you will be unable to tell, without doing a >>> comparison, whether two different MSs played to participants in two >>> different CSs are identical or not for the particular time >> span that >>> is common. I don't see where such a requirement would come from. >>> >>> John (as individual) >>> >>> >> > From pkyzivat@cisco.com Wed Apr 27 06:57: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 8FB86E0704 for ; Wed, 27 Apr 2011 06:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.481 X-Spam-Level: X-Spam-Status: No, score=-110.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 cvRtCJQSlVYN for ; Wed, 27 Apr 2011 06:57:48 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 49D81E0679 for ; Wed, 27 Apr 2011 06:57:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=4004; q=dns/txt; s=iport; t=1303912668; x=1305122268; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=F7lff3Hl/8PZA8bdenXGcMCuNksry25eRxe+Ve41IWk=; b=UHo0a40q6KBcBvFHJVfCtqIbBX/LfjPjSkpwiD3Gi1gUzA2YdZyzpwgf BpimqZCPeI1LMlfyIjY3p/q+Elqk+cQiXyZF5Uyr0DMhyvbjkdlp5Jzu7 ARuUPHka52MDNQ81jbQgfgpEFRGj3ngsKR1SgU0+cOsINi23ziXbOxeus M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFQguE2tJXG+/2dsb2JhbACla3eIcJ4FnHKDAIJ2BI5RhBKKNg X-IronPort-AV: E=Sophos;i="4.64,274,1301875200"; d="scan'208";a="687996527" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by sj-iport-6.cisco.com with ESMTP; 27 Apr 2011 13:57:47 +0000 Received: from [161.44.174.124] (dhcp-161-44-174-124.cisco.com [161.44.174.124]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3RDvkcc023203; Wed, 27 Apr 2011 13:57:47 GMT Message-ID: <4DB820DA.1080200@cisco.com> Date: Wed, 27 Apr 2011 09:57:46 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Elwell, John" References: <4DB58BC7.5090603@cisco.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] RS to CS relationship as an attribute in Recording block X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 27 Apr 2011 13:57:52 -0000 On 4/27/2011 4:00 AM, Elwell, John wrote: > I agree with Paul. > > Also, it is not at all clear to me why we need any unique identification for the RS - doesn't the SIP dialog identifier achieve this? The RS is only a vehicle for delivering one or more recordings (media and metadata) to the SRS, and once the delivered information is stored for future playback, the delivery mechanism, i.e., the RS identity, is no longer relevant. I don't think we *need* explicit metadata for the RS. But I think the SRS will want to keep track of where it got the various pieces of data and metadata it receives and records. It could capture basic info from the SIP dialog for that purpose. But it might be useful for the SRC to be able to transmit additional data about itself and its reason for establishing the RS. Perhaps that is all "extension data", but I think its useful to have some mechanism in place to transmit it. Thanks, Paul > However, I have a feeling we have been round this loop before, so apologies if we came to a resolution. > > John (as individual) > >> -----Original Message----- >> From: siprec-bounces@ietf.org >> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: 25 April 2011 15:57 >> To: siprec@ietf.org >> Subject: Re: [siprec] RS to CS relationship as an attribute >> in Recording block >> >> Given all the combinations you cite, I'm inclined to simply plan to >> accommodate many RS to many CS in all cases. >> >> Having to specify which type is to be used when establishing the RS >> seems like a problem waiting to happen. I think the SRC won't always >> know, or worse - it will think it knows but turn out to be wrong. >> >> Thanks, >> Paul >> >> On 4/25/2011 10:35 AM, Parthasarathi R (partr) wrote: >>> Hi all, >>> The context for this attribute is whether globally unique >> id is required >>> in each metadata block or whether it is required only in some of the >>> block only. One of the compelling reason for globally unique id is >>> because of the complex relationship between RS and CS which is not >>> currently passed from SRC to SRS. I'm trying to find >> whether passing the >>> information will reduce the complexity of globally unique >> id in some blocks. >>> In case RS to CS relationship between SRC& SRS, there is a >> possibility >>> of three types and they are as follows: >>> 1) One RS to one CS: Simple mechanism and every CS is >> directly mapped to >>> RS. Here, RS needs to be global unique id whereas those block is not >>> required to be global. >>> 2) One RS to many CS: >>> Usecases are as follows: >>> a) Persistent recording >>> b) Recording with single CSG >>> Here as well, RS needs to be global unique id whereas those >> block is not >>> required to be global. >>> 3) Many RS to one CS: >>> Use case are as follows: >>> a) start/stop recording session during single CS. >>> Here. RS needs global unique id as well as CS needs global >> unique id. >>> Please note that this mechanism will not co-exist with >> above two mechanism. >>> The attribute name is recording_type wherein the value of >> the attributes >>> will be >>> a) one_rs_one_cs >>> b) one_rs_many_cs >>> c) many_rs_one_cs >>> By knowing this attribute, SRS will be able to manage >> unique-id and its >>> scope as SRS aware of SRC mechanism. Say in case of >> one_rs_many_cs SRC, >>> media stream (MS) will never exceed RS wherein in case of >>> many_rs_one_cs, MS will never exceed CS and in both scenario, MS is >>> local to RS or CS. Please let me know whether it is worth >> to add this >>> attribute in Metadata model. >>> Thanks >>> Partha >>> >>> >>> >>> _______________________________________________ >>> siprec mailing list >>> siprec@ietf.org >>> https://www.ietf.org/mailman/listinfo/siprec >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >> From john.elwell@siemens-enterprise.com Wed Apr 27 09:54: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 28326E0728 for ; Wed, 27 Apr 2011 09:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.851 X-Spam-Level: X-Spam-Status: No, score=-104.851 tagged_above=-999 required=5 tests=[AWL=1.748, 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 Lrfn8byTFjNu for ; Wed, 27 Apr 2011 09:54:05 -0700 (PDT) Received: from mail182.messagelabs.com (mail182.messagelabs.com [85.158.139.83]) by ietfa.amsl.com (Postfix) with SMTP id 1F9A9E06F7 for ; Wed, 27 Apr 2011 09:54:04 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-12.tower-182.messagelabs.com!1303923243!5554094!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 28565 invoked from network); 27 Apr 2011 16:54:03 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-12.tower-182.messagelabs.com with SMTP; 27 Apr 2011 16:54:03 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id DA4071EB83E3; Wed, 27 Apr 2011 18:54:03 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 27 Apr 2011 18:54:03 +0200 From: "Elwell, John" To: Leon Portman , "siprec@ietf.org" , "Ken Rehor (krehor) (krehor@cisco.com)" Date: Wed, 27 Apr 2011 18:54:02 +0200 Thread-Topic: [siprec] Summary of the changes of draft-ietf-siprec-req-10 - last call Thread-Index: AcwE3y4TqEYV7EYpTvCzQYc4dfJgQwAGlQuA Message-ID: References: <07465C1D981ABC41A344374066AE1A2C38AB7A1BEB@TLVMBX01.nice.com> In-Reply-To: <07465C1D981ABC41A344374066AE1A2C38AB7A1BEB@TLVMBX01.nice.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Summary of the changes of draft-ietf-siprec-req-10 - last call X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 27 Apr 2011 16:54:06 -0000 =20 > -----Original Message----- > From: Leon Portman [mailto:Leon.Portman@nice.com]=20 > Sent: 27 April 2011 14:30 > To: siprec@ietf.org; Ken Rehor (krehor) (krehor@cisco.com);=20 > Elwell, John > Subject: [siprec] Summary of the changes of=20 > draft-ietf-siprec-req-10 - last call >=20 > Hello >=20 > =20 >=20 > Please see below summary of the changes for updated version=20 > of the requirements document. >=20 > =20 >=20 > Main changes: >=20 > =20 >=20 > 1. Updated REQ-022, 023, 024 (all other numbers are ++,=20 > original 22 and 23 removed), thanks to Muthu and John for the text >=20 > a. REQ-022: The mechanism MUST provide means for=20 > facilitating synchronization of the recorded media streams=20 > and metadata. >=20 > b. REQ-023: The mechanism MUST provide means for=20 > facilitating synchronization among the recorded media streams. >=20 > c. REQ-024: The mechanism MUST provide means for=20 > relating recordings to wall clock time. >=20 > 2. Use Case 8 - nit pick, thanks to Muthu (me -> may be) >=20 > a."In cases where calls inside or between branches must be=20 > recorded, a centralized recording system in data centers=20 > together with telephony infrastructure (e.g. PBX) may be deployed." >=20 > 3. Proposed additional paragraph in the=20 > security section from the security review (not in the text=20 > yet, pending WG approval): >=20 > "Integrity and correctness of the recorded sessions is not=20 > ensured by cryptographic means to ensure that the CS has not=20 > been tampered with. This would have to be done by=20 > organizational and technical controls that prevent tampering=20 > with CS participants and SRC." I have tried to reword to make it clearer (e.g., to get rid of the double u= se of "ensure"): "A malicious or corrupt SRC can tamper with media and metadata relating to = a CS before sending to an SRC. Also CS media and signalling can be tampered= with in the network prior to reaching an SRC, unless proper means are prov= ided to ensure integrity protection during transmission. Means for ensuring= the integrity and correctness of media and metadata emitted by an SRC are = outside the scope of this work. Other organizational and technical controls= will need to be used to prevent tampering." I would suggest you run this by the Security Area reviewer to ensure he is = happy. John >=20 > =20 >=20 > Regards >=20 > =20 >=20 > Leon >=20 > =20 >=20 > =20 >=20 > =20 >=20 > = From Leon.Portman@nice.com Wed Apr 27 10:47: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 C4681E07DA for ; Wed, 27 Apr 2011 10:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.546 X-Spam-Level: X-Spam-Status: No, score=-1.546 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] 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 W0uVPxVJXnpk for ; Wed, 27 Apr 2011 10:47:27 -0700 (PDT) Received: from mailil.nice.com (unknown [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id 53237E076E for ; Wed, 27 Apr 2011 10:47:26 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Wed, 27 Apr 2011 20:47:24 +0300 From: Leon Portman To: "Elwell, John" , "siprec@ietf.org" , "Ken Rehor (krehor) (krehor@cisco.com)" Date: Wed, 27 Apr 2011 20:47:23 +0300 Thread-Topic: [siprec] Summary of the changes of draft-ietf-siprec-req-10 - last call Thread-Index: AcwE3y4TqEYV7EYpTvCzQYc4dfJgQwAGlQuAAAJcplA= Message-ID: <07465C1D981ABC41A344374066AE1A2C38AB7A1CBF@TLVMBX01.nice.com> References: <07465C1D981ABC41A344374066AE1A2C38AB7A1BEB@TLVMBX01.nice.com> In-Reply-To: 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_07465C1D981ABC41A344374066AE1A2C38AB7A1CBFTLVMBX01nicec_" MIME-Version: 1.0 Subject: Re: [siprec] Summary of the changes of draft-ietf-siprec-req-10 - last call X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 27 Apr 2011 17:47:27 -0000 --_000_07465C1D981ABC41A344374066AE1A2C38AB7A1CBFTLVMBX01nicec_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable John, hi Thank you very much. I think there two places were you meant to use SRS ins= tead of SRC: "A malicious or corrupt SRC can tamper with media and metadata relating to = a CS before sending to an SRS. Also CS media and signaling can be tampered = with in the network prior to reaching an SRS, unless proper means are provi= ded to ensure integrity protection during transmission. Means for ensuring = the integrity and correctness of media and metadata emitted by an SRC are o= utside the scope of this work. Other organizational and technical controls = will need to be used to prevent tampering." Leon -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] Sent: Wednesday, April 27, 2011 7:54 PM To: Leon Portman; siprec@ietf.org; Ken Rehor (krehor) (krehor@cisco.com) Subject: RE: [siprec] Summary of the changes of draft-ietf-siprec-req-10 - = last call > -----Original Message----- > From: Leon Portman [mailto:Leon.Portman@nice.com] > Sent: 27 April 2011 14:30 > To: siprec@ietf.org; Ken Rehor (krehor) (krehor@cisco.com); > Elwell, John > Subject: [siprec] Summary of the changes of > draft-ietf-siprec-req-10 - last call > > Hello > > > > Please see below summary of the changes for updated version > of the requirements document. > > > > Main changes: > > > > 1. Updated REQ-022, 023, 024 (all other numbers are ++, > original 22 and 23 removed), thanks to Muthu and John for the text > > a. REQ-022: The mechanism MUST provide means for > facilitating synchronization of the recorded media streams > and metadata. > > b. REQ-023: The mechanism MUST provide means for > facilitating synchronization among the recorded media streams. > > c. REQ-024: The mechanism MUST provide means for > relating recordings to wall clock time. > > 2. Use Case 8 - nit pick, thanks to Muthu (me -> may be) > > a."In cases where calls inside or between branches must be > recorded, a centralized recording system in data centers > together with telephony infrastructure (e.g. PBX) may be deployed." > > 3. Proposed additional paragraph in the > security section from the security review (not in the text > yet, pending WG approval): > > "Integrity and correctness of the recorded sessions is not > ensured by cryptographic means to ensure that the CS has not > been tampered with. This would have to be done by > organizational and technical controls that prevent tampering > with CS participants and SRC." I have tried to reword to make it clearer (e.g., to get rid of the double u= se of "ensure"): "A malicious or corrupt SRC can tamper with media and metadata relating to = a CS before sending to an SRC. Also CS media and signalling can be tampered= with in the network prior to reaching an SRC, unless proper means are prov= ided to ensure integrity protection during transmission. Means for ensuring= the integrity and correctness of media and metadata emitted by an SRC are = outside the scope of this work. Other organizational and technical controls= will need to be used to prevent tampering." I would suggest you run this by the Security Area reviewer to ensure he is = happy. John > > > > Regards > > > > Leon > > > > > > > > --_000_07465C1D981ABC41A344374066AE1A2C38AB7A1CBFTLVMBX01nicec_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

John, hi=

 

Thank you very much. I think there two places were you meant to use SRS= instead of SRC:

 

"A malicious or corrupt SRC can tamper with m= edia and metadata relating to a CS before sending to an SRS. Also CS media and signaling can be tampered with in the = network prior to reaching an SRS, unless p= roper means are provided to ensure integrity protection during transmission= . Means for ensuring the integrity and correctness of media and metadata em= itted by an SRC are outside the scope of this work. Other organizational an= d technical controls will need to be used to prevent tampering."<= /o:p>

 

Leon

 

-----Original Message-----
From: Elwell, John [mailto:jo= hn.elwell@siemens-enterprise.com]
Sent: Wednesday, April 27, 2011 7:54 = PM
To: Leon Portman; siprec@ietf.org; Ken Rehor (krehor) (krehor@cisco.c= om)
Subject: RE: [siprec] Summary of the changes of draft-ietf-siprec-re= q-10 - last call

 

 

> -----Original Message-----

> From: Leon Portman [mailto:Leon.Portman@nice.com]=

> Sent: 27 April 2011 14:30=

> To: siprec@ietf.org; Ken Rehor (kreh= or) (krehor@cisco.com);

> Elwell,= John

> Subject: [siprec] Summary = of the changes of

> draft-ietf-si= prec-req-10 - last call

>

> Hello

>

> 

=

>

> Pl= ease see below summary of the changes for  updated version =

> of the requirements document.

>

>&= nbsp;

>

> Main changes:

&g= t;

> 

>

> 1. &= nbsp;     Updated REQ-022, 023, 024 (all other numbers = are ++,

> original 22 and 23 remo= ved), thanks to Muthu and John for the text

>

> a.   = ;    REQ-022: The mechanism MUST provide means for

> facilitating synchronization of the reco= rded media streams

> and metadata= .

>

> b.      REQ-023: The mechanism MUST = provide means for

> facilitating = synchronization among the recorded media streams.

>

> c.  = ;     REQ-024: The mechanism MUST provide means for

> relating recordings to wall clock = time.

>

> 2. Use Case 8 - nit pick, thanks to Muthu (me -> may b= e)

>

> a."In cases where calls inside or between branches must= be

> recorded, a centralized rec= ording system in data centers

> t= ogether with telephony infrastructure (e.g. PBX) may be deployed."

>

>           &= nbsp;     3. Proposed additional paragraph in the =

> security section from the security r= eview (not in the text

> yet, pen= ding WG approval):

>

> "Integrity and correctness of the recor= ded sessions is not

> ensured by = cryptographic means to ensure that the CS has not

> been tampered with. This would have to be done by

> organizational and technical contro= ls that prevent tampering

> with = CS participants and SRC."

&= nbsp;

I have tried to reword to make it cl= earer (e.g., to get rid of the double use of "ensure"):

"A malicious or corrupt SRC can tamper wi= th media and metadata relating to a CS before sending to an SRC. Also CS me= dia and signalling can be tampered with in the network prior to reaching an= SRC, unless proper means are provided to ensure integrity protection durin= g transmission. Means for ensuring the integrity and correctness of media a= nd metadata emitted by an SRC are outside the scope of this work. Other org= anizational and technical controls will need to be used to prevent tamperin= g."

 

I would suggest you run this by the Security Area reviewer= to ensure he is happy.

 

John

=  

>

> 

>

> Regards

>

> 

>

&= gt; Leon

>

> 

>

> 

>

> 

>

&g= t;

= --_000_07465C1D981ABC41A344374066AE1A2C38AB7A1CBFTLVMBX01nicec_-- From john.elwell@siemens-enterprise.com Wed Apr 27 11:04: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 328F6E0710 for ; Wed, 27 Apr 2011 11:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.883 X-Spam-Level: X-Spam-Status: No, score=-104.883 tagged_above=-999 required=5 tests=[AWL=1.716, 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 XWYmjuIDna9e for ; Wed, 27 Apr 2011 11:04:43 -0700 (PDT) Received: from mail216.messagelabs.com (mail216.messagelabs.com [85.158.143.99]) by ietfa.amsl.com (Postfix) with SMTP id 008AAE06EC for ; Wed, 27 Apr 2011 11:04:42 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-15.tower-216.messagelabs.com!1303927481!3352436!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 22783 invoked from network); 27 Apr 2011 18:04:41 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-15.tower-216.messagelabs.com with SMTP; 27 Apr 2011 18:04:41 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 815AD23F03E2; Wed, 27 Apr 2011 20:04:41 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 27 Apr 2011 20:04:41 +0200 From: "Elwell, John" To: Leon Portman , "siprec@ietf.org" , "Ken Rehor (krehor) (krehor@cisco.com)" Date: Wed, 27 Apr 2011 20:04:39 +0200 Thread-Topic: [siprec] Summary of the changes of draft-ietf-siprec-req-10 - last call Thread-Index: AcwE3y4TqEYV7EYpTvCzQYc4dfJgQwAGlQuAAAJcplAAAIj4AA== Message-ID: References: <07465C1D981ABC41A344374066AE1A2C38AB7A1BEB@TLVMBX01.nice.com> <07465C1D981ABC41A344374066AE1A2C38AB7A1CBF@TLVMBX01.nice.com> In-Reply-To: <07465C1D981ABC41A344374066AE1A2C38AB7A1CBF@TLVMBX01.nice.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Summary of the changes of draft-ietf-siprec-req-10 - last call X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 27 Apr 2011 18:04:44 -0000 Oops. In fact, only the first place was wrong. To clarify the other one, I = extended the second sentence with the words "on the CS". The text should be= : "A malicious or corrupt SRC can tamper with media and metadata relating to = a CS before sending to an SRS. Also CS media and signalling can be tampered= with in the network prior to reaching an SRC, unless proper means are prov= ided to ensure integrity protection during transmission on the CS. Means fo= r ensuring the integrity and correctness of media and metadata emitted by a= n SRC are outside the scope of this work. Other organizational and technica= l controls will need to be used to prevent tampering." John=20 > -----Original Message----- > From: Leon Portman [mailto:Leon.Portman@nice.com]=20 > Sent: 27 April 2011 18:47 > To: Elwell, John; siprec@ietf.org; Ken Rehor (krehor)=20 > (krehor@cisco.com) > Subject: RE: [siprec] Summary of the changes of=20 > draft-ietf-siprec-req-10 - last call >=20 > John, hi >=20 > =20 >=20 > Thank you very much. I think there two places were you meant=20 > to use SRS instead of SRC: >=20 > =20 >=20 > "A malicious or corrupt SRC can tamper with media and=20 > metadata relating to a CS before sending to an SRS. Also CS=20 > media and signaling can be tampered with in the network prior=20 > to reaching an SRS, unless proper means are provided to=20 > ensure integrity protection during transmission. Means for=20 > ensuring the integrity and correctness of media and metadata=20 > emitted by an SRC are outside the scope of this work. Other=20 > organizational and technical controls will need to be used to=20 > prevent tampering." >=20 > =20 >=20 > Leon >=20 > =20 >=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > Sent: Wednesday, April 27, 2011 7:54 PM > To: Leon Portman; siprec@ietf.org; Ken Rehor (krehor)=20 > (krehor@cisco.com) > Subject: RE: [siprec] Summary of the changes of=20 > draft-ietf-siprec-req-10 - last call >=20 > =20 >=20 > =20 >=20 > > -----Original Message----- >=20 > > From: Leon Portman [mailto:Leon.Portman@nice.com]=20 >=20 > > Sent: 27 April 2011 14:30 >=20 > > To: siprec@ietf.org; Ken Rehor (krehor) (krehor@cisco.com);=20 >=20 > > Elwell, John >=20 > > Subject: [siprec] Summary of the changes of=20 >=20 > > draft-ietf-siprec-req-10 - last call >=20 > >=20 >=20 > > Hello >=20 > >=20 >=20 > > =20 >=20 > >=20 >=20 > > Please see below summary of the changes for updated version=20 >=20 > > of the requirements document. >=20 > >=20 >=20 > > =20 >=20 > >=20 >=20 > > Main changes: >=20 > >=20 >=20 > > =20 >=20 > >=20 >=20 > > 1. Updated REQ-022, 023, 024 (all other numbers are ++,=20 >=20 > > original 22 and 23 removed), thanks to Muthu and John for the text >=20 > >=20 >=20 > > a. REQ-022: The mechanism MUST provide means for=20 >=20 > > facilitating synchronization of the recorded media streams=20 >=20 > > and metadata. >=20 > >=20 >=20 > > b. REQ-023: The mechanism MUST provide means for=20 >=20 > > facilitating synchronization among the recorded media streams. >=20 > >=20 >=20 > > c. REQ-024: The mechanism MUST provide means for=20 >=20 > > relating recordings to wall clock time. >=20 > >=20 >=20 > > 2. Use Case 8 - nit pick, thanks to Muthu (me -> may be) >=20 > >=20 >=20 > > a."In cases where calls inside or between branches must be=20 >=20 > > recorded, a centralized recording system in data centers=20 >=20 > > together with telephony infrastructure (e.g. PBX) may be deployed." >=20 > >=20 >=20 > > 3. Proposed additional paragraph in the=20 >=20 > > security section from the security review (not in the text=20 >=20 > > yet, pending WG approval): >=20 > >=20 >=20 > > "Integrity and correctness of the recorded sessions is not=20 >=20 > > ensured by cryptographic means to ensure that the CS has not=20 >=20 > > been tampered with. This would have to be done by=20 >=20 > > organizational and technical controls that prevent tampering=20 >=20 > > with CS participants and SRC." >=20 > =20 >=20 > I have tried to reword to make it clearer (e.g., to get rid=20 > of the double use of "ensure"): >=20 > "A malicious or corrupt SRC can tamper with media and=20 > metadata relating to a CS before sending to an SRC. Also CS=20 > media and signalling can be tampered with in the network=20 > prior to reaching an SRC, unless proper means are provided to=20 > ensure integrity protection during transmission. Means for=20 > ensuring the integrity and correctness of media and metadata=20 > emitted by an SRC are outside the scope of this work. Other=20 > organizational and technical controls will need to be used to=20 > prevent tampering." >=20 > =20 >=20 > I would suggest you run this by the Security Area reviewer to=20 > ensure he is happy. >=20 > =20 >=20 > John >=20 > =20 >=20 > >=20 >=20 > > =20 >=20 > >=20 >=20 > > Regards >=20 > >=20 >=20 > > =20 >=20 > >=20 >=20 > > Leon >=20 > >=20 >=20 > > =20 >=20 > >=20 >=20 > > =20 >=20 > >=20 >=20 > > =20 >=20 > >=20 >=20 > >=20 >=20 > = From eckelcu@cisco.com Wed Apr 27 11:17: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 9D3C1E0754 for ; Wed, 27 Apr 2011 11:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.414 X-Spam-Level: X-Spam-Status: No, score=-10.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 xAT6119W0ROO for ; Wed, 27 Apr 2011 11:17:51 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 0C31CE0765 for ; Wed, 27 Apr 2011 11:17:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=16986; q=dns/txt; s=iport; t=1303928270; x=1305137870; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=AFw8c2w3Ru71dzPrSMSlvRw7cJZc56qSVYb8Z+bAT3s=; b=a8YMZ97Zps1kucQFR/WzJ7GHk62o86bGytmGYRecVNoZ4exWUPMzAOU+ P0wARrduROhwN33jhTyCqeYbXVDJuuDs2TjDQ35uls3SyOGrs5wZtuZno rOSagjoS8q0pV8UBbR8MtxqZRGoA/fkb4Y312qdMV3AqsG7JRl1SPjrRg o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsBAEtduE2rRDoJ/2dsb2JhbACXf41td6cgnG2FdgSGA4xoijI X-IronPort-AV: E=Sophos;i="4.64,275,1301875200"; d="scan'208";a="688180722" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-6.cisco.com with ESMTP; 27 Apr 2011 18:17:50 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3RIHofg024499 for ; Wed, 27 Apr 2011 18:17:50 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); Wed, 27 Apr 2011 11:17:50 -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, 27 Apr 2011 11:17:46 -0700 Message-ID: In-Reply-To: <4DB81F8A.8000306@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Does MS have life outside a particular CS? (was RE: comments on draft-ram-siprec-metadata-04) Thread-Index: AcwE4leug7I2UTo8T+aMdNr1lctZ4AAJQTvg References: <4DAD8A5F.4040506@cisco.com><4DADA8E6.9010006@cisco.com> <35BCE99A477D6A49 8 6 F B 2216 D8CF2CFD06133A56@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD06133DD4@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD06133E6B@XMB-BGL-417.cisco.com> <4DB81F8A.8000306@cisco.com> From: "Charles Eckel (eckelcu)" To: "Paul Kyzivat (pkyzivat)" , "Parthasarathi R (partr)" X-OriginalArrivalTime: 27 Apr 2011 18:17:50.0243 (UTC) FILETIME=[6AD92F30:01CC0507] Cc: siprec@ietf.org Subject: Re: [siprec] Does MS have life outside a particular CS? (was RE: comments on draft-ram-siprec-metadata-04) X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 27 Apr 2011 18:17:52 -0000 That helps clarify it for me. Thanks Paul. Cheers, Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat (pkyzivat) > Sent: Wednesday, April 27, 2011 6:52 AM > To: Parthasarathi R (partr) > Cc: siprec@ietf.org > Subject: Re: [siprec] Does MS have life outside a particular CS? (was RE: comments on draft-ram- > siprec-metadata-04) >=20 > There seems to be some confusion in this discussion about what a MS is. >=20 > On one hand there is an m-line in the SDP of the RS, and a corresponding > RTP stream. >=20 > On another hand there is an m-line in a CS and a corresponding RTP stream. >=20 > And then there is an MS described in the metadata conveyed over the RS. >=20 > And for both of the above, a single m-line might correspond to different > RTP streams over time, due to renegotiating the address and/or port of > the recipient, or by a different sender sending to the same port. >=20 > There is a mapping between one or more RTP streams in the CS (or > multiple CSs?) and one or more RTP streams in the RS. The metadata > hopefully describes that mapping. >=20 > But perhaps we don't have full agreement on what sorts of mappings are > possible. Some that I think we allow are: > - one CS RTP stream to one RS RTP stream. > - multiple concurrent CS RTP streams mixed to one > RS RTP stream > - multiple CS RTP streams sequentially mapped to the same > RS RTP stream > ... >=20 > Presumably the RTP streams associated with the RS end when the RS ends. > That does not necessarily mean that the media stream of a CS also ends > at that time. It could be picked up again in a different RS by the same > or different SRC. >=20 > Thanks, > Paul >=20 > On 4/27/2011 2:30 AM, Parthasarathi R (partr) wrote: > > John, > > > > My intention is show the complexity in the metadata model in the current > > form. Global unique id solves the issue but let us explore for better > > optimized solution with more local unique id if any exists. > > > > I have created another mail thread for adding the recording type > > attribute which helps in most of the metadata blocks to have local > > unique id rather than global unique id. Let us see how others visualize > > that attribute. > > > > IMO, it may better to have globally unique id with the current metadata > > model attributes. We may be able to add the normative statement that > > "Media stream (MS) MUST be terminated when CS is terminated" in the > > metadata but in reality, MS is within the scope of RS which is forced to > > delete for no reason. These sort will be restrictive for few SRC > > implementation. For eg: RS may created MS with RSVP which may not prefer > > to terminate the resource during RS mid-session changes like CS changes > > even though intermediate time with no media but the above normative > > statement forces to break those SRC implementation. > > > > Please read inline for more comments. > > > > Thanks > > Partha > > > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Friday, April 22, 2011 1:48 AM > > To: Parthasarathi R (partr); Ram Mohan R (rmohanr); Paul Kyzivat > > (pkyzivat) > > Cc: siprec@ietf.org > > Subject: RE: Does MS have life outside a particular CS? (was RE: > > [siprec] comments on draft-ram-siprec-metadata-04) > > > > > > > >> -----Original Message----- > >> From: Parthasarathi R (partr) [mailto:partr@cisco.com] > >> Sent: 21 April 2011 17:20 > >> To: Elwell, John; Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > >> Cc: siprec@ietf.org > >> Subject: RE: Does MS have life outside a particular CS? (was > >> RE: [siprec] comments on draft-ram-siprec-metadata-04) > >> > >> John, > >> > >> Please read inline. > >> > >> Thanks > >> Partha > >> > >> -----Original Message----- > >> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > >> Sent: Thursday, April 21, 2011 9:12 PM > >> To: Parthasarathi R (partr); Ram Mohan R (rmohanr); Paul Kyzivat > >> (pkyzivat) > >> Cc: siprec@ietf.org > >> Subject: RE: Does MS have life outside a particular CS? (was RE: > >> [siprec] comments on draft-ram-siprec-metadata-04) > >> > >> Partha, > >> > >>> -----Original Message----- > >>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] > >>> Sent: 21 April 2011 14:25 > >>> To: Elwell, John; Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > >>> Cc: siprec@ietf.org > >>> Subject: RE: Does MS have life outside a particular CS? (was > >>> RE: [siprec] comments on draft-ram-siprec-metadata-04) > >>> > >>> John, > >>> > >>> I could think of one usecase wherein MS is outside CS but within > >>> single RS. The usecase is multiple CS within single RS and MS. The > >>> usecase is as follows: > >>> > >>> B2BUA acts as SRC. A, B, C are participants within single B2BUA. A > >>> creates single RS for a CSG. > >>> > >>> 1) A calls B through B2BUA. B2BUA creates RS towards SRS with CSG1, > >>> CS1, > >>> MS1 (A's media stream), MS2 (B's media stream), Participant1 as A& > >>> Participant2 as B. > >> [JRE] Why two media streams? Why not a single MS, with both A and B > >> sending and receiving that MS? > >> The media streams are un-mixed, MS1 points to RTP from A > >> through label attribute in MS1 SDP, MS2 points to RTP from B through > >> label attribute in MS2 SDP > > [JRE] Reading the metadata model again, I think it does seem to imply > > two Media Stream objects if the two directions for a 2-party call are > > sent unmixed (as two m-lines in the RS SDP), so I will concede that we > > have two Media Stream objects here. I had been thinking of a slightly > > different model, where there is one Media Stream, but associations > > between the Media Stream and Participants pointed to different m-lines > > in the RS SDP. > > > >> > >>> 2) B connects with C through B2BUA > >>> 3) B transfer the call of A& B to C using REFER, B2BUA > >> converts REFER > >> > >>> to RE-INVITE towards A& C and A& C are connected. B2BUA > >> updates RS > >>> with CS2, Participant1 as A& participant2 as C, MS1(A's media > >>> stream), MS2(C's media stream). > >> [JRE] I would have expected, from my understanding of the metadata > >> model, that the CS2 would have a new MS, with both A and B sending and > > > >> receiving that new MS. > >> > >> It is not mandatory because participant information will be > >> updated and pointing to the same m-line in RS with same label > >> attribute. > >> From SRS perspective, the same media stream with the update in the > >> participant name only. Say MS2 is stored as one record with B as > >> participant for T0 to T1 timelines and C as participant from T1 to T2. > >> > > [JRE] Or alternatively it could be modelled that when a new CS starts > > there is a new Media Stream object, still pointing to the same m-line in > > the RS SDP. > > > > The purpose of unique-id will go for toss here. The same media > > stream (MS) has unique id "id1" initially and later it will have "id2" > > which will not be good for replay. Of course, MS life is always within > > RS in this scenario but not within CS. So, Unique Id within RS will > > serve the purpose > > > > This would avoid the need for a Media Stream object to survive beyond > > the lifetime of a CS, and therefore allow local identification. While > > there is no CS in progress, the m-line would be disabled (port 0) and > > would not be referenced by any Media Stream. > > > > RS m-line is not required to 0 because it shall change into > > "a=3Dinactive" as well. There is no change in the resource = reservation in > > both SRC and SRS > > > >> > >>> There is no update on RS1, CSG1, MS1, MS2. MS2 will become MS2 with > >>> the new association and in terms of format, it will associate with > >>> tag. > >>> > >>> In the above scenario, MS have life outside CS but it is within RS. > >> [JRE] I can see how it COULD work like that, but it is not intuitive. > >> > >> In SIPREC solution, UPDATE message with CS2(session > >> element) , > >> participant "C" element are received in SRS. This partial update of > >> UPDATE helps to make this scenario work. There is no change in term > >> stream element or RS SDP > >> > >> To me, a new CS means the existing media stream stops and a new media > >> stream is created. > >> > >> I'm interested knowing whether you propose that MS MUST stop > >> in case CS ends and the above scenario is outside the scope of SIPREC? > >> > >> > >>> The > >>> unique id shall be within RS scope as mentioned in IETF-80 meeting. > >>> But in another situation, MS is outside the scope of RS but > >> within CS > >>> and the usecase is Multiple RS for single CS, details are > >> as follows: > >>> > >>> A, B are pariticipants. A acts as SRC which tear down RS > >> whenever hold > >> > >>> happens& creates new RS when resume happens. > >>> > >>> 1) A calls B. A creates RS1 towards SRS with CS1, MS1 (A's media > >>> stream), MS2 (B's Media stream),Participant1 as A& > >> Participant2 as B. > >> [JRE] Again, I would model this as a single MS, to which both A and B > >> contribute. > >> Again, unmixed stream from A and B > >>> 2) A put B on hold. A tear down RS1. > >>> 3) A resume B. A creates RS2 towards SRS with CS1, MS1 (A's media > >>> stream), MS2 (B's Media stream),Participant1 as A& > >> Participant2 as B > >>> > >>> Here MS1& MS2 needs to be same across RS to group media streams > >>> correctly. Please let me know your opinion here. > >> > >> [JRE] Although I disagree that we have two Media Streams here, I do > >> agree that the single Media Stream could be considered to survive the > >> hold/resume, and hence survive from RS1 to RS2. But the MS is within > >> the context of the same CS (CS1), and therefore this is outside the > >> scope of this particular thread, which is asking whether an MS can > >> have a life outside a particular CS. In this case the MS continues to > >> be associated with the CS, so I don't have a problem with that. > >> > >> I have 2nd example to illustrate MS have life outside RS. > >> > >> > >> So you have failed to convince me that an MS needs to have a life > >> outside a CS. > >> > >> In case the above scenario-1 way of recording is outside the > >> scope of SIPREC, I agree with you that MS does not have life outside a > > > >> particular CS > > [JRE] I assume you are talking about the call transfer case. I am not > > saying that use case is outside the scope of SIPREC. I am just saying > > that it can be modelled a different way, which may be advantageous in > > terms of the number of globally unique identifiers needed. > > > > > > John (as individual) > > > > > > > >> > >> John (as individual) > >> > >> > >>> > >>> Having said that MS have life outside a particular CS, I create > >>> separate thread within unique how it shall be handled. > >>> > >>> Thanks > >>> Partha > >>> > >>> -----Original Message----- > >>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > >>> Sent: Thursday, April 21, 2011 12:01 PM > >>> To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > >>> Cc: Parthasarathi R (partr); siprec@ietf.org > >>> Subject: Does MS have life outside a particular CS? (was > >> RE: [siprec] > >>> comments on draft-ram-siprec-metadata-04) > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > >>>> Sent: 20 April 2011 18:08 > >>>> To: Elwell, John; Paul Kyzivat (pkyzivat) > >>>> Cc: Parthasarathi R (partr); siprec@ietf.org > >>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > >>>> > >>>> Hi John, > >>>> > >>>> Please see inline [RAM] > >>>> > >>>>> -----Original Message----- > >>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > >>>>> Sent: Wednesday, April 20, 2011 8:19 PM > >>>>> To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > >>>>> Cc: Parthasarathi R (partr); siprec@ietf.org > >>>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > >>>>> > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > >>>>>> Sent: 20 April 2011 14:52 > >>>>>> To: Elwell, John; Paul Kyzivat (pkyzivat) > >>>>>> Cc: Parthasarathi R (partr); siprec@ietf.org > >>>>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > >>>>>> > >>>>>> John, > >>>>>> > >>>>>> I agree with you that normal cases RS will remain at > >>> least for the > >>> > >>>>>> duration of CS. However it is common to have use cases where > >>>>> recording > >>>>>> is done for first few mins of a CS and then stopped, > >>>> re-started at a > >>>>>> later point (e.g Recording of a company meeting where > >>> you may want > >>>> to > >>>>>> record only portions of meeting). > >>>>>> > >>>>>> In any case, the point I like to high light here is, MS > >>>> block could > >>>>> be > >>>>>> common across RS and even across CS[ due to consult > >>>> transfer e.t.c]. > >>>>>> These use cases indicate the need to have a unique ID > >>> for MS block > >>> > >>>>>> (similar to the UUID that we have defined in format) as > >>> we cannot > >>>>>> depend on neither CS ID or RS ID. > >>>>> [JRE] I am having a hard time understanding the concept > >>> of a single > >>>>> Media Stream that survives across multiple CSs. For > >>> example, in the > >>>>> case of transfer, I would have thought new Media > >> Streams would be > >>>>> created. > >>>> > >>>> [RAM] > >>>> Here is my thoughts. > >>>> 1) There can be multiple RS per CS > >>>> RS1 --- CS1--MS1 > >>>> RS2----CS1--MS1 > >>>> Examples are partial recording of CS (like recording parts > >>> of meeting, > >>> > >>>> redundant recording where there are multiple SRCs recording > >>> the same > >>>> CS) > >>> [JRE] Agreed. In this case MS1 is local to CS1. > >>> > >>>> > >>>> 2) There can be same Media Stream across multiple CS. > >>>> RS1--- CS1--- MS1 > >>>> RS2--CS2--MS1 > >>>> Examples are Multicast MoH played to multiple end points who are > >>>> potentially part of disjoint CSs where each CS is recorded > >>> as part of > >>>> separate RS. > >>>> > >>>> Of course the above is arguable where the stream is same or > >>> different. > >>>> My view is since the UA (that supplies the Multicast MoH) and its > >>>> media are same across all CS, I think it can be represented > >>> as same MS > >>> > >>>> block. > >>> [JRE] I would argue these are different MSs. I agree that a medium > >>> such as music on hold might be sent, in synch, to multiple > >>> participants in multiple CSs. In that particular situation > >> there might > >> > >>> be some efficiency saving by calling it the same MS. > >> However, I would > >>> suggest (although this is not my field of expertise) it would make > >>> life a lot harder for the SRS and its database. I would > >> have expected > >>> to want to record a complete CS (all its participants and media > >>> streams) as a complete recording, which could be deleted, > >> copied, and > >> > >>> so on without having to go looking for other objects that complete > >>> that recording and are shared with other recordings. For > >> example, if > >>> you delete a recording, you would want to delete all its > >> MSs, but not > >>> those used by other recordings, although you would need a garbage > >>> collection mechanism to delete an MS recording when it is no longer > >>> used by any CS recordings. Rather ugly. Making a MS local to a CS > >>> would simplify all this. > >>> > >>>> > >>>> > >>>> However it is still possible to treat each as separate > >>> stream in the > >>>> model, in which case the information that it is the same MS > >>> played by > >>>> a UA to different CS will be lost. I don't know if there is an > >>>> interest to capture this level of detail and if it is of > >> any use to > >>>> SRS. > >>> [JRE] I assume what you are saying here is not that > >> information will > >>> be lost, but that you will be unable to tell, without doing a > >>> comparison, whether two different MSs played to participants in two > >>> different CSs are identical or not for the particular time > >> span that > >>> is common. I don't see where such a requirement would come from. > >>> > >>> John (as individual) > >>> > >>> > >> > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From Leon.Portman@nice.com Wed Apr 27 12:23: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 1EC5BE0821 for ; Wed, 27 Apr 2011 12:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.489 X-Spam-Level: X-Spam-Status: No, score=-1.489 tagged_above=-999 required=5 tests=[AWL=-0.994, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 MkgsqNAIIpVv for ; Wed, 27 Apr 2011 12:23:26 -0700 (PDT) Received: from mailil.nice.com (unknown [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id 93D83E0813 for ; Wed, 27 Apr 2011 12:23:25 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Wed, 27 Apr 2011 22:23:24 +0300 From: Leon Portman To: "Elwell, John" , "siprec@ietf.org" , "Ken Rehor (krehor) (krehor@cisco.com)" Date: Wed, 27 Apr 2011 22:23:24 +0300 Thread-Topic: [siprec] Summary of the changes of draft-ietf-siprec-req-10 - last call Thread-Index: AcwE3y4TqEYV7EYpTvCzQYc4dfJgQwAGlQuAAAJcplAAAIj4AAAAQU5Q Message-ID: <07465C1D981ABC41A344374066AE1A2C38AB7A1CCE@TLVMBX01.nice.com> References: <07465C1D981ABC41A344374066AE1A2C38AB7A1BEB@TLVMBX01.nice.com> <07465C1D981ABC41A344374066AE1A2C38AB7A1CBF@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 Subject: Re: [siprec] Summary of the changes of draft-ietf-siprec-req-10 - last call X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 27 Apr 2011 19:23:27 -0000 Thank you very much. Sending it to Tobias Leon -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 Sent: Wednesday, April 27, 2011 9:05 PM To: Leon Portman; siprec@ietf.org; Ken Rehor (krehor) (krehor@cisco.com) Subject: RE: [siprec] Summary of the changes of draft-ietf-siprec-req-10 - = last call Oops. In fact, only the first place was wrong. To clarify the other one, I = extended the second sentence with the words "on the CS". The text should be= : "A malicious or corrupt SRC can tamper with media and metadata relating to = a CS before sending to an SRS. Also CS media and signalling can be tampered= with in the network prior to reaching an SRC, unless proper means are prov= ided to ensure integrity protection during transmission on the CS. Means fo= r ensuring the integrity and correctness of media and metadata emitted by a= n SRC are outside the scope of this work. Other organizational and technica= l controls will need to be used to prevent tampering." John=20 > -----Original Message----- > From: Leon Portman [mailto:Leon.Portman@nice.com] > Sent: 27 April 2011 18:47 > To: Elwell, John; siprec@ietf.org; Ken Rehor (krehor) > (krehor@cisco.com) > Subject: RE: [siprec] Summary of the changes of > draft-ietf-siprec-req-10 - last call >=20 > John, hi >=20 > =20 >=20 > Thank you very much. I think there two places were you meant to use=20 > SRS instead of SRC: >=20 > =20 >=20 > "A malicious or corrupt SRC can tamper with media and metadata=20 > relating to a CS before sending to an SRS. Also CS media and signaling=20 > can be tampered with in the network prior to reaching an SRS, unless=20 > proper means are provided to ensure integrity protection during=20 > transmission. Means for ensuring the integrity and correctness of=20 > media and metadata emitted by an SRC are outside the scope of this=20 > work. Other organizational and technical controls will need to be used=20 > to prevent tampering." >=20 > =20 >=20 > Leon >=20 > =20 >=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Wednesday, April 27, 2011 7:54 PM > To: Leon Portman; siprec@ietf.org; Ken Rehor (krehor) > (krehor@cisco.com) > Subject: RE: [siprec] Summary of the changes of > draft-ietf-siprec-req-10 - last call >=20 > =20 >=20 > =20 >=20 > > -----Original Message----- >=20 > > From: Leon Portman [mailto:Leon.Portman@nice.com] >=20 > > Sent: 27 April 2011 14:30 >=20 > > To: siprec@ietf.org; Ken Rehor (krehor) (krehor@cisco.com); >=20 > > Elwell, John >=20 > > Subject: [siprec] Summary of the changes of >=20 > > draft-ietf-siprec-req-10 - last call >=20 > >=20 >=20 > > Hello >=20 > >=20 >=20 > > =20 >=20 > >=20 >=20 > > Please see below summary of the changes for updated version >=20 > > of the requirements document. >=20 > >=20 >=20 > > =20 >=20 > >=20 >=20 > > Main changes: >=20 > >=20 >=20 > > =20 >=20 > >=20 >=20 > > 1. Updated REQ-022, 023, 024 (all other numbers are ++,=20 >=20 > > original 22 and 23 removed), thanks to Muthu and John for the text >=20 > >=20 >=20 > > a. REQ-022: The mechanism MUST provide means for=20 >=20 > > facilitating synchronization of the recorded media streams >=20 > > and metadata. >=20 > >=20 >=20 > > b. REQ-023: The mechanism MUST provide means for=20 >=20 > > facilitating synchronization among the recorded media streams. >=20 > >=20 >=20 > > c. REQ-024: The mechanism MUST provide means for=20 >=20 > > relating recordings to wall clock time. >=20 > >=20 >=20 > > 2. Use Case 8 - nit pick, thanks to Muthu (me -> may be) >=20 > >=20 >=20 > > a."In cases where calls inside or between branches must be >=20 > > recorded, a centralized recording system in data centers >=20 > > together with telephony infrastructure (e.g. PBX) may be deployed." >=20 > >=20 >=20 > > 3. Proposed additional paragraph in the >=20 > > security section from the security review (not in the text >=20 > > yet, pending WG approval): >=20 > >=20 >=20 > > "Integrity and correctness of the recorded sessions is not >=20 > > ensured by cryptographic means to ensure that the CS has not >=20 > > been tampered with. This would have to be done by >=20 > > organizational and technical controls that prevent tampering >=20 > > with CS participants and SRC." >=20 > =20 >=20 > I have tried to reword to make it clearer (e.g., to get rid of the=20 > double use of "ensure"): >=20 > "A malicious or corrupt SRC can tamper with media and metadata=20 > relating to a CS before sending to an SRC. Also CS media and=20 > signalling can be tampered with in the network prior to reaching an=20 > SRC, unless proper means are provided to ensure integrity protection=20 > during transmission. Means for ensuring the integrity and correctness=20 > of media and metadata emitted by an SRC are outside the scope of this=20 > work. Other organizational and technical controls will need to be used=20 > to prevent tampering." >=20 > =20 >=20 > I would suggest you run this by the Security Area reviewer to ensure=20 > he is happy. >=20 > =20 >=20 > John >=20 > =20 >=20 > >=20 >=20 > > =20 >=20 > >=20 >=20 > > Regards >=20 > >=20 >=20 > > =20 >=20 > >=20 >=20 > > Leon >=20 > >=20 >=20 > > =20 >=20 > >=20 >=20 > > =20 >=20 > >=20 >=20 > > =20 >=20 > >=20 >=20 > >=20 >=20 >=20 From Henry.Lum@alcatel-lucent.com Wed Apr 27 13:16:03 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 8CEBAE07E1 for ; Wed, 27 Apr 2011 13:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.449 X-Spam-Level: X-Spam-Status: No, score=-4.449 tagged_above=-999 required=5 tests=[AWL=2.149, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 3JpGtXAxmI49 for ; Wed, 27 Apr 2011 13:16:01 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 59B41E07C8 for ; Wed, 27 Apr 2011 13:16:01 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p3RKFwCE004994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 27 Apr 2011 15:15:58 -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 p3RKFu5Q022324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 27 Apr 2011 15:15:58 -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 p3RKFuBE014352; Wed, 27 Apr 2011 13:15:56 -0700 (PDT) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.93]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Apr 2011 13:15:56 -0700 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_01CC0517.EA39B2BB" Date: Wed, 27 Apr 2011 13:15:53 -0700 Message-ID: <059AF07365DC474393A19A3AF187DF7406F8FB7B@NAHALD.us.int.genesyslab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Summary of the changes of draft-ietf-siprec-req-10 -last call Thread-Index: AcwE3y4TqEYV7EYpTvCzQYc4dfJgQwAMJfNg From: "Henry Lum" To: "Leon Portman" , , , "Elwell, John" X-OriginalArrivalTime: 27 Apr 2011 20:15:56.0229 (UTC) FILETIME=[EA6CD750:01CC0517] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: Re: [siprec] Summary of the changes of draft-ietf-siprec-req-10 - last call X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 27 Apr 2011 20:16:03 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC0517.EA39B2BB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am trying to see if we can more explicit about relating wall clock time with recording controls such as pause/resume: =20 REQ-024: The mechanism MUST provide means to relate recording and recording controls such as start/stop/pause/resume to the wall clock time. =20 Henry =20 =20 From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Leon Portman Sent: April-27-11 9:30 AM To: siprec@ietf.org; Ken Rehor (krehor)(krehor@cisco.com); Elwell, John Subject: [siprec] Summary of the changes of draft-ietf-siprec-req-10 - last call =20 Hello =20 Please see below summary of the changes for updated version of the requirements document. =20 Main changes: =20 1. Updated REQ-022, 023, 024 (all other numbers are ++, original 22 and 23 removed), thanks to Muthu and John for the text a. REQ-022: The mechanism MUST provide means for facilitating synchronization of the recorded media streams and metadata. b. REQ-023: The mechanism MUST provide means for facilitating synchronization among the recorded media streams. c. REQ-024: The mechanism MUST provide means for relating recordings to wall clock time. 2. Use Case 8 - nit pick, thanks to Muthu (me -> may be) a."In cases where calls inside or between branches must be recorded, a centralized recording system in data centers together with telephony infrastructure (e.g. PBX) may be deployed." 3. Proposed additional paragraph in the security section from the security review (not in the text yet, pending WG approval): "Integrity and correctness of the recorded sessions is not ensured by cryptographic means to ensure that the CS has not been tampered with. This would have to be done by organizational and technical controls that prevent tampering with CS participants and SRC." =20 Regards =20 Leon =20 =20 =20 =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 ------_=_NextPart_001_01CC0517.EA39B2BB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am trying to see if we can more explicit about relating= wall clock time with recording controls such as pause/resume:=

 =

REQ-0= 24: The mechanism MUST provide means to relate recording and recording co= ntrols such as start/stop/pause/resume to the wall clock time.=

 =

Henry=

=  

 

From: siprec-bounces@ietf.org [mailt= o:siprec-bounces@ietf.org] On Behalf Of Leon Portman
Sent: April-27-11 9:30 AM
To: siprec@ietf.org; Ken Rehor (krehor)(= krehor@cisco.com); Elwell, John
Subject: [siprec] Summary of th= e changes of draft-ietf-siprec-req-10 - last call

 

= Hello

 

Please see below summary of the changes for  updated version o= f the requirements document.

 

Main changes:

 

1.     =   Updated REQ-022,= 023, 024 (all other numbers are ++, original 22 and 23 removed), thanks = to Muthu and John for the text

a.    =    REQ-022: T= he mechanism MUST provide means for facilitating synchronization of the r= ecorded media streams and metadata.

b.   &= nbsp;  REQ-023: Th= e mechanism MUST provide means for facilitating synchronization among the= recorded media streams.

c.     =   REQ-024: The mec= hanism MUST provide means for relating recordings to wall clock time.

2. Use Case 8 – nit pick, thanks to Muthu (me ->= ; may be)

a."In cases where c= alls inside or between branches must be recorded, a centralized recording= system in data centers together with telephony infrastructure (e.g. PBX)= may be deployed."

         &nbs= p;      3. Proposed additional paragraph in the = security section from the security review (not in the text yet, pending W= G approval):

"Integrity and correctness of the recorded sessions is not ensur= ed by cryptographic means to ensure that the CS has not been tampered wit= h. This would have to be done by organizational and technical controls th= at prevent tampering with CS participants and SRC."

 <= /p>

Regards

 

=

Leon

 

&n= bsp;

 

 

CONFIDENTIALITY NOTICE: This e-mail and any fil= es attached may contain confidential and proprietary information of Alcat= el-Lucent and/or its affiliated entities. Access by the intended recipien= t only is authorized. Any liability arising from any party acting, or ref= raining from acting, on any information contained in this e-mail is hereb= y excluded. If you are not the intended recipient, please notify the send= er 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-mai= l and any attachments belongs to Alcatel-Lucent and/or its affiliated ent= ities. ------_=_NextPart_001_01CC0517.EA39B2BB-- From Henry.Lum@alcatel-lucent.com Wed Apr 27 14:01: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 DBB53E07A0 for ; Wed, 27 Apr 2011 14:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.165 X-Spam-Level: X-Spam-Status: No, score=-5.165 tagged_above=-999 required=5 tests=[AWL=1.434, 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 XGxV05i7mlqd for ; Wed, 27 Apr 2011 14:01:44 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 1540EE074D for ; Wed, 27 Apr 2011 14:01:44 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p3RL1gDl025284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 27 Apr 2011 16:01:42 -0500 (CDT) Received: from relay-out1.dc.genesyslab.com (relay-out1.dc.genesyslab.com [172.22.68.187]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p3RL1ehN024791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 27 Apr 2011 16:01:41 -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 p3RL1d11021080; Wed, 27 Apr 2011 14:01:39 -0700 (PDT) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.93]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Apr 2011 14:01:39 -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, 27 Apr 2011 14:01:37 -0700 Message-ID: <059AF07365DC474393A19A3AF187DF7406F8FBA1@NAHALD.us.int.genesyslab.com> In-Reply-To: <4DB81F8A.8000306@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Does MS have life outside a particular CS? (was RE: comments on draft-ram-siprec-metadata-04) Thread-Index: AcwE4la6UC8biR97S/qhdRqJ4BkaIQAOo7Vw References: <4DAD8A5F.4040506@cisco.com><4DADA8E6.9010006@cisco.com> <35BCE99A477D6A49 8 6 F B 2216 D8CF2CFD06133A56@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD06133DD4@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD06133E6B@XMB-BGL-417.cisco.com> <4DB81F8A.8000306@cisco.com> From: "Henry Lum" To: "Paul Kyzivat" , "Parthasarathi R (partr)" X-OriginalArrivalTime: 27 Apr 2011 21:01:39.0587 (UTC) FILETIME=[4D980D30:01CC051E] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: siprec@ietf.org Subject: Re: [siprec] Does MS have life outside a particular CS? (was RE: comments on draft-ram-siprec-metadata-04) X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 27 Apr 2011 21:01:46 -0000 > Presumably the RTP streams associated with the RS end when the RS ends. > That does not necessarily mean that the media stream of a CS also ends at > that time. It could be picked up again in a different RS by the same or > different SRC. IIUC, a single CS is only mapped to a single SRC. If we have a media stream of a CS picked by another SRC, then it should be a different CS but can be related to the same CS group. Henry > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf > Of Paul Kyzivat > Sent: April-27-11 9:52 AM > To: Parthasarathi R (partr) > Cc: siprec@ietf.org > Subject: Re: [siprec] Does MS have life outside a particular CS? (was RE: > comments on draft-ram-siprec-metadata-04) >=20 > There seems to be some confusion in this discussion about what a MS is. >=20 > On one hand there is an m-line in the SDP of the RS, and a corresponding RTP > stream. >=20 > On another hand there is an m-line in a CS and a corresponding RTP stream. >=20 > And then there is an MS described in the metadata conveyed over the RS. >=20 > And for both of the above, a single m-line might correspond to different RTP > streams over time, due to renegotiating the address and/or port of the > recipient, or by a different sender sending to the same port. >=20 > There is a mapping between one or more RTP streams in the CS (or multiple > CSs?) and one or more RTP streams in the RS. The metadata hopefully > describes that mapping. >=20 > But perhaps we don't have full agreement on what sorts of mappings are > possible. Some that I think we allow are: > - one CS RTP stream to one RS RTP stream. > - multiple concurrent CS RTP streams mixed to one > RS RTP stream > - multiple CS RTP streams sequentially mapped to the same > RS RTP stream > ... >=20 > Presumably the RTP streams associated with the RS end when the RS ends. > That does not necessarily mean that the media stream of a CS also ends at > that time. It could be picked up again in a different RS by the same or > different SRC. >=20 > Thanks, > Paul >=20 > On 4/27/2011 2:30 AM, Parthasarathi R (partr) wrote: > > John, > > > > My intention is show the complexity in the metadata model in the > > current form. Global unique id solves the issue but let us explore for > > better optimized solution with more local unique id if any exists. > > > > I have created another mail thread for adding the recording type > > attribute which helps in most of the metadata blocks to have local > > unique id rather than global unique id. Let us see how others > > visualize that attribute. > > > > IMO, it may better to have globally unique id with the current > > metadata model attributes. We may be able to add the normative > > statement that "Media stream (MS) MUST be terminated when CS is > > terminated" in the metadata but in reality, MS is within the scope of > > RS which is forced to delete for no reason. These sort will be > > restrictive for few SRC implementation. For eg: RS may created MS with > > RSVP which may not prefer to terminate the resource during RS > > mid-session changes like CS changes even though intermediate time with > > no media but the above normative statement forces to break those SRC > implementation. > > > > Please read inline for more comments. > > > > Thanks > > Partha > > > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Friday, April 22, 2011 1:48 AM > > To: Parthasarathi R (partr); Ram Mohan R (rmohanr); Paul Kyzivat > > (pkyzivat) > > Cc: siprec@ietf.org > > Subject: RE: Does MS have life outside a particular CS? (was RE: > > [siprec] comments on draft-ram-siprec-metadata-04) > > > > > > > >> -----Original Message----- > >> From: Parthasarathi R (partr) [mailto:partr@cisco.com] > >> Sent: 21 April 2011 17:20 > >> To: Elwell, John; Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > >> Cc: siprec@ietf.org > >> Subject: RE: Does MS have life outside a particular CS? (was > >> RE: [siprec] comments on draft-ram-siprec-metadata-04) > >> > >> John, > >> > >> Please read inline. > >> > >> Thanks > >> Partha > >> > >> -----Original Message----- > >> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > >> Sent: Thursday, April 21, 2011 9:12 PM > >> To: Parthasarathi R (partr); Ram Mohan R (rmohanr); Paul Kyzivat > >> (pkyzivat) > >> Cc: siprec@ietf.org > >> Subject: RE: Does MS have life outside a particular CS? (was RE: > >> [siprec] comments on draft-ram-siprec-metadata-04) > >> > >> Partha, > >> > >>> -----Original Message----- > >>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] > >>> Sent: 21 April 2011 14:25 > >>> To: Elwell, John; Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > >>> Cc: siprec@ietf.org > >>> Subject: RE: Does MS have life outside a particular CS? (was > >>> RE: [siprec] comments on draft-ram-siprec-metadata-04) > >>> > >>> John, > >>> > >>> I could think of one usecase wherein MS is outside CS but within > >>> single RS. The usecase is multiple CS within single RS and MS. The > >>> usecase is as follows: > >>> > >>> B2BUA acts as SRC. A, B, C are participants within single B2BUA. A > >>> creates single RS for a CSG. > >>> > >>> 1) A calls B through B2BUA. B2BUA creates RS towards SRS with CSG1, > >>> CS1, > >>> MS1 (A's media stream), MS2 (B's media stream), Participant1 as A& > >>> Participant2 as B. > >> [JRE] Why two media streams? Why not a single MS, with both A and B > >> sending and receiving that MS? > >> The media streams are un-mixed, MS1 points to RTP from A > >> through label attribute in MS1 SDP, MS2 points to RTP from B through > >> label attribute in MS2 SDP > > [JRE] Reading the metadata model again, I think it does seem to imply > > two Media Stream objects if the two directions for a 2-party call are > > sent unmixed (as two m-lines in the RS SDP), so I will concede that we > > have two Media Stream objects here. I had been thinking of a slightly > > different model, where there is one Media Stream, but associations > > between the Media Stream and Participants pointed to different m-lines > > in the RS SDP. > > > >> > >>> 2) B connects with C through B2BUA > >>> 3) B transfer the call of A& B to C using REFER, B2BUA > >> converts REFER > >> > >>> to RE-INVITE towards A& C and A& C are connected. B2BUA > >> updates RS > >>> with CS2, Participant1 as A& participant2 as C, MS1(A's media > >>> stream), MS2(C's media stream). > >> [JRE] I would have expected, from my understanding of the metadata > >> model, that the CS2 would have a new MS, with both A and B sending > >> and > > > >> receiving that new MS. > >> > >> It is not mandatory because participant information will be > >> updated and pointing to the same m-line in RS with same label > >> attribute. > >> From SRS perspective, the same media stream with the update in the > >> participant name only. Say MS2 is stored as one record with B as > >> participant for T0 to T1 timelines and C as participant from T1 to T2. > >> > > [JRE] Or alternatively it could be modelled that when a new CS starts > > there is a new Media Stream object, still pointing to the same m-line > > in the RS SDP. > > > > The purpose of unique-id will go for toss here. The same > > media stream (MS) has unique id "id1" initially and later it will have "id2" > > which will not be good for replay. Of course, MS life is always within > > RS in this scenario but not within CS. So, Unique Id within RS will > > serve the purpose > > > > This would avoid the need for a Media Stream object to survive > > beyond the lifetime of a CS, and therefore allow local identification. > > While there is no CS in progress, the m-line would be disabled (port > > 0) and would not be referenced by any Media Stream. > > > > RS m-line is not required to 0 because it shall change into > > "a=3Dinactive" as well. There is no change in the resource reservatio= n > > in both SRC and SRS > > > >> > >>> There is no update on RS1, CSG1, MS1, MS2. MS2 will become MS2 with > >>> the new association and in terms of format, it will associate with > >>> tag. > >>> > >>> In the above scenario, MS have life outside CS but it is within RS. > >> [JRE] I can see how it COULD work like that, but it is not intuitive. > >> > >> In SIPREC solution, UPDATE message with CS2(session > >> element) , > >> participant "C" element are received in SRS. This partial update of > >> UPDATE helps to make this scenario work. There is no change in term > >> stream element or RS SDP > >> > >> To me, a new CS means the existing media stream stops and a new media > >> stream is created. > >> > >> I'm interested knowing whether you propose that MS MUST > >> stop in case CS ends and the above scenario is outside the scope of > SIPREC? > >> > >> > >>> The > >>> unique id shall be within RS scope as mentioned in IETF-80 meeting. > >>> But in another situation, MS is outside the scope of RS but > >> within CS > >>> and the usecase is Multiple RS for single CS, details are > >> as follows: > >>> > >>> A, B are pariticipants. A acts as SRC which tear down RS > >> whenever hold > >> > >>> happens& creates new RS when resume happens. > >>> > >>> 1) A calls B. A creates RS1 towards SRS with CS1, MS1 (A's media > >>> stream), MS2 (B's Media stream),Participant1 as A& > >> Participant2 as B. > >> [JRE] Again, I would model this as a single MS, to which both A and B > >> contribute. > >> Again, unmixed stream from A and B > >>> 2) A put B on hold. A tear down RS1. > >>> 3) A resume B. A creates RS2 towards SRS with CS1, MS1 (A's media > >>> stream), MS2 (B's Media stream),Participant1 as A& > >> Participant2 as B > >>> > >>> Here MS1& MS2 needs to be same across RS to group media streams > >>> correctly. Please let me know your opinion here. > >> > >> [JRE] Although I disagree that we have two Media Streams here, I do > >> agree that the single Media Stream could be considered to survive the > >> hold/resume, and hence survive from RS1 to RS2. But the MS is within > >> the context of the same CS (CS1), and therefore this is outside the > >> scope of this particular thread, which is asking whether an MS can > >> have a life outside a particular CS. In this case the MS continues to > >> be associated with the CS, so I don't have a problem with that. > >> > >> I have 2nd example to illustrate MS have life outside RS. > >> > >> > >> So you have failed to convince me that an MS needs to have a life > >> outside a CS. > >> > >> In case the above scenario-1 way of recording is outside > >> the scope of SIPREC, I agree with you that MS does not have life > >> outside a > > > >> particular CS > > [JRE] I assume you are talking about the call transfer case. I am not > > saying that use case is outside the scope of SIPREC. I am just saying > > that it can be modelled a different way, which may be advantageous in > > terms of the number of globally unique identifiers needed. > > > > > > John (as individual) > > > > > > > >> > >> John (as individual) > >> > >> > >>> > >>> Having said that MS have life outside a particular CS, I create > >>> separate thread within unique how it shall be handled. > >>> > >>> Thanks > >>> Partha > >>> > >>> -----Original Message----- > >>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > >>> Sent: Thursday, April 21, 2011 12:01 PM > >>> To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > >>> Cc: Parthasarathi R (partr); siprec@ietf.org > >>> Subject: Does MS have life outside a particular CS? (was > >> RE: [siprec] > >>> comments on draft-ram-siprec-metadata-04) > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > >>>> Sent: 20 April 2011 18:08 > >>>> To: Elwell, John; Paul Kyzivat (pkyzivat) > >>>> Cc: Parthasarathi R (partr); siprec@ietf.org > >>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > >>>> > >>>> Hi John, > >>>> > >>>> Please see inline [RAM] > >>>> > >>>>> -----Original Message----- > >>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > >>>>> Sent: Wednesday, April 20, 2011 8:19 PM > >>>>> To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > >>>>> Cc: Parthasarathi R (partr); siprec@ietf.org > >>>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > >>>>> > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > >>>>>> Sent: 20 April 2011 14:52 > >>>>>> To: Elwell, John; Paul Kyzivat (pkyzivat) > >>>>>> Cc: Parthasarathi R (partr); siprec@ietf.org > >>>>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > >>>>>> > >>>>>> John, > >>>>>> > >>>>>> I agree with you that normal cases RS will remain at > >>> least for the > >>> > >>>>>> duration of CS. However it is common to have use cases where > >>>>> recording > >>>>>> is done for first few mins of a CS and then stopped, > >>>> re-started at a > >>>>>> later point (e.g Recording of a company meeting where > >>> you may want > >>>> to > >>>>>> record only portions of meeting). > >>>>>> > >>>>>> In any case, the point I like to high light here is, MS > >>>> block could > >>>>> be > >>>>>> common across RS and even across CS[ due to consult > >>>> transfer e.t.c]. > >>>>>> These use cases indicate the need to have a unique ID > >>> for MS block > >>> > >>>>>> (similar to the UUID that we have defined in format) as > >>> we cannot > >>>>>> depend on neither CS ID or RS ID. > >>>>> [JRE] I am having a hard time understanding the concept > >>> of a single > >>>>> Media Stream that survives across multiple CSs. For > >>> example, in the > >>>>> case of transfer, I would have thought new Media > >> Streams would be > >>>>> created. > >>>> > >>>> [RAM] > >>>> Here is my thoughts. > >>>> 1) There can be multiple RS per CS > >>>> RS1 --- CS1--MS1 > >>>> RS2----CS1--MS1 > >>>> Examples are partial recording of CS (like recording parts > >>> of meeting, > >>> > >>>> redundant recording where there are multiple SRCs recording > >>> the same > >>>> CS) > >>> [JRE] Agreed. In this case MS1 is local to CS1. > >>> > >>>> > >>>> 2) There can be same Media Stream across multiple CS. > >>>> RS1--- CS1--- MS1 > >>>> RS2--CS2--MS1 > >>>> Examples are Multicast MoH played to multiple end points who are > >>>> potentially part of disjoint CSs where each CS is recorded > >>> as part of > >>>> separate RS. > >>>> > >>>> Of course the above is arguable where the stream is same or > >>> different. > >>>> My view is since the UA (that supplies the Multicast MoH) and its > >>>> media are same across all CS, I think it can be represented > >>> as same MS > >>> > >>>> block. > >>> [JRE] I would argue these are different MSs. I agree that a medium > >>> such as music on hold might be sent, in synch, to multiple > >>> participants in multiple CSs. In that particular situation > >> there might > >> > >>> be some efficiency saving by calling it the same MS. > >> However, I would > >>> suggest (although this is not my field of expertise) it would make > >>> life a lot harder for the SRS and its database. I would > >> have expected > >>> to want to record a complete CS (all its participants and media > >>> streams) as a complete recording, which could be deleted, > >> copied, and > >> > >>> so on without having to go looking for other objects that complete > >>> that recording and are shared with other recordings. For > >> example, if > >>> you delete a recording, you would want to delete all its > >> MSs, but not > >>> those used by other recordings, although you would need a garbage > >>> collection mechanism to delete an MS recording when it is no longer > >>> used by any CS recordings. Rather ugly. Making a MS local to a CS > >>> would simplify all this. > >>> > >>>> > >>>> > >>>> However it is still possible to treat each as separate > >>> stream in the > >>>> model, in which case the information that it is the same MS > >>> played by > >>>> a UA to different CS will be lost. I don't know if there is an > >>>> interest to capture this level of detail and if it is of > >> any use to > >>>> SRS. > >>> [JRE] I assume what you are saying here is not that > >> information will > >>> be lost, but that you will be unable to tell, without doing a > >>> comparison, whether two different MSs played to participants in two > >>> different CSs are identical or not for the particular time > >> span that > >>> is common. I don't see where such a requirement would come from. > >>> > >>> John (as individual) > >>> > >>> > >> > > > _______________________________________________ > 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@cisco.com Wed Apr 27 15:55: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 1A3F7E0791 for ; Wed, 27 Apr 2011 15:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.463 X-Spam-Level: X-Spam-Status: No, score=-110.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 1f60LAfdoHyn for ; Wed, 27 Apr 2011 15:55:33 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC42E07CB for ; Wed, 27 Apr 2011 15:55:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=18900; q=dns/txt; s=iport; t=1303944933; x=1305154533; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=VhXe0RJNb+sNLyWFNNFPL5xQUWNa1J2XABdjYPFNC5s=; b=WtL7dz2cLHzacBYn/I6NGfczCCCNcnw5GfuTYV2T/qarJgK3CTFYR0fK EO37FlBtKqhce7+FO73RfdnykzEM/13bxPGnnrU6/BLJ6d0AFhew7u2Fj 1IhK4nt5XojMQ0d4ikA/DUZhlUthVSSR5ZRFsMuaG3M8pyNvR6S3zbj+p Q=; X-IronPort-AV: E=Sophos;i="4.64,277,1301875200"; d="scan'208";a="345965538" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-2.cisco.com with ESMTP; 27 Apr 2011 22:55:33 +0000 Received: from [161.44.174.124] (dhcp-161-44-174-124.cisco.com [161.44.174.124]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3RMtWdJ005929; Wed, 27 Apr 2011 22:55:32 GMT Message-ID: <4DB89EE3.8070504@cisco.com> Date: Wed, 27 Apr 2011 18:55:31 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Henry Lum References: <4DADA8E6.9010006@cisco.com> <35BCE99A477D6A49 8 6 F B 2216 D8CF2CFD06133A56@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD06133DD4@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD06133E6B@XMB-BGL-417.cisco.com> <4DB81F8A.8000306@cisco.com> <059AF07365DC474393A19A3AF187DF7406F8FBA1@NAHALD.us.int.genesyslab.com> In-Reply-To: <059AF07365DC474393A19A3AF187DF7406F8FBA1@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] Does MS have life outside a particular CS? (was RE: comments on draft-ram-siprec-metadata-04) X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 27 Apr 2011 22:55:35 -0000 On 4/27/2011 5:01 PM, Henry Lum wrote: >> Presumably the RTP streams associated with the RS end when the RS > ends. >> That does not necessarily mean that the media stream of a CS also ends > at >> that time. It could be picked up again in a different RS by the same > or >> different SRC. > > IIUC, a single CS is only mapped to a single SRC. If we have a media > stream of a CS picked by another SRC, then it should be a different CS > but can be related to the same CS group. Two things: It could be the same SRC but two different RSs. (Perhaps it drops the RS during a long pause, or because the SRS crashed and restarted and the SRC had to reconnect.) If there are two different SRCs, and they happen to know it is the same CS (I'm not proposing *how* they know), it would be better to refer to the same CS. I'm not saying we should require SRCs to do such things - only that a design that permits this is better than one that does not. Thanks, Paul > Henry > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf >> Of Paul Kyzivat >> Sent: April-27-11 9:52 AM >> To: Parthasarathi R (partr) >> Cc: siprec@ietf.org >> Subject: Re: [siprec] Does MS have life outside a particular CS? (was > RE: >> comments on draft-ram-siprec-metadata-04) >> >> There seems to be some confusion in this discussion about what a MS > is. >> >> On one hand there is an m-line in the SDP of the RS, and a > corresponding RTP >> stream. >> >> On another hand there is an m-line in a CS and a corresponding RTP > stream. >> >> And then there is an MS described in the metadata conveyed over the > RS. >> >> And for both of the above, a single m-line might correspond to > different RTP >> streams over time, due to renegotiating the address and/or port of the >> recipient, or by a different sender sending to the same port. >> >> There is a mapping between one or more RTP streams in the CS (or > multiple >> CSs?) and one or more RTP streams in the RS. The metadata hopefully >> describes that mapping. >> >> But perhaps we don't have full agreement on what sorts of mappings are >> possible. Some that I think we allow are: >> - one CS RTP stream to one RS RTP stream. >> - multiple concurrent CS RTP streams mixed to one >> RS RTP stream >> - multiple CS RTP streams sequentially mapped to the same >> RS RTP stream >> ... >> >> Presumably the RTP streams associated with the RS end when the RS > ends. >> That does not necessarily mean that the media stream of a CS also ends > at >> that time. It could be picked up again in a different RS by the same > or >> different SRC. >> >> Thanks, >> Paul >> >> On 4/27/2011 2:30 AM, Parthasarathi R (partr) wrote: >>> John, >>> >>> My intention is show the complexity in the metadata model in the >>> current form. Global unique id solves the issue but let us explore > for >>> better optimized solution with more local unique id if any exists. >>> >>> I have created another mail thread for adding the recording type >>> attribute which helps in most of the metadata blocks to have local >>> unique id rather than global unique id. Let us see how others >>> visualize that attribute. >>> >>> IMO, it may better to have globally unique id with the current >>> metadata model attributes. We may be able to add the normative >>> statement that "Media stream (MS) MUST be terminated when CS is >>> terminated" in the metadata but in reality, MS is within the scope > of >>> RS which is forced to delete for no reason. These sort will be >>> restrictive for few SRC implementation. For eg: RS may created MS > with >>> RSVP which may not prefer to terminate the resource during RS >>> mid-session changes like CS changes even though intermediate time > with >>> no media but the above normative statement forces to break those SRC >> implementation. >>> >>> Please read inline for more comments. >>> >>> Thanks >>> Partha >>> >>> -----Original Message----- >>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>> Sent: Friday, April 22, 2011 1:48 AM >>> To: Parthasarathi R (partr); Ram Mohan R (rmohanr); Paul Kyzivat >>> (pkyzivat) >>> Cc: siprec@ietf.org >>> Subject: RE: Does MS have life outside a particular CS? (was RE: >>> [siprec] comments on draft-ram-siprec-metadata-04) >>> >>> >>> >>>> -----Original Message----- >>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] >>>> Sent: 21 April 2011 17:20 >>>> To: Elwell, John; Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) >>>> Cc: siprec@ietf.org >>>> Subject: RE: Does MS have life outside a particular CS? (was >>>> RE: [siprec] comments on draft-ram-siprec-metadata-04) >>>> >>>> John, >>>> >>>> Please read inline. >>>> >>>> Thanks >>>> Partha >>>> >>>> -----Original Message----- >>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>>> Sent: Thursday, April 21, 2011 9:12 PM >>>> To: Parthasarathi R (partr); Ram Mohan R (rmohanr); Paul Kyzivat >>>> (pkyzivat) >>>> Cc: siprec@ietf.org >>>> Subject: RE: Does MS have life outside a particular CS? (was RE: >>>> [siprec] comments on draft-ram-siprec-metadata-04) >>>> >>>> Partha, >>>> >>>>> -----Original Message----- >>>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] >>>>> Sent: 21 April 2011 14:25 >>>>> To: Elwell, John; Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) >>>>> Cc: siprec@ietf.org >>>>> Subject: RE: Does MS have life outside a particular CS? (was >>>>> RE: [siprec] comments on draft-ram-siprec-metadata-04) >>>>> >>>>> John, >>>>> >>>>> I could think of one usecase wherein MS is outside CS but within >>>>> single RS. The usecase is multiple CS within single RS and MS. > The >>>>> usecase is as follows: >>>>> >>>>> B2BUA acts as SRC. A, B, C are participants within single B2BUA. A >>>>> creates single RS for a CSG. >>>>> >>>>> 1) A calls B through B2BUA. B2BUA creates RS towards SRS with > CSG1, >>>>> CS1, >>>>> MS1 (A's media stream), MS2 (B's media stream), Participant1 as A& >>>>> Participant2 as B. >>>> [JRE] Why two media streams? Why not a single MS, with both A and B >>>> sending and receiving that MS? >>>> The media streams are un-mixed, MS1 points to RTP from A >>>> through label attribute in MS1 SDP, MS2 points to RTP from B > through >>>> label attribute in MS2 SDP >>> [JRE] Reading the metadata model again, I think it does seem to > imply >>> two Media Stream objects if the two directions for a 2-party call > are >>> sent unmixed (as two m-lines in the RS SDP), so I will concede that > we >>> have two Media Stream objects here. I had been thinking of a > slightly >>> different model, where there is one Media Stream, but associations >>> between the Media Stream and Participants pointed to different > m-lines >>> in the RS SDP. >>> >>>> >>>>> 2) B connects with C through B2BUA >>>>> 3) B transfer the call of A& B to C using REFER, B2BUA >>>> converts REFER >>>> >>>>> to RE-INVITE towards A& C and A& C are connected. B2BUA >>>> updates RS >>>>> with CS2, Participant1 as A& participant2 as C, MS1(A's media >>>>> stream), MS2(C's media stream). >>>> [JRE] I would have expected, from my understanding of the metadata >>>> model, that the CS2 would have a new MS, with both A and B sending >>>> and >>> >>>> receiving that new MS. >>>> >>>> It is not mandatory because participant information will > be >>>> updated and pointing to the same m-line in RS with same label >>>> attribute. >>>> From SRS perspective, the same media stream with the update in the >>>> participant name only. Say MS2 is stored as one record with B as >>>> participant for T0 to T1 timelines and C as participant from T1 to > T2. >>>> >>> [JRE] Or alternatively it could be modelled that when a new CS > starts >>> there is a new Media Stream object, still pointing to the same > m-line >>> in the RS SDP. >>> >>> The purpose of unique-id will go for toss here. The same >>> media stream (MS) has unique id "id1" initially and later it will > have "id2" >>> which will not be good for replay. Of course, MS life is always > within >>> RS in this scenario but not within CS. So, Unique Id within RS will >>> serve the purpose >>> >>> This would avoid the need for a Media Stream object to survive >>> beyond the lifetime of a CS, and therefore allow local > identification. >>> While there is no CS in progress, the m-line would be disabled (port >>> 0) and would not be referenced by any Media Stream. >>> >>> RS m-line is not required to 0 because it shall change > into >>> "a=inactive" as well. There is no change in the resource reservation >>> in both SRC and SRS >>> >>>> >>>>> There is no update on RS1, CSG1, MS1, MS2. MS2 will become MS2 > with >>>>> the new association and in terms of format, it will associate with >>>>> tag. >>>>> >>>>> In the above scenario, MS have life outside CS but it is within > RS. >>>> [JRE] I can see how it COULD work like that, but it is not > intuitive. >>>> >>>> In SIPREC solution, UPDATE message with CS2(session >>>> element) , >>>> participant "C" element are received in SRS. This partial update of >>>> UPDATE helps to make this scenario work. There is no change in term >>>> stream element or RS SDP >>>> >>>> To me, a new CS means the existing media stream stops and a new > media >>>> stream is created. >>>> >>>> I'm interested knowing whether you propose that MS MUST >>>> stop in case CS ends and the above scenario is outside the scope of >> SIPREC? >>>> >>>> >>>>> The >>>>> unique id shall be within RS scope as mentioned in IETF-80 > meeting. >>>>> But in another situation, MS is outside the scope of RS but >>>> within CS >>>>> and the usecase is Multiple RS for single CS, details are >>>> as follows: >>>>> >>>>> A, B are pariticipants. A acts as SRC which tear down RS >>>> whenever hold >>>> >>>>> happens& creates new RS when resume happens. >>>>> >>>>> 1) A calls B. A creates RS1 towards SRS with CS1, MS1 (A's media >>>>> stream), MS2 (B's Media stream),Participant1 as A& >>>> Participant2 as B. >>>> [JRE] Again, I would model this as a single MS, to which both A and > B >>>> contribute. >>>> Again, unmixed stream from A and B >>>>> 2) A put B on hold. A tear down RS1. >>>>> 3) A resume B. A creates RS2 towards SRS with CS1, MS1 (A's media >>>>> stream), MS2 (B's Media stream),Participant1 as A& >>>> Participant2 as B >>>>> >>>>> Here MS1& MS2 needs to be same across RS to group media streams >>>>> correctly. Please let me know your opinion here. >>>> >>>> [JRE] Although I disagree that we have two Media Streams here, I do >>>> agree that the single Media Stream could be considered to survive > the >>>> hold/resume, and hence survive from RS1 to RS2. But the MS is > within >>>> the context of the same CS (CS1), and therefore this is outside the >>>> scope of this particular thread, which is asking whether an MS can >>>> have a life outside a particular CS. In this case the MS continues > to >>>> be associated with the CS, so I don't have a problem with that. >>>> >>>> I have 2nd example to illustrate MS have life outside RS. >>>> >>>> >>>> So you have failed to convince me that an MS needs to have a life >>>> outside a CS. >>>> >>>> In case the above scenario-1 way of recording is outside >>>> the scope of SIPREC, I agree with you that MS does not have life >>>> outside a >>> >>>> particular CS >>> [JRE] I assume you are talking about the call transfer case. I am > not >>> saying that use case is outside the scope of SIPREC. I am just > saying >>> that it can be modelled a different way, which may be advantageous > in >>> terms of the number of globally unique identifiers needed. >>> >>> >>> John (as individual) >>> >>> >>> >>>> >>>> John (as individual) >>>> >>>> >>>>> >>>>> Having said that MS have life outside a particular CS, I create >>>>> separate thread within unique how it shall be handled. >>>>> >>>>> Thanks >>>>> Partha >>>>> >>>>> -----Original Message----- >>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>>>> Sent: Thursday, April 21, 2011 12:01 PM >>>>> To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) >>>>> Cc: Parthasarathi R (partr); siprec@ietf.org >>>>> Subject: Does MS have life outside a particular CS? (was >>>> RE: [siprec] >>>>> comments on draft-ram-siprec-metadata-04) >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] >>>>>> Sent: 20 April 2011 18:08 >>>>>> To: Elwell, John; Paul Kyzivat (pkyzivat) >>>>>> Cc: Parthasarathi R (partr); siprec@ietf.org >>>>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 >>>>>> >>>>>> Hi John, >>>>>> >>>>>> Please see inline [RAM] >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>>>>>> Sent: Wednesday, April 20, 2011 8:19 PM >>>>>>> To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) >>>>>>> Cc: Parthasarathi R (partr); siprec@ietf.org >>>>>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] >>>>>>>> Sent: 20 April 2011 14:52 >>>>>>>> To: Elwell, John; Paul Kyzivat (pkyzivat) >>>>>>>> Cc: Parthasarathi R (partr); siprec@ietf.org >>>>>>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 >>>>>>>> >>>>>>>> John, >>>>>>>> >>>>>>>> I agree with you that normal cases RS will remain at >>>>> least for the >>>>> >>>>>>>> duration of CS. However it is common to have use cases where >>>>>>> recording >>>>>>>> is done for first few mins of a CS and then stopped, >>>>>> re-started at a >>>>>>>> later point (e.g Recording of a company meeting where >>>>> you may want >>>>>> to >>>>>>>> record only portions of meeting). >>>>>>>> >>>>>>>> In any case, the point I like to high light here is, MS >>>>>> block could >>>>>>> be >>>>>>>> common across RS and even across CS[ due to consult >>>>>> transfer e.t.c]. >>>>>>>> These use cases indicate the need to have a unique ID >>>>> for MS block >>>>> >>>>>>>> (similar to the UUID that we have defined in format) as >>>>> we cannot >>>>>>>> depend on neither CS ID or RS ID. >>>>>>> [JRE] I am having a hard time understanding the concept >>>>> of a single >>>>>>> Media Stream that survives across multiple CSs. For >>>>> example, in the >>>>>>> case of transfer, I would have thought new Media >>>> Streams would be >>>>>>> created. >>>>>> >>>>>> [RAM] >>>>>> Here is my thoughts. >>>>>> 1) There can be multiple RS per CS >>>>>> RS1 --- CS1--MS1 >>>>>> RS2----CS1--MS1 >>>>>> Examples are partial recording of CS (like recording parts >>>>> of meeting, >>>>> >>>>>> redundant recording where there are multiple SRCs recording >>>>> the same >>>>>> CS) >>>>> [JRE] Agreed. In this case MS1 is local to CS1. >>>>> >>>>>> >>>>>> 2) There can be same Media Stream across multiple CS. >>>>>> RS1--- CS1--- MS1 >>>>>> RS2--CS2--MS1 >>>>>> Examples are Multicast MoH played to multiple end points who are >>>>>> potentially part of disjoint CSs where each CS is recorded >>>>> as part of >>>>>> separate RS. >>>>>> >>>>>> Of course the above is arguable where the stream is same or >>>>> different. >>>>>> My view is since the UA (that supplies the Multicast MoH) and its >>>>>> media are same across all CS, I think it can be represented >>>>> as same MS >>>>> >>>>>> block. >>>>> [JRE] I would argue these are different MSs. I agree that a medium >>>>> such as music on hold might be sent, in synch, to multiple >>>>> participants in multiple CSs. In that particular situation >>>> there might >>>> >>>>> be some efficiency saving by calling it the same MS. >>>> However, I would >>>>> suggest (although this is not my field of expertise) it would make >>>>> life a lot harder for the SRS and its database. I would >>>> have expected >>>>> to want to record a complete CS (all its participants and media >>>>> streams) as a complete recording, which could be deleted, >>>> copied, and >>>> >>>>> so on without having to go looking for other objects that complete >>>>> that recording and are shared with other recordings. For >>>> example, if >>>>> you delete a recording, you would want to delete all its >>>> MSs, but not >>>>> those used by other recordings, although you would need a garbage >>>>> collection mechanism to delete an MS recording when it is no > longer >>>>> used by any CS recordings. Rather ugly. Making a MS local to a CS >>>>> would simplify all this. >>>>> >>>>>> >>>>>> >>>>>> However it is still possible to treat each as separate >>>>> stream in the >>>>>> model, in which case the information that it is the same MS >>>>> played by >>>>>> a UA to different CS will be lost. I don't know if there is an >>>>>> interest to capture this level of detail and if it is of >>>> any use to >>>>>> SRS. >>>>> [JRE] I assume what you are saying here is not that >>>> information will >>>>> be lost, but that you will be unable to tell, without doing a >>>>> comparison, whether two different MSs played to participants in > two >>>>> different CSs are identical or not for the particular time >>>> span that >>>>> is common. I don't see where such a requirement would come from. >>>>> >>>>> John (as individual) >>>>> >>>>> >>>> >>> >> _______________________________________________ >> 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 Wed Apr 27 23:24: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 A8317E062A for ; Wed, 27 Apr 2011 23:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.913 X-Spam-Level: X-Spam-Status: No, score=-104.913 tagged_above=-999 required=5 tests=[AWL=1.685, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 Yl3J2SVksJG2 for ; Wed, 27 Apr 2011 23:24:18 -0700 (PDT) Received: from mail182.messagelabs.com (mail182.messagelabs.com [85.158.139.83]) by ietfa.amsl.com (Postfix) with SMTP id C4272E064B for ; Wed, 27 Apr 2011 23:24:17 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-6.tower-182.messagelabs.com!1303971856!5726539!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 21447 invoked from network); 28 Apr 2011 06:24:16 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-6.tower-182.messagelabs.com with SMTP; 28 Apr 2011 06:24:16 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 108AF23F03DB; Thu, 28 Apr 2011 08:24:16 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 28 Apr 2011 08:24:16 +0200 From: "Elwell, John" To: Henry Lum , Leon Portman , "siprec@ietf.org" , "krehor@cisco.com" Date: Thu, 28 Apr 2011 08:24:14 +0200 Thread-Topic: [siprec] Summary of the changes of draft-ietf-siprec-req-10 - last call Thread-Index: AcwE3y4TqEYV7EYpTvCzQYc4dfJgQwAMJfNgABdFL4A= Message-ID: References: <059AF07365DC474393A19A3AF187DF7406F8FB7B@NAHALD.us.int.genesyslab.com> In-Reply-To: <059AF07365DC474393A19A3AF187DF7406F8FB7B@NAHALD.us.int.genesyslab.com> 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_A444A0F8084434499206E78C106220CA0875F84616MCHP058Agloba_" MIME-Version: 1.0 Subject: Re: [siprec] Summary of the changes of draft-ietf-siprec-req-10 - last call X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 28 Apr 2011 06:24:20 -0000 --_000_A444A0F8084434499206E78C106220CA0875F84616MCHP058Agloba_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable OK for me. John ________________________________ From: Henry Lum [mailto:Henry.Lum@alcatel-lucent.com] Sent: 27 April 2011 21:16 To: Leon Portman; siprec@ietf.org; krehor@cisco.com; Elwell, John Subject: RE: [siprec] Summary of the changes of draft-ietf-siprec-req-10 - = last call I am trying to see if we can more explicit about relating wall clock time w= ith recording controls such as pause/resume: REQ-024: The mechanism MUST provide means to relate recording and recording= controls such as start/stop/pause/resume to the wall clock time. Henry From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Leon Portman Sent: April-27-11 9:30 AM To: siprec@ietf.org; Ken Rehor (krehor)(krehor@cisco.com); Elwell, John Subject: [siprec] Summary of the changes of draft-ietf-siprec-req-10 - last= call Hello Please see below summary of the changes for updated version of the require= ments document. Main changes: 1. Updated REQ-022, 023, 024 (all other numbers are ++, original 22 a= nd 23 removed), thanks to Muthu and John for the text a. REQ-022: The mechanism MUST provide means for facilitating synchro= nization of the recorded media streams and metadata. b. REQ-023: The mechanism MUST provide means for facilitating synchron= ization among the recorded media streams. c. REQ-024: The mechanism MUST provide means for relating recordings = to wall clock time. 2. Use Case 8 - nit pick, thanks to Muthu (me -> may be) a."In cases where calls inside or between branches must be recorded, a cent= ralized recording system in data centers together with telephony infrastruc= ture (e.g. PBX) may be deployed." 3. Proposed additional paragraph in the security section fr= om the security review (not in the text yet, pending WG approval): "Integrity and correctness of the recorded sessions is not ensured by crypt= ographic means to ensure that the CS has not been tampered with. This would= have to be done by organizational and technical controls that prevent tamp= ering with CS participants and SRC." Regards Leon CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain conf= idential and proprietary information of Alcatel-Lucent and/or its affiliate= d entities. Access by the intended recipient only is authorized. Any liabil= ity arising from any party acting, or refraining from acting, on any inform= ation contained in this e-mail is hereby excluded. If you are not the inten= ded recipient, please notify the sender immediately, destroy the original t= ransmission and its attachments and do not disclose the contents to any oth= er 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-Luc= ent and/or its affiliated entities. --_000_A444A0F8084434499206E78C106220CA0875F84616MCHP058Agloba_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
OK for=20 me.
 
John

From: Henry Lum=20 [mailto:Henry.Lum@alcatel-lucent.com]
Sent: 27 April 2011=20 21:16
To: Leon Portman; siprec@ietf.org; krehor@cisco.com; Elwe= ll,=20 John
Subject: RE: [siprec] Summary of the changes of=20 draft-ietf-siprec-req-10 - last call

I am trying to see if= we can=20 more explicit about relating wall clock time with recording controls such= as=20 pause/resume:

 

REQ-024: The mechanis= m MUST=20 provide means to relate recording and recording controls such as=20 start/stop/pause/resume to the wall clock time.

 

Henry

 

 

From:=20 siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= =20 Leon Portman
Sent: April-27-11 9:30 AM
To:=20 siprec@ietf.org; Ken Rehor (krehor)(krehor@cisco.com); Elwell,=20 John
Subject: [siprec] Summary of the changes of=20 draft-ietf-siprec-req-10 - last call

 

Hello

 

Please see below summary of the c= hanges=20 for  updated version of the requirements document.=

 

Main changes:

 

1.      = ;=20 Updated REQ-022, 023, 0= 24 (all=20 other numbers are ++, original 22 and 23 removed), thanks to Muthu and Jo= hn=20 for the text

a.      = ;=20 REQ-022: The mechanism = MUST=20 provide means for facilitating synchronization of the recorded media stre= ams=20 and metadata.

b.     =20 REQ-023: The mechanism = MUST=20 provide means for facilitating synchronization among the recorded media=20 streams.

c.      = ;=20 REQ-024: The mechanism = MUST=20 provide means for relating recordings to wall clock=20 time.

2.= Use Case 8=20 – nit pick, thanks to Muthu (me -> may be)

a."In cases where calls inside or between branches must be=20 recorded, a centralized recording system in data centers together with=20 telephony infrastructure (e.g. PBX) may be deployed."

          =      =20 3. Proposed additional paragraph in the security section from the securit= y=20 review (not in the text yet, pending WG approval):

"Integrity and correctness of = the=20 recorded sessions is not ensured by cryptographic means to ensure that th= e CS=20 has not been tampered with. This would have to be done by organizational = and=20 technical controls that prevent tampering with CS participants and=20 SRC."

 

Regards

 

Leon

 

 

 

 


CONFIDENTIALITY=20 NOTICE: This e-mail and any files attached may contain confidential and=20 proprietary information of Alcatel-Lucent and/or its affiliated entities.= =20 Access by the intended recipient only is authorized. Any liability arisin= g=20 from any party acting, or refraining from acting, on any information cont= ained=20 in this e-mail is hereby excluded. If you are not the intended recipient,= =20 please notify the sender immediately, destroy the original transmission a= nd=20 its attachments and do not disclose the contents to any other person, use= it=20 for any purpose, or store or copy the information in any medium. Copyrigh= t in=20 this e-mail and any attachments belongs to Alcatel-Lucent and/or its=20 affiliated entities.
--_000_A444A0F8084434499206E78C106220CA0875F84616MCHP058Agloba_-- From Leon.Portman@nice.com Wed Apr 27 23:58: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 5F5DFE06B6 for ; Wed, 27 Apr 2011 23:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 rq6chuRBzdB0 for ; Wed, 27 Apr 2011 23:58:39 -0700 (PDT) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id 69F53E06B4 for ; Wed, 27 Apr 2011 23:58:38 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Thu, 28 Apr 2011 09:58:36 +0300 From: Leon Portman To: "Elwell, John" , Henry Lum , "siprec@ietf.org" , "krehor@cisco.com" Date: Thu, 28 Apr 2011 09:58:37 +0300 Thread-Topic: [siprec] Summary of the changes of draft-ietf-siprec-req-10 - last call Thread-Index: AcwE3y4TqEYV7EYpTvCzQYc4dfJgQwAMJfNgABdFL4AAATQWQA== Message-ID: <07465C1D981ABC41A344374066AE1A2C38AB7A1DBA@TLVMBX01.nice.com> References: <059AF07365DC474393A19A3AF187DF7406F8FB7B@NAHALD.us.int.genesyslab.com> In-Reply-To: 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_07465C1D981ABC41A344374066AE1A2C38AB7A1DBATLVMBX01nicec_" MIME-Version: 1.0 Subject: Re: [siprec] Summary of the changes of draft-ietf-siprec-req-10 - last call X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 28 Apr 2011 06:58:41 -0000 --_000_07465C1D981ABC41A344374066AE1A2C38AB7A1DBATLVMBX01nicec_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 Leon From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] Sent: Thursday, April 28, 2011 9:24 AM To: Henry Lum; Leon Portman; siprec@ietf.org; krehor@cisco.com Subject: RE: [siprec] Summary of the changes of draft-ietf-siprec-req-10 - = last call OK for me. John ________________________________ From: Henry Lum [mailto:Henry.Lum@alcatel-lucent.com] Sent: 27 April 2011 21:16 To: Leon Portman; siprec@ietf.org; krehor@cisco.com; Elwell, John Subject: RE: [siprec] Summary of the changes of draft-ietf-siprec-req-10 - = last call I am trying to see if we can more explicit about relating wall clock time w= ith recording controls such as pause/resume: REQ-024: The mechanism MUST provide means to relate recording and recording= controls such as start/stop/pause/resume to the wall clock time. Henry From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Leon Portman Sent: April-27-11 9:30 AM To: siprec@ietf.org; Ken Rehor (krehor)(krehor@cisco.com); Elwell, John Subject: [siprec] Summary of the changes of draft-ietf-siprec-req-10 - last= call Hello Please see below summary of the changes for updated version of the require= ments document. Main changes: 1. Updated REQ-022, 023, 024 (all other numbers are ++, original 22 a= nd 23 removed), thanks to Muthu and John for the text a. REQ-022: The mechanism MUST provide means for facilitating synchro= nization of the recorded media streams and metadata. b. REQ-023: The mechanism MUST provide means for facilitating synchron= ization among the recorded media streams. c. REQ-024: The mechanism MUST provide means for relating recordings = to wall clock time. 2. Use Case 8 - nit pick, thanks to Muthu (me -> may be) a."In cases where calls inside or between branches must be recorded, a cent= ralized recording system in data centers together with telephony infrastruc= ture (e.g. PBX) may be deployed." 3. Proposed additional paragraph in the security section fr= om the security review (not in the text yet, pending WG approval): "Integrity and correctness of the recorded sessions is not ensured by crypt= ographic means to ensure that the CS has not been tampered with. This would= have to be done by organizational and technical controls that prevent tamp= ering with CS participants and SRC." Regards Leon CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain conf= idential and proprietary information of Alcatel-Lucent and/or its affiliate= d entities. Access by the intended recipient only is authorized. Any liabil= ity arising from any party acting, or refraining from acting, on any inform= ation contained in this e-mail is hereby excluded. If you are not the inten= ded recipient, please notify the sender immediately, destroy the original t= ransmission and its attachments and do not disclose the contents to any oth= er 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-Luc= ent and/or its affiliated entities. --_000_07465C1D981ABC41A344374066AE1A2C38AB7A1DBATLVMBX01nicec_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1

 

Leon

 

From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]
<= b>Sent: Thursday, April 28, 2011 9:24 AM
To: Henry Lum; Leon = Portman; siprec@ietf.org; krehor@cisco.com
Subject: RE: [siprec] = Summary of the changes of draft-ietf-siprec-req-10 - last call

 

OK for me.

 

John<= /span>

 

=

From: Henry Lum [mailto:Henry.Lum@alcatel-lu= cent.com]
Sent: 27 April 2011 21:16
To: Leon Portman; = siprec@ietf.org; krehor@cisco.com; Elwell, John
Subject: RE: [sip= rec] Summary of the changes of draft-ietf-siprec-req-10 - last call<= span style=3D'font-size:12.0pt;font-family:"Times New Roman","serif"'>=

I am trying to see if we can more explicit about relating wall clock = time with recording controls such as pause/resume:

 

REQ-024: The mechanism MUST provide means to relate recording and record= ing controls such as start/stop/pause/resume to the wall clock time.

 

Henry

 

 

From: siprec-bounces@iet= f.org [mailto:siprec-bounces@ietf.org] On Behalf Of Leon Portman
= Sent: April-27-11 9:30 AM
To: siprec@ietf.org; Ken Rehor (= krehor)(krehor@cisco.com); Elwell, John
Subject: [siprec] Summary= of the changes of draft-ietf-siprec-req-10 - last call

 

Hello

&= nbsp;

Please see below summary of the changes= for  updated version of the requirements document.

 

Main changes:

 

1.   &nbs= p;   Updated REQ-022, 023, 024 (all other numbers are ++, = original 22 and 23 removed), thanks to Muthu and John for the text

a.       REQ-022: The mechanism MUST pr= ovide means for facilitating synchronization of the recorded media streams = and metadata.

b.      REQ-023: The m= echanism MUST provide means for facilitating synchronization among the reco= rded media streams.

c.       RE= Q-024: The mechanism MUST provide means for relating recordings to wall clo= ck time.

2. Use Case 8 – nit pick, thanks to Muthu (me -> may be)

a."In cases where calls inside or between branches must be recorded= , a centralized recording system in data centers together with telephony in= frastructure (e.g. PBX) may be deployed."

           = ;     3. Proposed additional paragraph in the security = section from the security review (not in the text yet, pending WG approval)= :

"Integrity and correctness of = the recorded sessions is not ensured by cryptographic means to ensure that = the CS has not been tampered with. This would have to be done by organizati= onal and technical controls that prevent tampering with CS participants and= SRC."

 

Regards

&nbs= p;

Leon

 

 

 

 =

 


CONFIDENTIALITY NOTICE: Th= is e-mail and any files attached may contain confidential and proprietary i= nformation 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 noti= fy the sender immediately, destroy the original transmission and its attach= ments 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.

= --_000_07465C1D981ABC41A344374066AE1A2C38AB7A1DBATLVMBX01nicec_-- From partr@cisco.com Thu Apr 28 00:06: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 3DC6CE064B for ; Thu, 28 Apr 2011 00:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.893 X-Spam-Level: X-Spam-Status: No, score=-9.893 tagged_above=-999 required=5 tests=[AWL=0.705, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 Gy3Dq60K38x7 for ; Thu, 28 Apr 2011 00:06:51 -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 0E863E06C0 for ; Thu, 28 Apr 2011 00:06:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=17527; q=dns/txt; s=iport; t=1303974410; x=1305184010; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=QIKBhcxnPYBsG4vIq7pVJTdu0LfikE+iO8yRp3aGncQ=; b=DqdOLi6nSLBIbQ5jLFm6juaiQgSkUPrl3YBCNQE/MW3Ss0tWhYyzwfgA VZeYfDr8vRLKddyudNyAQJyZy9yEUi2rdUeY8w9Pjqaed2LW7tlFlV+jS yvn7Lkdtb9OOa/Zt6fwr9prOMOqMl5rNOr7tMV19QB5718fwaSUd0j0WR w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvgAAMgRuU2Q/khLgWdsb2JhbACCYpUwjW0UAQEWJiWldZ0ChXYEhgWMcIob X-IronPort-AV: E=Sophos;i="4.64,278,1301875200"; d="scan'208,217";a="27645586" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 28 Apr 2011 07:06:48 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3S76jDV028751; Thu, 28 Apr 2011 07:06:48 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Apr 2011 12:36:21 +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_01CC0572.C75D990F" Date: Thu, 28 Apr 2011 12:36:21 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Summary of the changes of draft-ietf-siprec-req-10 - last call Thread-Index: AcwE3y4TqEYV7EYpTvCzQYc4dfJgQwAMJfNgABdFL4AAAGbTAA== References: <059AF07365DC474393A19A3AF187DF7406F8FB7B@NAHALD.us.int.genesyslab.com> From: "Parthasarathi R (partr)" To: "Elwell, John" , "Henry Lum" , "Leon Portman" , , "Ken Rehor (krehor)" X-OriginalArrivalTime: 28 Apr 2011 07:06:21.0869 (UTC) FILETIME=[C784EDD0:01CC0572] Subject: Re: [siprec] Summary of the changes of draft-ietf-siprec-req-10 - last call X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 28 Apr 2011 07:06:53 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC0572.C75D990F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm also fine with Henry proposed requirement.=20 =20 I'm curious to know from SIPREC solution point of view whether REQ-024 requirement calls for Network Time protocol (NTP) or similar protocol mechanism between SRC and SRS. =20 Thanks Partha ________________________________ From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John Sent: Thursday, April 28, 2011 11:54 AM To: Henry Lum; Leon Portman; siprec@ietf.org; Ken Rehor (krehor) Subject: Re: [siprec] Summary of the changes of draft-ietf-siprec-req-10 - last call OK for me. =20 John ________________________________ From: Henry Lum [mailto:Henry.Lum@alcatel-lucent.com]=20 Sent: 27 April 2011 21:16 To: Leon Portman; siprec@ietf.org; krehor@cisco.com; Elwell, John Subject: RE: [siprec] Summary of the changes of draft-ietf-siprec-req-10 - last call =09 =09 I am trying to see if we can more explicit about relating wall clock time with recording controls such as pause/resume: =20 REQ-024: The mechanism MUST provide means to relate recording and recording controls such as start/stop/pause/resume to the wall clock time. =20 Henry =20 =20 From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Leon Portman Sent: April-27-11 9:30 AM To: siprec@ietf.org; Ken Rehor (krehor)(krehor@cisco.com); Elwell, John Subject: [siprec] Summary of the changes of draft-ietf-siprec-req-10 - last call =20 Hello =20 Please see below summary of the changes for updated version of the requirements document. =20 Main changes: =20 1. Updated REQ-022, 023, 024 (all other numbers are ++, original 22 and 23 removed), thanks to Muthu and John for the text a. REQ-022: The mechanism MUST provide means for facilitating synchronization of the recorded media streams and metadata. b. REQ-023: The mechanism MUST provide means for facilitating synchronization among the recorded media streams. c. REQ-024: The mechanism MUST provide means for relating recordings to wall clock time. 2. Use Case 8 - nit pick, thanks to Muthu (me -> may be) a."In cases where calls inside or between branches must be recorded, a centralized recording system in data centers together with telephony infrastructure (e.g. PBX) may be deployed." 3. Proposed additional paragraph in the security section from the security review (not in the text yet, pending WG approval): "Integrity and correctness of the recorded sessions is not ensured by cryptographic means to ensure that the CS has not been tampered with. This would have to be done by organizational and technical controls that prevent tampering with CS participants and SRC." =20 Regards =20 Leon =20 =20 =20 =20 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.=20 ------_=_NextPart_001_01CC0572.C75D990F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I'm also fine with Henry proposed = requirement.=20
 
I'm curious to know from SIPREC solution = point of view=20 whether REQ-024 requirement calls for Network Time protocol (NTP) or=20 similar protocol mechanism between SRC and = SRS.
 
Thanks
Partha

From: siprec-bounces@ietf.org=20 [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell,=20 John
Sent: Thursday, April 28, 2011 11:54 AM
To: = Henry Lum;=20 Leon Portman; siprec@ietf.org; Ken Rehor (krehor)
Subject: Re: = [siprec] Summary of the changes of draft-ietf-siprec-req-10 - last=20 call

OK for=20 me.
 
John

From: Henry Lum=20 [mailto:Henry.Lum@alcatel-lucent.com]
Sent: 27 April 2011=20 21:16
To: Leon Portman; siprec@ietf.org; krehor@cisco.com; = Elwell,=20 John
Subject: RE: [siprec] Summary of the changes of=20 draft-ietf-siprec-req-10 - last call

I am trying to see = if we can=20 more explicit about relating wall clock time with recording controls = such as=20 pause/resume:

 

REQ-024: The = mechanism MUST=20 provide means to relate recording and recording controls such as=20 start/stop/pause/resume to the wall clock time.

 

Henry

 

 

From:=20 siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf = Of=20 Leon Portman
Sent: April-27-11 9:30 AM
To:=20 siprec@ietf.org; Ken Rehor (krehor)(krehor@cisco.com); Elwell,=20 John
Subject: [siprec] Summary of the changes of=20 draft-ietf-siprec-req-10 - last call

 

Hello

 

Please see below summary of = the changes=20 for  updated version of the requirements = document.

 

Main = changes:

 

1.      =20 Updated REQ-022, = 023, 024 (all=20 other numbers are ++, original 22 and 23 removed), thanks to Muthu and = John=20 for the text

a.      =20 REQ-022: The = mechanism MUST=20 provide means for facilitating synchronization of the recorded media = streams=20 and metadata.

b.     =20 REQ-023: The = mechanism MUST=20 provide means for facilitating synchronization among the recorded = media=20 streams.

c.      =20 REQ-024: The = mechanism MUST=20 provide means for relating recordings to wall clock=20 time.

2. Use Case 8=20 – nit pick, thanks to Muthu (me -> may = be)

a."In cases where calls inside or between branches must = be=20 recorded, a centralized recording system in data centers together with = telephony infrastructure (e.g. PBX) may be = deployed."

          =      =20 3. Proposed additional paragraph in the security section from the = security=20 review (not in the text yet, pending WG = approval):

"Integrity and correctness = of the=20 recorded sessions is not ensured by cryptographic means to ensure that = the CS=20 has not been tampered with. This would have to be done by = organizational and=20 technical controls that prevent tampering with CS participants and=20 SRC."

 

Regards

 

Leon

 

 

 

 


CONFIDENTIALITY=20 NOTICE: This e-mail and any files attached may contain confidential = and=20 proprietary information of Alcatel-Lucent and/or its affiliated = entities.=20 Access by the intended recipient only is authorized. Any liability = arising=20 from any party acting, or refraining from acting, on any information = contained=20 in this e-mail is hereby excluded. If you are not the intended = recipient,=20 please notify the sender immediately, destroy the original = transmission and=20 its attachments and do not disclose the contents to any other person, = use it=20 for any purpose, or store or copy the information in any medium. = Copyright in=20 this e-mail and any attachments belongs to Alcatel-Lucent and/or its=20 affiliated entities. ------_=_NextPart_001_01CC0572.C75D990F-- From Leon.Portman@nice.com Thu Apr 28 00:43:09 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 0EF24E062A for ; Thu, 28 Apr 2011 00:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 nMTe8m3Rvvkw for ; Thu, 28 Apr 2011 00:43:06 -0700 (PDT) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id 9D9FBE064A for ; Thu, 28 Apr 2011 00:43:05 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Thu, 28 Apr 2011 10:43:04 +0300 From: Leon Portman To: "Parthasarathi R (partr)" , "Elwell, John" , Henry Lum , "siprec@ietf.org" , "Ken Rehor (krehor)" Date: Thu, 28 Apr 2011 10:43:04 +0300 Thread-Topic: [siprec] Summary of the changes of draft-ietf-siprec-req-10 - last call Thread-Index: AcwE3y4TqEYV7EYpTvCzQYc4dfJgQwAMJfNgABdFL4AAAGbTAAACEy3g Message-ID: <07465C1D981ABC41A344374066AE1A2C38AB7A1E4A@TLVMBX01.nice.com> References: <059AF07365DC474393A19A3AF187DF7406F8FB7B@NAHALD.us.int.genesyslab.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: multipart/alternative; boundary="_000_07465C1D981ABC41A344374066AE1A2C38AB7A1E4ATLVMBX01nicec_" MIME-Version: 1.0 Subject: Re: [siprec] Summary of the changes of draft-ietf-siprec-req-10 - last call X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 28 Apr 2011 07:43:09 -0000 --_000_07465C1D981ABC41A344374066AE1A2C38AB7A1E4ATLVMBX01nicec_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable My opinion that we should not require or relay on NTP. It will also not hel= p us will network latency or in delays with sending and processing metadata= and rtp packets. This is why we should explicitly send wall clock between = SRC and SRS. And SRC should be "the master" clock. SRS time is not importan= t. Regards Leon From: Parthasarathi R (partr) [mailto:partr@cisco.com] Sent: Thursday, April 28, 2011 10:06 AM To: Elwell, John; Henry Lum; Leon Portman; siprec@ietf.org; Ken Rehor (kreh= or) Subject: RE: [siprec] Summary of the changes of draft-ietf-siprec-req-10 - = last call I'm also fine with Henry proposed requirement. I'm curious to know from SIPREC solution point of view whether REQ-024 requ= irement calls for Network Time protocol (NTP) or similar protocol mechanism= between SRC and SRS. Thanks Partha ________________________________ From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Elwell, John Sent: Thursday, April 28, 2011 11:54 AM To: Henry Lum; Leon Portman; siprec@ietf.org; Ken Rehor (krehor) Subject: Re: [siprec] Summary of the changes of draft-ietf-siprec-req-10 - = last call OK for me. John ________________________________ From: Henry Lum [mailto:Henry.Lum@alcatel-lucent.com] Sent: 27 April 2011 21:16 To: Leon Portman; siprec@ietf.org; krehor@cisco.com; Elwell, John Subject: RE: [siprec] Summary of the changes of draft-ietf-siprec-req-10 - = last call I am trying to see if we can more explicit about relating wall clock time w= ith recording controls such as pause/resume: REQ-024: The mechanism MUST provide means to relate recording and recording= controls such as start/stop/pause/resume to the wall clock time. Henry From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Leon Portman Sent: April-27-11 9:30 AM To: siprec@ietf.org; Ken Rehor (krehor)(krehor@cisco.com); Elwell, John Subject: [siprec] Summary of the changes of draft-ietf-siprec-req-10 - last= call Hello Please see below summary of the changes for updated version of the require= ments document. Main changes: 1. Updated REQ-022, 023, 024 (all other numbers are ++, original 22 a= nd 23 removed), thanks to Muthu and John for the text a. REQ-022: The mechanism MUST provide means for facilitating synchro= nization of the recorded media streams and metadata. b. REQ-023: The mechanism MUST provide means for facilitating synchron= ization among the recorded media streams. c. REQ-024: The mechanism MUST provide means for relating recordings = to wall clock time. 2. Use Case 8 - nit pick, thanks to Muthu (me -> may be) a."In cases where calls inside or between branches must be recorded, a cent= ralized recording system in data centers together with telephony infrastruc= ture (e.g. PBX) may be deployed." 3. Proposed additional paragraph in the security section fr= om the security review (not in the text yet, pending WG approval): "Integrity and correctness of the recorded sessions is not ensured by crypt= ographic means to ensure that the CS has not been tampered with. This would= have to be done by organizational and technical controls that prevent tamp= ering with CS participants and SRC." Regards Leon CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain conf= idential and proprietary information of Alcatel-Lucent and/or its affiliate= d entities. Access by the intended recipient only is authorized. Any liabil= ity arising from any party acting, or refraining from acting, on any inform= ation contained in this e-mail is hereby excluded. If you are not the inten= ded recipient, please notify the sender immediately, destroy the original t= ransmission and its attachments and do not disclose the contents to any oth= er 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-Luc= ent and/or its affiliated entities. --_000_07465C1D981ABC41A344374066AE1A2C38AB7A1E4ATLVMBX01nicec_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

My opinion that we should not require or relay on NTP. It wil= l also not help us will network latency or in delays with sending and proce= ssing metadata and rtp packets. This is why we should explicitly send wall = clock between SRC and SRS. And SRC should be "the master" clock. = SRS time is not important.

 

<= span style=3D'color:#1F497D'>Regards

 

Leon

 

From: Parthasarathi R (partr) [mailto:partr@cisco= .com]
Sent: Thursday, April 28, 2011 10:06 AM
To: Elwe= ll, John; Henry Lum; Leon Portman; siprec@ietf.org; Ken Rehor (krehor)
<= b>Subject: RE: [siprec] Summary of the changes of draft-ietf-siprec-req= -10 - last call

=  

I'm also fine with = ;Henry proposed requirement.

 

I'm curious to know from SIPREC solution point of view whet= her REQ-024 requirement calls for Network Time protocol (NTP) or similar&nb= sp;protocol mechanism between SRC and SRS.<= /span>

 

Thanks

Partha<= /p>

 

From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Be= half Of Elwell, John
Sent: Thursday, April 28, 2011 11:54 AM<= br>To: Henry Lum; Leon Portman; siprec@ietf.org; Ken Rehor (krehor)<= br>Subject: Re: [siprec] Summary of the changes of draft-ietf-siprec= -req-10 - last call

OK for me.

 

John

 

From: Henry Lum [mailto:Henry.Lum@alcatel-lucent.com]
Sent= : 27 April 2011 21:16
To: Leon Portman; siprec@ietf.org; kreh= or@cisco.com; Elwell, John
Subject: RE: [siprec] Summary of the c= hanges of draft-ietf-siprec-req-10 - last call

I am trying to = see if we can more explicit about relating wall clock time with recording c= ontrols such as pause/resume:

 

REQ-024: The mecha= nism MUST provide means to relate recording and recording controls such as = start/stop/pause/resume to the wall clock time.

 =

= Henry

 

 

From: siprec-bounces@ietf.org [mailto:siprec-boun= ces@ietf.org] On Behalf Of Leon Portman
Sent: April-27-11 = 9:30 AM
To: siprec@ietf.org; Ken Rehor (krehor)(krehor@cisco.com)= ; Elwell, John
Subject: [siprec] Summary of the changes of draft-= ietf-siprec-req-10 - last call

 

Hello

 

Please see below summary of the changes for  updated vers= ion of the requirements document.

&= nbsp;

Main changes:

 

1.       U= pdated REQ-022, 023, 024 (all other numbers are ++, original 22 and 23 remo= ved), thanks to Muthu and John for the text

a.   &nbs= p;   REQ-022: The mechanism MUST provide means for facilit= ating synchronization of the recorded media streams and metadata.

b.=       REQ-023: The mechanism MUST provide m= eans for facilitating synchronization among the recorded media streams.

c.       REQ-024: The mechanism MU= ST provide means for relating recordings to wall clock time.

=

2. Use Case 8 – = nit pick, thanks to Muthu (me -> may be)

a."In cases whe= re calls inside or between branches must be recorded, a centralized recordi= ng system in data centers together with telephony infrastructure (e.g. PBX)= may be deployed."

  &= nbsp;           &nbs= p; 3. Proposed additional paragraph in the security section from the securi= ty review (not in the text yet, pending WG approval):

"Integrity and correctness of the recorded sessions i= s not ensured by cryptographic means to ensure that the CS has not been tam= pered with. This would have to be done by organizational and technical cont= rols that prevent tampering with CS participants and SRC."<= /p>

 

Reg= ards

 

Leon

 

 

 

=

 

=

 


CONFIDENTIALITY NOTICE: This e-mail and any files= attached may contain confidential and proprietary information of Alcatel-L= ucent 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 immediate= ly, destroy the original transmission and its attachments and do not disclo= se the contents to any other person, use it for any purpose, or store or co= py the information in any medium. Copyright in this e-mail and any attachme= nts belongs to Alcatel-Lucent and/or its affiliated entities.

= --_000_07465C1D981ABC41A344374066AE1A2C38AB7A1E4ATLVMBX01nicec_-- From rmohanr@cisco.com Thu Apr 28 01: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 84C18E0686 for ; Thu, 28 Apr 2011 01:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 hYQ8KK5nTJQi for ; Thu, 28 Apr 2011 01:48: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 797F6E062A for ; Thu, 28 Apr 2011 01:48:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=18299; q=dns/txt; s=iport; t=1303980512; x=1305190112; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=yZ4VcCY9DzuaZKVOB7oE0R9xvwy6i8LorjrxZP2RTvk=; b=I5qf4y41ABBLAd2UE1cRhI6XBIzJX2Q02xUWbry5cmeLLNxKZBX29skk xlDtjfQcerS2akhP4vWHaS7mr1WasLAIeHwHoytAV+8PyXx11SNmIVcQY qfNqkb/ivQYmoRkKo+ohOgX1Njzr2CNPSbc6l2H44cwHsbIgVRnr0PPrV g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8BAKApuU2Q/khLgWdsb2JhbACCYpUujW0UAQEWJiWlRJ0EhXYEhgeMcYl1 X-IronPort-AV: E=Sophos;i="4.64,279,1301875200"; d="scan'208,217";a="85700965" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 28 Apr 2011 08:48:31 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3S8mOLI001409; Thu, 28 Apr 2011 08:48:30 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, 28 Apr 2011 14:18:10 +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_01CC0581.0040BE44" Date: Thu, 28 Apr 2011 14:18:07 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD062428D7@XMB-BGL-417.cisco.com> In-Reply-To: <059AF07365DC474393A19A3AF187DF7406F8FB7B@NAHALD.us.int.genesyslab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Summary of the changes of draft-ietf-siprec-req-10 -last call Thread-Index: AcwE3y4TqEYV7EYpTvCzQYc4dfJgQwAMJfNgABxMLMA= References: <059AF07365DC474393A19A3AF187DF7406F8FB7B@NAHALD.us.int.genesyslab.com> From: "Ram Mohan R (rmohanr)" To: "Henry Lum" , "Leon Portman" , , "Ken Rehor (krehor)" , "Elwell, John" X-OriginalArrivalTime: 28 Apr 2011 08:48:10.0228 (UTC) FILETIME=[00628B40:01CC0581] Subject: Re: [siprec] Summary of the changes of draft-ietf-siprec-req-10 -last call X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 28 Apr 2011 08:48:35 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC0581.0040BE44 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Looks Ok for me. =20 Regards, Ram =20 From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Henry Lum Sent: Thursday, April 28, 2011 1:46 AM To: Leon Portman; siprec@ietf.org; Ken Rehor (krehor); Elwell, John Subject: Re: [siprec] Summary of the changes of draft-ietf-siprec-req-10 -last call =20 I am trying to see if we can more explicit about relating wall clock time with recording controls such as pause/resume: =20 REQ-024: The mechanism MUST provide means to relate recording and recording controls such as start/stop/pause/resume to the wall clock time. =20 Henry =20 =20 From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Leon Portman Sent: April-27-11 9:30 AM To: siprec@ietf.org; Ken Rehor (krehor)(krehor@cisco.com); Elwell, John Subject: [siprec] Summary of the changes of draft-ietf-siprec-req-10 - last call =20 Hello =20 Please see below summary of the changes for updated version of the requirements document. =20 Main changes: =20 1. Updated REQ-022, 023, 024 (all other numbers are ++, original 22 and 23 removed), thanks to Muthu and John for the text a. REQ-022: The mechanism MUST provide means for facilitating synchronization of the recorded media streams and metadata. b. REQ-023: The mechanism MUST provide means for facilitating synchronization among the recorded media streams. c. REQ-024: The mechanism MUST provide means for relating recordings to wall clock time. 2. Use Case 8 - nit pick, thanks to Muthu (me -> may be) a."In cases where calls inside or between branches must be recorded, a centralized recording system in data centers together with telephony infrastructure (e.g. PBX) may be deployed." 3. Proposed additional paragraph in the security section from the security review (not in the text yet, pending WG approval): "Integrity and correctness of the recorded sessions is not ensured by cryptographic means to ensure that the CS has not been tampered with. This would have to be done by organizational and technical controls that prevent tampering with CS participants and SRC." =20 Regards =20 Leon =20 =20 =20 =20 =20 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. ------_=_NextPart_001_01CC0581.0040BE44 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Looks Ok for me.

 

Regards,

Ram

 

From:= = siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of = Henry Lum
Sent: Thursday, April 28, 2011 1:46 = AM
To: Leon Portman; siprec@ietf.org; Ken Rehor (krehor); = Elwell, John
Subject: Re: [siprec] Summary of the changes of = draft-ietf-siprec-req-10 -last call

 

I am trying to see if we can more = explicit about relating wall clock time with recording controls such as = pause/resume:

 

REQ-024: = The mechanism MUST provide means to relate recording and recording = controls such as start/stop/pause/resume to the wall clock = time.

 

Henry

 

 

From:= = siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of = Leon Portman
Sent: April-27-11 9:30 AM
To: = siprec@ietf.org; Ken Rehor (krehor)(krehor@cisco.com); Elwell, = John
Subject: [siprec] Summary of the changes of = draft-ietf-siprec-req-10 - last call

 

Hello

 

Please see = below summary of the changes for  updated version of the = requirements document.

 

Main = changes:

 

1.       = Updated REQ-022, 023, 024 (all other numbers are = ++, original 22 and 23 removed), thanks to Muthu and John for the = text

a.       = REQ-022: The mechanism MUST provide means for = facilitating synchronization of the recorded media streams and = metadata.

b.      = REQ-023: The mechanism MUST provide means for = facilitating synchronization among the recorded media = streams.

c.       = REQ-024: The mechanism MUST provide means for = relating recordings to wall clock time.

2. Use Case 8 – = nit pick, thanks to Muthu (me -> may be)

a."In cases where calls = inside or between branches must be recorded, a centralized recording = system in data centers together with telephony infrastructure (e.g. PBX) = may be deployed."

        &nbs= p;       3. Proposed additional paragraph = in the security section from the security review (not in the text yet, = pending WG approval):

"Integrity and correctness of the recorded = sessions is not ensured by cryptographic means to ensure that the CS has = not been tampered with. This would have to be done by organizational and = technical controls that prevent tampering with CS participants and = SRC."

 

Regards

 

Leon

 

 

 

 

 


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.

------_=_NextPart_001_01CC0581.0040BE44-- From pkyzivat@cisco.com Thu Apr 28 05:49: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 D0470E0701 for ; Thu, 28 Apr 2011 05:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 SGxVw9EQpzHW for ; Thu, 28 Apr 2011 05:49:46 -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 6F898E06F6 for ; Thu, 28 Apr 2011 05:49:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=5493; q=dns/txt; s=iport; t=1303994985; x=1305204585; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=OjBOlfEw8q9RyWmfbSfWxlfa1DWRlDHzTdml0ZA3CKk=; b=WIiRHv/NrIFCABFHS3EibT5kAFpux7zQSGhVd+nE5Y8DZ2+/cJvv4FSB Q9igGrezlXwJ7yk9gdSwgm4lxy6ibRVCKBqfl+45uAWrh8mc9cZ28J6w8 Xvf+efSu8bU6oEeQwfzqJtlpp6qO8Im6a69o8oL+fRtMFlzedQc4vvwIi k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8BANphuU2Q/khLgWdsb2JhbACYEI1uFAEBFiYliHCdA50EhXYEjlyEFIoR X-IronPort-AV: E=Sophos;i="4.64,280,1301875200"; d="scan'208";a="85752381" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 28 Apr 2011 12:49:44 +0000 Received: from [10.86.245.99] ([10.86.245.99]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3SCnhun014459 for ; Thu, 28 Apr 2011 12:49:43 GMT Message-ID: <4DB96266.5000602@cisco.com> Date: Thu, 28 Apr 2011 08:49:42 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: siprec@ietf.org References: <059AF07365DC474393A19A3AF187DF7406F8FB7B@NAHALD.us.int.genesyslab.com> <07465C1D981ABC41A344374066AE1A2C38AB7A1E4A@TLVMBX01.nice.com> In-Reply-To: <07465C1D981ABC41A344374066AE1A2C38AB7A1E4A@TLVMBX01.nice.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [siprec] Summary of the changes of draft-ietf-siprec-req-10 - last call X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 28 Apr 2011 12:49:46 -0000 On 4/28/2011 3:43 AM, Leon Portman wrote: > My opinion that we should not require or relay on NTP. It will also not > help us will network latency or in delays with sending and processing > metadata and rtp packets. This is why we should explicitly send wall > clock between SRC and SRS. And SRC should be "the master" clock. SRS > time is not important. I'm ok with that. But it doesn't address coordination of the metadata timing with the media timing. It may not need to be normative but *somewhere* I would like to see a description of a plausible algorithm for aligning the media to the SRC wall clock time. (I'm just looking for an existence proof that there is sufficient information to do the job.) Perhaps it is as simple as: - the SRS tags received media packets with the time of reception using its own clock - when the SRS receives metadata, it uses the SRC time from the message to compute a delta between SRS time and SRC time - the SRS then uses that delta to adjust the timestamps for the referenced media (The above is at least incomplete - it raises a number of issues.) Thanks, Paul > Regards > > Leon > > *From:*Parthasarathi R (partr) [mailto:partr@cisco.com] > *Sent:* Thursday, April 28, 2011 10:06 AM > *To:* Elwell, John; Henry Lum; Leon Portman; siprec@ietf.org; Ken Rehor > (krehor) > *Subject:* RE: [siprec] Summary of the changes of > draft-ietf-siprec-req-10 - last call > > I'm also fine with Henry proposed requirement. > > I'm curious to know from SIPREC solution point of view whether REQ-024 > requirement calls for Network Time protocol (NTP) or similar protocol > mechanism between SRC and SRS. > > Thanks > > Partha > > ------------------------------------------------------------------------ > > *From:*siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] *On > Behalf Of *Elwell, John > *Sent:* Thursday, April 28, 2011 11:54 AM > *To:* Henry Lum; Leon Portman; siprec@ietf.org; Ken Rehor (krehor) > *Subject:* Re: [siprec] Summary of the changes of > draft-ietf-siprec-req-10 - last call > > OK for me. > > John > > ------------------------------------------------------------------------ > > *From:*Henry Lum [mailto:Henry.Lum@alcatel-lucent.com] > *Sent:* 27 April 2011 21:16 > *To:* Leon Portman; siprec@ietf.org; krehor@cisco.com; Elwell, John > *Subject:* RE: [siprec] Summary of the changes of > draft-ietf-siprec-req-10 - last call > > I am trying to see if we can more explicit about relating wall clock > time with recording controls such as pause/resume: > > REQ-024: The mechanism MUST provide means to relate recording and > recording controls such as start/stop/pause/resume to the wall clock > time. > > Henry > > *From:*siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] *On > Behalf Of *Leon Portman > *Sent:* April-27-11 9:30 AM > *To:* siprec@ietf.org; Ken Rehor (krehor)(krehor@cisco.com); Elwell, > John > *Subject:* [siprec] Summary of the changes of > draft-ietf-siprec-req-10 - last call > > Hello > > Please see below summary of the changes for updated version of the > requirements document. > > Main changes: > > 1.Updated REQ-022, 023, 024 (all other numbers are ++, original 22 > and 23 removed), thanks to Muthu and John for the text > > a.REQ-022: The mechanism MUST provide means for facilitating > synchronization of the recorded media streams and metadata. > > b.REQ-023: The mechanism MUST provide means for facilitating > synchronization among the recorded media streams. > > c.REQ-024: The mechanism MUST provide means for relating recordings > to wall clock time. > > 2. Use Case 8 – nit pick, thanks to Muthu (me -> may be) > > a."In cases where calls inside or between branches must be recorded, > a centralized recording system in data centers together with > telephony infrastructure (e.g. PBX) may be deployed." > > 3. Proposed additional paragraph in the security section from the > security review (not in the text yet, pending WG approval): > > "Integrity and correctness of the recorded sessions is not ensured > by cryptographic means to ensure that the CS has not been tampered > with. This would have to be done by organizational and technical > controls that prevent tampering with CS participants and SRC." > > Regards > > Leon > > > 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. > > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From Leon.Portman@nice.com Thu Apr 28 05:57: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 AF8CFE0703 for ; Thu, 28 Apr 2011 05:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.144, 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 ToslxFZUDC02 for ; Thu, 28 Apr 2011 05:57:12 -0700 (PDT) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id 58514E06C5 for ; Thu, 28 Apr 2011 05:57:11 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Thu, 28 Apr 2011 15:57:09 +0300 From: Leon Portman To: Paul Kyzivat , "siprec@ietf.org" Date: Thu, 28 Apr 2011 15:57:08 +0300 Thread-Topic: [siprec] Summary of the changes of draft-ietf-siprec-req-10 - last call Thread-Index: AcwFotl94T33dFisQZGQOGHXqCIjUAAAFbYQ Message-ID: <07465C1D981ABC41A344374066AE1A2C38AB7A201D@TLVMBX01.nice.com> References: <059AF07365DC474393A19A3AF187DF7406F8FB7B@NAHALD.us.int.genesyslab.com> <07465C1D981ABC41A344374066AE1A2C38AB7A1E4A@TLVMBX01.nice.com> <4DB96266.5000602@cisco.com> In-Reply-To: <4DB96266.5000602@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] Summary of the changes of draft-ietf-siprec-req-10 - last call X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 28 Apr 2011 12:57:12 -0000 Paul Hi Yes, it can be used like that except that time difference information proba= bly will be used during the playback - to align played media with metadata = events. Leon -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Paul Kyzivat Sent: Thursday, April 28, 2011 3:50 PM To: siprec@ietf.org Subject: Re: [siprec] Summary of the changes of draft-ietf-siprec-req-10 - = last call On 4/28/2011 3:43 AM, Leon Portman wrote: > My opinion that we should not require or relay on NTP. It will also=20 > not help us will network latency or in delays with sending and=20 > processing metadata and rtp packets. This is why we should explicitly=20 > send wall clock between SRC and SRS. And SRC should be "the master"=20 > clock. SRS time is not important. I'm ok with that. But it doesn't address coordination of the metadata timin= g with the media timing. It may not need to be normative but *somewhere* I would like to see a descr= iption of a plausible algorithm for aligning the media to the SRC wall cloc= k time. (I'm just looking for an existence proof that there is sufficient i= nformation to do the job.) Perhaps it is as simple as: - the SRS tags received media packets with the time of reception using its own clock - when the SRS receives metadata, it uses the SRC time from the message to compute a delta between SRS time and SRC time - the SRS then uses that delta to adjust the timestamps for the referenced media (The above is at least incomplete - it raises a number of issues.) Thanks, Paul > Regards > > Leon > > *From:*Parthasarathi R (partr) [mailto:partr@cisco.com] > *Sent:* Thursday, April 28, 2011 10:06 AM > *To:* Elwell, John; Henry Lum; Leon Portman; siprec@ietf.org; Ken=20 > Rehor > (krehor) > *Subject:* RE: [siprec] Summary of the changes of > draft-ietf-siprec-req-10 - last call > > I'm also fine with Henry proposed requirement. > > I'm curious to know from SIPREC solution point of view whether REQ-024=20 > requirement calls for Network Time protocol (NTP) or similar protocol=20 > mechanism between SRC and SRS. > > Thanks > > Partha > > ---------------------------------------------------------------------- > -- > > *From:*siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] *On=20 > Behalf Of *Elwell, John > *Sent:* Thursday, April 28, 2011 11:54 AM > *To:* Henry Lum; Leon Portman; siprec@ietf.org; Ken Rehor (krehor) > *Subject:* Re: [siprec] Summary of the changes of > draft-ietf-siprec-req-10 - last call > > OK for me. > > John > > =20 > ---------------------------------------------------------------------- > -- > > *From:*Henry Lum [mailto:Henry.Lum@alcatel-lucent.com] > *Sent:* 27 April 2011 21:16 > *To:* Leon Portman; siprec@ietf.org; krehor@cisco.com; Elwell, John > *Subject:* RE: [siprec] Summary of the changes of > draft-ietf-siprec-req-10 - last call > > I am trying to see if we can more explicit about relating wall clock > time with recording controls such as pause/resume: > > REQ-024: The mechanism MUST provide means to relate recording and > recording controls such as start/stop/pause/resume to the wall clock > time. > > Henry > > *From:*siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] *On > Behalf Of *Leon Portman > *Sent:* April-27-11 9:30 AM > *To:* siprec@ietf.org; Ken Rehor (krehor)(krehor@cisco.com); Elwell, > John > *Subject:* [siprec] Summary of the changes of > draft-ietf-siprec-req-10 - last call > > Hello > > Please see below summary of the changes for updated version of the > requirements document. > > Main changes: > > 1.Updated REQ-022, 023, 024 (all other numbers are ++, original 22 > and 23 removed), thanks to Muthu and John for the text > > a.REQ-022: The mechanism MUST provide means for facilitating > synchronization of the recorded media streams and metadata. > > b.REQ-023: The mechanism MUST provide means for facilitating > synchronization among the recorded media streams. > > c.REQ-024: The mechanism MUST provide means for relating recordings > to wall clock time. > > 2. Use Case 8 - nit pick, thanks to Muthu (me -> may be) > > a."In cases where calls inside or between branches must be recorded, > a centralized recording system in data centers together with > telephony infrastructure (e.g. PBX) may be deployed." > > 3. Proposed additional paragraph in the security section from the > security review (not in the text yet, pending WG approval): > > "Integrity and correctness of the recorded sessions is not ensured > by cryptographic means to ensure that the CS has not been tampered > with. This would have to be done by organizational and technical > controls that prevent tampering with CS participants and SRC." > > Regards > > Leon > > > 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. > > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From Henry.Lum@alcatel-lucent.com Thu Apr 28 08:19:26 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 AD9EDE069F for ; Thu, 28 Apr 2011 08:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.524 X-Spam-Level: X-Spam-Status: No, score=-5.524 tagged_above=-999 required=5 tests=[AWL=1.075, 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 n-FSXJM9BoaR for ; Thu, 28 Apr 2011 08:19:24 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 9783EE0670 for ; Thu, 28 Apr 2011 08:19:10 -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 p3SFJ7M1001405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 28 Apr 2011 10:19:07 -0500 (CDT) Received: from relay-out1.dc.genesyslab.com (relay-out1.dc.genesyslab.com [172.22.68.187]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p3SFJ5OA014778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 28 Apr 2011 10:19:07 -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 p3SFJ5Sw029552; Thu, 28 Apr 2011 08:19:05 -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, 28 Apr 2011 08:19:04 -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, 28 Apr 2011 08:19:03 -0700 Message-ID: <059AF07365DC474393A19A3AF187DF7406F8FCDC@NAHALD.us.int.genesyslab.com> In-Reply-To: <4DB89EE3.8070504@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Does MS have life outside a particular CS? (was RE: comments on draft-ram-siprec-metadata-04) Thread-Index: AcwFLjq5vLFKKs63TD2GeuqgnNHr5gAiFGCw References: <4DADA8E6.9010006@cisco.com> <35BCE99A477D6A49 8 6 F B 2216 D8CF2CFD06133A56@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD06133DD4@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD06133E6B@XMB-BGL-417.cisco.com> <4DB81F8A.8000306@cisco.com> <059AF07365DC474393A19A3AF187DF7406F8FBA1@NAHALD.us.int.genesyslab.com> <4DB89EE3.8070504@cisco.com> From: "Henry Lum" To: "Paul Kyzivat" X-OriginalArrivalTime: 28 Apr 2011 15:19:04.0921 (UTC) FILETIME=[9C78AC90:01CC05B7] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Cc: siprec@ietf.org Subject: Re: [siprec] Does MS have life outside a particular CS? (was RE: comments on draft-ram-siprec-metadata-04) X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 28 Apr 2011 15:19:26 -0000 I agree it would be out of scope for two different SRCs to refer to the same CS. The metadata model currently does not seem to prevent such scenario, as long as there is a way to identify the same CS across different SRC. The CS Identifier currently states that it is a unique identifier, and I don't think we should mandate that to be globally unique across multiple SRCs like the CSG identifier. Regards, Henry > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Wednesday, April 27, 2011 6:56 PM > To: Henry Lum > Cc: Parthasarathi R (partr); siprec@ietf.org > Subject: Re: [siprec] Does MS have life outside a particular CS? (was > RE: comments on draft-ram-siprec-metadata-04) >=20 >=20 >=20 > On 4/27/2011 5:01 PM, Henry Lum wrote: > >> Presumably the RTP streams associated with the RS end when the RS > > ends. > >> That does not necessarily mean that the media stream of a CS also > ends > > at > >> that time. It could be picked up again in a different RS by the same > > or > >> different SRC. > > > > IIUC, a single CS is only mapped to a single SRC. If we have a media > > stream of a CS picked by another SRC, then it should be a different > CS > > but can be related to the same CS group. >=20 > Two things: >=20 > It could be the same SRC but two different RSs. (Perhaps it drops the > RS > during a long pause, or because the SRS crashed and restarted and the > SRC had to reconnect.) >=20 > If there are two different SRCs, and they happen to know it is the same > CS (I'm not proposing *how* they know), it would be better to refer to > the same CS. >=20 > I'm not saying we should require SRCs to do such things - only that a > design that permits this is better than one that does not. >=20 > Thanks, > Paul >=20 > > Henry > > > >> -----Original Message----- > >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf > >> Of Paul Kyzivat > >> Sent: April-27-11 9:52 AM > >> To: Parthasarathi R (partr) > >> Cc: siprec@ietf.org > >> Subject: Re: [siprec] Does MS have life outside a particular CS? > (was > > RE: > >> comments on draft-ram-siprec-metadata-04) > >> > >> There seems to be some confusion in this discussion about what a MS > > is. > >> > >> On one hand there is an m-line in the SDP of the RS, and a > > corresponding RTP > >> stream. > >> > >> On another hand there is an m-line in a CS and a corresponding RTP > > stream. > >> > >> And then there is an MS described in the metadata conveyed over the > > RS. > >> > >> And for both of the above, a single m-line might correspond to > > different RTP > >> streams over time, due to renegotiating the address and/or port of > the > >> recipient, or by a different sender sending to the same port. > >> > >> There is a mapping between one or more RTP streams in the CS (or > > multiple > >> CSs?) and one or more RTP streams in the RS. The metadata hopefully > >> describes that mapping. > >> > >> But perhaps we don't have full agreement on what sorts of mappings > are > >> possible. Some that I think we allow are: > >> - one CS RTP stream to one RS RTP stream. > >> - multiple concurrent CS RTP streams mixed to one > >> RS RTP stream > >> - multiple CS RTP streams sequentially mapped to the same > >> RS RTP stream > >> ... > >> > >> Presumably the RTP streams associated with the RS end when the RS > > ends. > >> That does not necessarily mean that the media stream of a CS also > ends > > at > >> that time. It could be picked up again in a different RS by the same > > or > >> different SRC. > >> > >> Thanks, > >> Paul > >> > >> On 4/27/2011 2:30 AM, Parthasarathi R (partr) wrote: > >>> John, > >>> > >>> My intention is show the complexity in the metadata model in the > >>> current form. Global unique id solves the issue but let us explore > > for > >>> better optimized solution with more local unique id if any exists. > >>> > >>> I have created another mail thread for adding the recording type > >>> attribute which helps in most of the metadata blocks to have local > >>> unique id rather than global unique id. Let us see how others > >>> visualize that attribute. > >>> > >>> IMO, it may better to have globally unique id with the current > >>> metadata model attributes. We may be able to add the normative > >>> statement that "Media stream (MS) MUST be terminated when CS is > >>> terminated" in the metadata but in reality, MS is within the scope > > of > >>> RS which is forced to delete for no reason. These sort will be > >>> restrictive for few SRC implementation. For eg: RS may created MS > > with > >>> RSVP which may not prefer to terminate the resource during RS > >>> mid-session changes like CS changes even though intermediate time > > with > >>> no media but the above normative statement forces to break those > SRC > >> implementation. > >>> > >>> Please read inline for more comments. > >>> > >>> Thanks > >>> Partha > >>> > >>> -----Original Message----- > >>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > >>> Sent: Friday, April 22, 2011 1:48 AM > >>> To: Parthasarathi R (partr); Ram Mohan R (rmohanr); Paul Kyzivat > >>> (pkyzivat) > >>> Cc: siprec@ietf.org > >>> Subject: RE: Does MS have life outside a particular CS? (was RE: > >>> [siprec] comments on draft-ram-siprec-metadata-04) > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] > >>>> Sent: 21 April 2011 17:20 > >>>> To: Elwell, John; Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > >>>> Cc: siprec@ietf.org > >>>> Subject: RE: Does MS have life outside a particular CS? (was > >>>> RE: [siprec] comments on draft-ram-siprec-metadata-04) > >>>> > >>>> John, > >>>> > >>>> Please read inline. > >>>> > >>>> Thanks > >>>> Partha > >>>> > >>>> -----Original Message----- > >>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > >>>> Sent: Thursday, April 21, 2011 9:12 PM > >>>> To: Parthasarathi R (partr); Ram Mohan R (rmohanr); Paul Kyzivat > >>>> (pkyzivat) > >>>> Cc: siprec@ietf.org > >>>> Subject: RE: Does MS have life outside a particular CS? (was RE: > >>>> [siprec] comments on draft-ram-siprec-metadata-04) > >>>> > >>>> Partha, > >>>> > >>>>> -----Original Message----- > >>>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] > >>>>> Sent: 21 April 2011 14:25 > >>>>> To: Elwell, John; Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > >>>>> Cc: siprec@ietf.org > >>>>> Subject: RE: Does MS have life outside a particular CS? (was > >>>>> RE: [siprec] comments on draft-ram-siprec-metadata-04) > >>>>> > >>>>> John, > >>>>> > >>>>> I could think of one usecase wherein MS is outside CS but within > >>>>> single RS. The usecase is multiple CS within single RS and MS. > > The > >>>>> usecase is as follows: > >>>>> > >>>>> B2BUA acts as SRC. A, B, C are participants within single B2BUA. > A > >>>>> creates single RS for a CSG. > >>>>> > >>>>> 1) A calls B through B2BUA. B2BUA creates RS towards SRS with > > CSG1, > >>>>> CS1, > >>>>> MS1 (A's media stream), MS2 (B's media stream), Participant1 as > A& > >>>>> Participant2 as B. > >>>> [JRE] Why two media streams? Why not a single MS, with both A and > B > >>>> sending and receiving that MS? > >>>> The media streams are un-mixed, MS1 points to RTP from > A > >>>> through label attribute in MS1 SDP, MS2 points to RTP from B > > through > >>>> label attribute in MS2 SDP > >>> [JRE] Reading the metadata model again, I think it does seem to > > imply > >>> two Media Stream objects if the two directions for a 2-party call > > are > >>> sent unmixed (as two m-lines in the RS SDP), so I will concede that > > we > >>> have two Media Stream objects here. I had been thinking of a > > slightly > >>> different model, where there is one Media Stream, but associations > >>> between the Media Stream and Participants pointed to different > > m-lines > >>> in the RS SDP. > >>> > >>>> > >>>>> 2) B connects with C through B2BUA > >>>>> 3) B transfer the call of A& B to C using REFER, B2BUA > >>>> converts REFER > >>>> > >>>>> to RE-INVITE towards A& C and A& C are connected. B2BUA > >>>> updates RS > >>>>> with CS2, Participant1 as A& participant2 as C, MS1(A's media > >>>>> stream), MS2(C's media stream). > >>>> [JRE] I would have expected, from my understanding of the metadata > >>>> model, that the CS2 would have a new MS, with both A and B sending > >>>> and > >>> > >>>> receiving that new MS. > >>>> > >>>> It is not mandatory because participant information > will > > be > >>>> updated and pointing to the same m-line in RS with same label > >>>> attribute. > >>>> From SRS perspective, the same media stream with the update in > the > >>>> participant name only. Say MS2 is stored as one record with B as > >>>> participant for T0 to T1 timelines and C as participant from T1 to > > T2. > >>>> > >>> [JRE] Or alternatively it could be modelled that when a new CS > > starts > >>> there is a new Media Stream object, still pointing to the same > > m-line > >>> in the RS SDP. > >>> > >>> The purpose of unique-id will go for toss here. The same > >>> media stream (MS) has unique id "id1" initially and later it will > > have "id2" > >>> which will not be good for replay. Of course, MS life is always > > within > >>> RS in this scenario but not within CS. So, Unique Id within RS will > >>> serve the purpose > >>> > >>> This would avoid the need for a Media Stream object to survive > >>> beyond the lifetime of a CS, and therefore allow local > > identification. > >>> While there is no CS in progress, the m-line would be disabled > (port > >>> 0) and would not be referenced by any Media Stream. > >>> > >>> RS m-line is not required to 0 because it shall change > > into > >>> "a=3Dinactive" as well. There is no change in the resource > reservation > >>> in both SRC and SRS > >>> > >>>> > >>>>> There is no update on RS1, CSG1, MS1, MS2. MS2 will become MS2 > > with > >>>>> the new association and in terms of format, it will associate > with > >>>>> tag. > >>>>> > >>>>> In the above scenario, MS have life outside CS but it is within > > RS. > >>>> [JRE] I can see how it COULD work like that, but it is not > > intuitive. > >>>> > >>>> In SIPREC solution, UPDATE message with CS2(session > >>>> element) , > >>>> participant "C" element are received in SRS. This partial update > of > >>>> UPDATE helps to make this scenario work. There is no change in > term > >>>> stream element or RS SDP > >>>> > >>>> To me, a new CS means the existing media stream stops and a new > > media > >>>> stream is created. > >>>> > >>>> I'm interested knowing whether you propose that MS MUST > >>>> stop in case CS ends and the above scenario is outside the scope > of > >> SIPREC? > >>>> > >>>> > >>>>> The > >>>>> unique id shall be within RS scope as mentioned in IETF-80 > > meeting. > >>>>> But in another situation, MS is outside the scope of RS but > >>>> within CS > >>>>> and the usecase is Multiple RS for single CS, details are > >>>> as follows: > >>>>> > >>>>> A, B are pariticipants. A acts as SRC which tear down RS > >>>> whenever hold > >>>> > >>>>> happens& creates new RS when resume happens. > >>>>> > >>>>> 1) A calls B. A creates RS1 towards SRS with CS1, MS1 (A's media > >>>>> stream), MS2 (B's Media stream),Participant1 as A& > >>>> Participant2 as B. > >>>> [JRE] Again, I would model this as a single MS, to which both A > and > > B > >>>> contribute. > >>>> Again, unmixed stream from A and B > >>>>> 2) A put B on hold. A tear down RS1. > >>>>> 3) A resume B. A creates RS2 towards SRS with CS1, MS1 (A's media > >>>>> stream), MS2 (B's Media stream),Participant1 as A& > >>>> Participant2 as B > >>>>> > >>>>> Here MS1& MS2 needs to be same across RS to group media streams > >>>>> correctly. Please let me know your opinion here. > >>>> > >>>> [JRE] Although I disagree that we have two Media Streams here, I > do > >>>> agree that the single Media Stream could be considered to survive > > the > >>>> hold/resume, and hence survive from RS1 to RS2. But the MS is > > within > >>>> the context of the same CS (CS1), and therefore this is outside > the > >>>> scope of this particular thread, which is asking whether an MS can > >>>> have a life outside a particular CS. In this case the MS continues > > to > >>>> be associated with the CS, so I don't have a problem with that. > >>>> > >>>> I have 2nd example to illustrate MS have life outside > RS. > >>>> > >>>> > >>>> So you have failed to convince me that an MS needs to have a life > >>>> outside a CS. > >>>> > >>>> In case the above scenario-1 way of recording is > outside > >>>> the scope of SIPREC, I agree with you that MS does not have life > >>>> outside a > >>> > >>>> particular CS > >>> [JRE] I assume you are talking about the call transfer case. I am > > not > >>> saying that use case is outside the scope of SIPREC. I am just > > saying > >>> that it can be modelled a different way, which may be advantageous > > in > >>> terms of the number of globally unique identifiers needed. > >>> > >>> > >>> John (as individual) > >>> > >>> > >>> > >>>> > >>>> John (as individual) > >>>> > >>>> > >>>>> > >>>>> Having said that MS have life outside a particular CS, I create > >>>>> separate thread within unique how it shall be handled. > >>>>> > >>>>> Thanks > >>>>> Partha > >>>>> > >>>>> -----Original Message----- > >>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > >>>>> Sent: Thursday, April 21, 2011 12:01 PM > >>>>> To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > >>>>> Cc: Parthasarathi R (partr); siprec@ietf.org > >>>>> Subject: Does MS have life outside a particular CS? (was > >>>> RE: [siprec] > >>>>> comments on draft-ram-siprec-metadata-04) > >>>>> > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > >>>>>> Sent: 20 April 2011 18:08 > >>>>>> To: Elwell, John; Paul Kyzivat (pkyzivat) > >>>>>> Cc: Parthasarathi R (partr); siprec@ietf.org > >>>>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > >>>>>> > >>>>>> Hi John, > >>>>>> > >>>>>> Please see inline [RAM] > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > >>>>>>> Sent: Wednesday, April 20, 2011 8:19 PM > >>>>>>> To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > >>>>>>> Cc: Parthasarathi R (partr); siprec@ietf.org > >>>>>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > >>>>>>>> Sent: 20 April 2011 14:52 > >>>>>>>> To: Elwell, John; Paul Kyzivat (pkyzivat) > >>>>>>>> Cc: Parthasarathi R (partr); siprec@ietf.org > >>>>>>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 > >>>>>>>> > >>>>>>>> John, > >>>>>>>> > >>>>>>>> I agree with you that normal cases RS will remain at > >>>>> least for the > >>>>> > >>>>>>>> duration of CS. However it is common to have use cases where > >>>>>>> recording > >>>>>>>> is done for first few mins of a CS and then stopped, > >>>>>> re-started at a > >>>>>>>> later point (e.g Recording of a company meeting where > >>>>> you may want > >>>>>> to > >>>>>>>> record only portions of meeting). > >>>>>>>> > >>>>>>>> In any case, the point I like to high light here is, MS > >>>>>> block could > >>>>>>> be > >>>>>>>> common across RS and even across CS[ due to consult > >>>>>> transfer e.t.c]. > >>>>>>>> These use cases indicate the need to have a unique ID > >>>>> for MS block > >>>>> > >>>>>>>> (similar to the UUID that we have defined in format) as > >>>>> we cannot > >>>>>>>> depend on neither CS ID or RS ID. > >>>>>>> [JRE] I am having a hard time understanding the concept > >>>>> of a single > >>>>>>> Media Stream that survives across multiple CSs. For > >>>>> example, in the > >>>>>>> case of transfer, I would have thought new Media > >>>> Streams would be > >>>>>>> created. > >>>>>> > >>>>>> [RAM] > >>>>>> Here is my thoughts. > >>>>>> 1) There can be multiple RS per CS > >>>>>> RS1 --- CS1--MS1 > >>>>>> RS2----CS1--MS1 > >>>>>> Examples are partial recording of CS (like recording parts > >>>>> of meeting, > >>>>> > >>>>>> redundant recording where there are multiple SRCs recording > >>>>> the same > >>>>>> CS) > >>>>> [JRE] Agreed. In this case MS1 is local to CS1. > >>>>> > >>>>>> > >>>>>> 2) There can be same Media Stream across multiple CS. > >>>>>> RS1--- CS1--- MS1 > >>>>>> RS2--CS2--MS1 > >>>>>> Examples are Multicast MoH played to multiple end points who are > >>>>>> potentially part of disjoint CSs where each CS is recorded > >>>>> as part of > >>>>>> separate RS. > >>>>>> > >>>>>> Of course the above is arguable where the stream is same or > >>>>> different. > >>>>>> My view is since the UA (that supplies the Multicast MoH) and > its > >>>>>> media are same across all CS, I think it can be represented > >>>>> as same MS > >>>>> > >>>>>> block. > >>>>> [JRE] I would argue these are different MSs. I agree that a > medium > >>>>> such as music on hold might be sent, in synch, to multiple > >>>>> participants in multiple CSs. In that particular situation > >>>> there might > >>>> > >>>>> be some efficiency saving by calling it the same MS. > >>>> However, I would > >>>>> suggest (although this is not my field of expertise) it would > make > >>>>> life a lot harder for the SRS and its database. I would > >>>> have expected > >>>>> to want to record a complete CS (all its participants and media > >>>>> streams) as a complete recording, which could be deleted, > >>>> copied, and > >>>> > >>>>> so on without having to go looking for other objects that > complete > >>>>> that recording and are shared with other recordings. For > >>>> example, if > >>>>> you delete a recording, you would want to delete all its > >>>> MSs, but not > >>>>> those used by other recordings, although you would need a garbage > >>>>> collection mechanism to delete an MS recording when it is no > > longer > >>>>> used by any CS recordings. Rather ugly. Making a MS local to a CS > >>>>> would simplify all this. > >>>>> > >>>>>> > >>>>>> > >>>>>> However it is still possible to treat each as separate > >>>>> stream in the > >>>>>> model, in which case the information that it is the same MS > >>>>> played by > >>>>>> a UA to different CS will be lost. I don't know if there is an > >>>>>> interest to capture this level of detail and if it is of > >>>> any use to > >>>>>> SRS. > >>>>> [JRE] I assume what you are saying here is not that > >>>> information will > >>>>> be lost, but that you will be unable to tell, without doing a > >>>>> comparison, whether two different MSs played to participants in > > two > >>>>> different CSs are identical or not for the particular time > >>>> span that > >>>>> is common. I don't see where such a requirement would come from. > >>>>> > >>>>> John (as individual) > >>>>> > >>>>> > >>>> > >>> > >> _______________________________________________ > >> 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. > > > > =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@cisco.com Thu Apr 28 08:42: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 1C1DFE0707 for ; Thu, 28 Apr 2011 08:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 LiwUDEuBzwv6 for ; Thu, 28 Apr 2011 08:42:39 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 5F15EE0685 for ; Thu, 28 Apr 2011 08:42:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=23154; q=dns/txt; s=iport; t=1304005359; x=1305214959; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=PHc18MKsJqUbdDHwr1iBWQ9cB4Rlh5rt3P36NuZIg7g=; b=KXaxikAh0vnWtcTTjJDftWaqREcZdNJ7VhIxB+HUzNFAg8nnnmoXoVZW BbTvI+ghxWd+mBLTv5E73fRGle8OxzN8ZafVBO+SNXc2oXwFNbm2ev8gL yBSabTmvrZkYszJFC1+aPhMQxo8sQao3Ji+gr5VDg0BT2Q7wwTcPbmdZi 4=; X-IronPort-AV: E=Sophos;i="4.64,281,1301875200"; d="scan'208";a="346496785" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by sj-iport-2.cisco.com with ESMTP; 28 Apr 2011 15:42:38 +0000 Received: from [10.86.245.99] ([10.86.245.99]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3SFgbN2028326; Thu, 28 Apr 2011 15:42:37 GMT Message-ID: <4DB98AED.3060005@cisco.com> Date: Thu, 28 Apr 2011 11:42:37 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Henry Lum References: <35BCE99A477D6A4986FB2216D8CF2CFD06133DD4@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD06133E6B@XMB-BGL-417.cisco.com> <4DB81F8A.8000306@cisco.com> <059AF07365DC474393A19A3AF187DF7406F8FBA1@NAHALD.us.int.genesyslab.com> <4DB89EE3.8070504@cisco.com> <059AF07365DC474393A19A3AF187DF7406F8FCDC@NAHALD.us.int.genesyslab.com> In-Reply-To: <059AF07365DC474393A19A3AF187DF7406F8FCDC@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] Does MS have life outside a particular CS? (was RE: comments on draft-ram-siprec-metadata-04) X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 28 Apr 2011 15:42:41 -0000 On 4/28/2011 11:19 AM, Henry Lum wrote: > I agree it would be out of scope for two different SRCs to refer to the > same CS. The metadata model currently does not seem to prevent such > scenario, as long as there is a way to identify the same CS across > different SRC. The CS Identifier currently states that it is a unique > identifier, and I don't think we should mandate that to be globally > unique across multiple SRCs like the CSG identifier. Once you decide to have a "unique" id assigned by the SRC, its very little harder to make it globally unique rather than simply unique to an RS or an SRC. And there is very little benefit to the SRS to narrowing the scope either. We only get to make this decision once. Its really hard to retrofit later to extend the scope. IMO all of the IDs should be globally unique. That gives us a lot more flexibility in how this evolves in the future. How we convey the id (as a URL, or something else) is another matter, and much less of a big deal. If the concern is how many bytes it consumes in the message then we can work on that. In any case, while proposed mechanisms must satisfy the requirements, AFAIK there is no reason that a proposed mechanism cannot go beyond the stated requirements. If there are multiple proposed mechanisms, and one has ids more global than another, then people can decide which they like better. But the choice is only among what is proposed. So if there are two philosophies in this regard, then maybe there had better be two proposed mechanisms. Or, I guess someone could propose a new requirement: "Unique IDs in the mechanism MUST NOT be globally scoped - they MUST be locally scoped to an RS and duplicated across RSs". (I won't support that one.) Thanks, Paul > Regards, > Henry > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Wednesday, April 27, 2011 6:56 PM >> To: Henry Lum >> Cc: Parthasarathi R (partr); siprec@ietf.org >> Subject: Re: [siprec] Does MS have life outside a particular CS? (was >> RE: comments on draft-ram-siprec-metadata-04) >> >> >> >> On 4/27/2011 5:01 PM, Henry Lum wrote: >>>> Presumably the RTP streams associated with the RS end when the RS >>> ends. >>>> That does not necessarily mean that the media stream of a CS also >> ends >>> at >>>> that time. It could be picked up again in a different RS by the > same >>> or >>>> different SRC. >>> >>> IIUC, a single CS is only mapped to a single SRC. If we have a media >>> stream of a CS picked by another SRC, then it should be a different >> CS >>> but can be related to the same CS group. >> >> Two things: >> >> It could be the same SRC but two different RSs. (Perhaps it drops the >> RS >> during a long pause, or because the SRS crashed and restarted and the >> SRC had to reconnect.) >> >> If there are two different SRCs, and they happen to know it is the > same >> CS (I'm not proposing *how* they know), it would be better to refer to >> the same CS. >> >> I'm not saying we should require SRCs to do such things - only that a >> design that permits this is better than one that does not. >> >> Thanks, >> Paul >> >>> Henry >>> >>>> -----Original Message----- >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>> Behalf >>>> Of Paul Kyzivat >>>> Sent: April-27-11 9:52 AM >>>> To: Parthasarathi R (partr) >>>> Cc: siprec@ietf.org >>>> Subject: Re: [siprec] Does MS have life outside a particular CS? >> (was >>> RE: >>>> comments on draft-ram-siprec-metadata-04) >>>> >>>> There seems to be some confusion in this discussion about what a MS >>> is. >>>> >>>> On one hand there is an m-line in the SDP of the RS, and a >>> corresponding RTP >>>> stream. >>>> >>>> On another hand there is an m-line in a CS and a corresponding RTP >>> stream. >>>> >>>> And then there is an MS described in the metadata conveyed over the >>> RS. >>>> >>>> And for both of the above, a single m-line might correspond to >>> different RTP >>>> streams over time, due to renegotiating the address and/or port of >> the >>>> recipient, or by a different sender sending to the same port. >>>> >>>> There is a mapping between one or more RTP streams in the CS (or >>> multiple >>>> CSs?) and one or more RTP streams in the RS. The metadata hopefully >>>> describes that mapping. >>>> >>>> But perhaps we don't have full agreement on what sorts of mappings >> are >>>> possible. Some that I think we allow are: >>>> - one CS RTP stream to one RS RTP stream. >>>> - multiple concurrent CS RTP streams mixed to one >>>> RS RTP stream >>>> - multiple CS RTP streams sequentially mapped to the same >>>> RS RTP stream >>>> ... >>>> >>>> Presumably the RTP streams associated with the RS end when the RS >>> ends. >>>> That does not necessarily mean that the media stream of a CS also >> ends >>> at >>>> that time. It could be picked up again in a different RS by the > same >>> or >>>> different SRC. >>>> >>>> Thanks, >>>> Paul >>>> >>>> On 4/27/2011 2:30 AM, Parthasarathi R (partr) wrote: >>>>> John, >>>>> >>>>> My intention is show the complexity in the metadata model in the >>>>> current form. Global unique id solves the issue but let us explore >>> for >>>>> better optimized solution with more local unique id if any exists. >>>>> >>>>> I have created another mail thread for adding the recording type >>>>> attribute which helps in most of the metadata blocks to have local >>>>> unique id rather than global unique id. Let us see how others >>>>> visualize that attribute. >>>>> >>>>> IMO, it may better to have globally unique id with the current >>>>> metadata model attributes. We may be able to add the normative >>>>> statement that "Media stream (MS) MUST be terminated when CS is >>>>> terminated" in the metadata but in reality, MS is within the scope >>> of >>>>> RS which is forced to delete for no reason. These sort will be >>>>> restrictive for few SRC implementation. For eg: RS may created MS >>> with >>>>> RSVP which may not prefer to terminate the resource during RS >>>>> mid-session changes like CS changes even though intermediate time >>> with >>>>> no media but the above normative statement forces to break those >> SRC >>>> implementation. >>>>> >>>>> Please read inline for more comments. >>>>> >>>>> Thanks >>>>> Partha >>>>> >>>>> -----Original Message----- >>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>>>> Sent: Friday, April 22, 2011 1:48 AM >>>>> To: Parthasarathi R (partr); Ram Mohan R (rmohanr); Paul Kyzivat >>>>> (pkyzivat) >>>>> Cc: siprec@ietf.org >>>>> Subject: RE: Does MS have life outside a particular CS? (was RE: >>>>> [siprec] comments on draft-ram-siprec-metadata-04) >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] >>>>>> Sent: 21 April 2011 17:20 >>>>>> To: Elwell, John; Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) >>>>>> Cc: siprec@ietf.org >>>>>> Subject: RE: Does MS have life outside a particular CS? (was >>>>>> RE: [siprec] comments on draft-ram-siprec-metadata-04) >>>>>> >>>>>> John, >>>>>> >>>>>> Please read inline. >>>>>> >>>>>> Thanks >>>>>> Partha >>>>>> >>>>>> -----Original Message----- >>>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>>>>> Sent: Thursday, April 21, 2011 9:12 PM >>>>>> To: Parthasarathi R (partr); Ram Mohan R (rmohanr); Paul Kyzivat >>>>>> (pkyzivat) >>>>>> Cc: siprec@ietf.org >>>>>> Subject: RE: Does MS have life outside a particular CS? (was RE: >>>>>> [siprec] comments on draft-ram-siprec-metadata-04) >>>>>> >>>>>> Partha, >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] >>>>>>> Sent: 21 April 2011 14:25 >>>>>>> To: Elwell, John; Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) >>>>>>> Cc: siprec@ietf.org >>>>>>> Subject: RE: Does MS have life outside a particular CS? (was >>>>>>> RE: [siprec] comments on draft-ram-siprec-metadata-04) >>>>>>> >>>>>>> John, >>>>>>> >>>>>>> I could think of one usecase wherein MS is outside CS but within >>>>>>> single RS. The usecase is multiple CS within single RS and MS. >>> The >>>>>>> usecase is as follows: >>>>>>> >>>>>>> B2BUA acts as SRC. A, B, C are participants within single B2BUA. >> A >>>>>>> creates single RS for a CSG. >>>>>>> >>>>>>> 1) A calls B through B2BUA. B2BUA creates RS towards SRS with >>> CSG1, >>>>>>> CS1, >>>>>>> MS1 (A's media stream), MS2 (B's media stream), Participant1 as >> A& >>>>>>> Participant2 as B. >>>>>> [JRE] Why two media streams? Why not a single MS, with both A and >> B >>>>>> sending and receiving that MS? >>>>>> The media streams are un-mixed, MS1 points to RTP from >> A >>>>>> through label attribute in MS1 SDP, MS2 points to RTP from B >>> through >>>>>> label attribute in MS2 SDP >>>>> [JRE] Reading the metadata model again, I think it does seem to >>> imply >>>>> two Media Stream objects if the two directions for a 2-party call >>> are >>>>> sent unmixed (as two m-lines in the RS SDP), so I will concede > that >>> we >>>>> have two Media Stream objects here. I had been thinking of a >>> slightly >>>>> different model, where there is one Media Stream, but associations >>>>> between the Media Stream and Participants pointed to different >>> m-lines >>>>> in the RS SDP. >>>>> >>>>>> >>>>>>> 2) B connects with C through B2BUA >>>>>>> 3) B transfer the call of A& B to C using REFER, B2BUA >>>>>> converts REFER >>>>>> >>>>>>> to RE-INVITE towards A& C and A& C are connected. B2BUA >>>>>> updates RS >>>>>>> with CS2, Participant1 as A& participant2 as C, MS1(A's media >>>>>>> stream), MS2(C's media stream). >>>>>> [JRE] I would have expected, from my understanding of the > metadata >>>>>> model, that the CS2 would have a new MS, with both A and B > sending >>>>>> and >>>>> >>>>>> receiving that new MS. >>>>>> >>>>>> It is not mandatory because participant information >> will >>> be >>>>>> updated and pointing to the same m-line in RS with same label >>>>>> attribute. >>>>>> From SRS perspective, the same media stream with the update in >> the >>>>>> participant name only. Say MS2 is stored as one record with B as >>>>>> participant for T0 to T1 timelines and C as participant from T1 > to >>> T2. >>>>>> >>>>> [JRE] Or alternatively it could be modelled that when a new CS >>> starts >>>>> there is a new Media Stream object, still pointing to the same >>> m-line >>>>> in the RS SDP. >>>>> >>>>> The purpose of unique-id will go for toss here. The > same >>>>> media stream (MS) has unique id "id1" initially and later it will >>> have "id2" >>>>> which will not be good for replay. Of course, MS life is always >>> within >>>>> RS in this scenario but not within CS. So, Unique Id within RS > will >>>>> serve the purpose >>>>> >>>>> This would avoid the need for a Media Stream object to survive >>>>> beyond the lifetime of a CS, and therefore allow local >>> identification. >>>>> While there is no CS in progress, the m-line would be disabled >> (port >>>>> 0) and would not be referenced by any Media Stream. >>>>> >>>>> RS m-line is not required to 0 because it shall change >>> into >>>>> "a=inactive" as well. There is no change in the resource >> reservation >>>>> in both SRC and SRS >>>>> >>>>>> >>>>>>> There is no update on RS1, CSG1, MS1, MS2. MS2 will become MS2 >>> with >>>>>>> the new association and in terms of format, it will associate >> with >>>>>>> tag. >>>>>>> >>>>>>> In the above scenario, MS have life outside CS but it is within >>> RS. >>>>>> [JRE] I can see how it COULD work like that, but it is not >>> intuitive. >>>>>> >>>>>> In SIPREC solution, UPDATE message with CS2(session >>>>>> element) , >>>>>> participant "C" element are received in SRS. This partial update >> of >>>>>> UPDATE helps to make this scenario work. There is no change in >> term >>>>>> stream element or RS SDP >>>>>> >>>>>> To me, a new CS means the existing media stream stops and a new >>> media >>>>>> stream is created. >>>>>> >>>>>> I'm interested knowing whether you propose that MS > MUST >>>>>> stop in case CS ends and the above scenario is outside the scope >> of >>>> SIPREC? >>>>>> >>>>>> >>>>>>> The >>>>>>> unique id shall be within RS scope as mentioned in IETF-80 >>> meeting. >>>>>>> But in another situation, MS is outside the scope of RS but >>>>>> within CS >>>>>>> and the usecase is Multiple RS for single CS, details are >>>>>> as follows: >>>>>>> >>>>>>> A, B are pariticipants. A acts as SRC which tear down RS >>>>>> whenever hold >>>>>> >>>>>>> happens& creates new RS when resume happens. >>>>>>> >>>>>>> 1) A calls B. A creates RS1 towards SRS with CS1, MS1 (A's media >>>>>>> stream), MS2 (B's Media stream),Participant1 as A& >>>>>> Participant2 as B. >>>>>> [JRE] Again, I would model this as a single MS, to which both A >> and >>> B >>>>>> contribute. >>>>>> Again, unmixed stream from A and B >>>>>>> 2) A put B on hold. A tear down RS1. >>>>>>> 3) A resume B. A creates RS2 towards SRS with CS1, MS1 (A's > media >>>>>>> stream), MS2 (B's Media stream),Participant1 as A& >>>>>> Participant2 as B >>>>>>> >>>>>>> Here MS1& MS2 needs to be same across RS to group media > streams >>>>>>> correctly. Please let me know your opinion here. >>>>>> >>>>>> [JRE] Although I disagree that we have two Media Streams here, I >> do >>>>>> agree that the single Media Stream could be considered to survive >>> the >>>>>> hold/resume, and hence survive from RS1 to RS2. But the MS is >>> within >>>>>> the context of the same CS (CS1), and therefore this is outside >> the >>>>>> scope of this particular thread, which is asking whether an MS > can >>>>>> have a life outside a particular CS. In this case the MS > continues >>> to >>>>>> be associated with the CS, so I don't have a problem with that. >>>>>> >>>>>> I have 2nd example to illustrate MS have life outside >> RS. >>>>>> >>>>>> >>>>>> So you have failed to convince me that an MS needs to have a life >>>>>> outside a CS. >>>>>> >>>>>> In case the above scenario-1 way of recording is >> outside >>>>>> the scope of SIPREC, I agree with you that MS does not have life >>>>>> outside a >>>>> >>>>>> particular CS >>>>> [JRE] I assume you are talking about the call transfer case. I am >>> not >>>>> saying that use case is outside the scope of SIPREC. I am just >>> saying >>>>> that it can be modelled a different way, which may be advantageous >>> in >>>>> terms of the number of globally unique identifiers needed. >>>>> >>>>> >>>>> John (as individual) >>>>> >>>>> >>>>> >>>>>> >>>>>> John (as individual) >>>>>> >>>>>> >>>>>>> >>>>>>> Having said that MS have life outside a particular CS, I create >>>>>>> separate thread within unique how it shall be handled. >>>>>>> >>>>>>> Thanks >>>>>>> Partha >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>>>>>> Sent: Thursday, April 21, 2011 12:01 PM >>>>>>> To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) >>>>>>> Cc: Parthasarathi R (partr); siprec@ietf.org >>>>>>> Subject: Does MS have life outside a particular CS? (was >>>>>> RE: [siprec] >>>>>>> comments on draft-ram-siprec-metadata-04) >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] >>>>>>>> Sent: 20 April 2011 18:08 >>>>>>>> To: Elwell, John; Paul Kyzivat (pkyzivat) >>>>>>>> Cc: Parthasarathi R (partr); siprec@ietf.org >>>>>>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 >>>>>>>> >>>>>>>> Hi John, >>>>>>>> >>>>>>>> Please see inline [RAM] >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>>>>>>>> Sent: Wednesday, April 20, 2011 8:19 PM >>>>>>>>> To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) >>>>>>>>> Cc: Parthasarathi R (partr); siprec@ietf.org >>>>>>>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] >>>>>>>>>> Sent: 20 April 2011 14:52 >>>>>>>>>> To: Elwell, John; Paul Kyzivat (pkyzivat) >>>>>>>>>> Cc: Parthasarathi R (partr); siprec@ietf.org >>>>>>>>>> Subject: RE: [siprec] comments on > draft-ram-siprec-metadata-04 >>>>>>>>>> >>>>>>>>>> John, >>>>>>>>>> >>>>>>>>>> I agree with you that normal cases RS will remain at >>>>>>> least for the >>>>>>> >>>>>>>>>> duration of CS. However it is common to have use cases where >>>>>>>>> recording >>>>>>>>>> is done for first few mins of a CS and then stopped, >>>>>>>> re-started at a >>>>>>>>>> later point (e.g Recording of a company meeting where >>>>>>> you may want >>>>>>>> to >>>>>>>>>> record only portions of meeting). >>>>>>>>>> >>>>>>>>>> In any case, the point I like to high light here is, MS >>>>>>>> block could >>>>>>>>> be >>>>>>>>>> common across RS and even across CS[ due to consult >>>>>>>> transfer e.t.c]. >>>>>>>>>> These use cases indicate the need to have a unique ID >>>>>>> for MS block >>>>>>> >>>>>>>>>> (similar to the UUID that we have defined in format) as >>>>>>> we cannot >>>>>>>>>> depend on neither CS ID or RS ID. >>>>>>>>> [JRE] I am having a hard time understanding the concept >>>>>>> of a single >>>>>>>>> Media Stream that survives across multiple CSs. For >>>>>>> example, in the >>>>>>>>> case of transfer, I would have thought new Media >>>>>> Streams would be >>>>>>>>> created. >>>>>>>> >>>>>>>> [RAM] >>>>>>>> Here is my thoughts. >>>>>>>> 1) There can be multiple RS per CS >>>>>>>> RS1 --- CS1--MS1 >>>>>>>> RS2----CS1--MS1 >>>>>>>> Examples are partial recording of CS (like recording parts >>>>>>> of meeting, >>>>>>> >>>>>>>> redundant recording where there are multiple SRCs recording >>>>>>> the same >>>>>>>> CS) >>>>>>> [JRE] Agreed. In this case MS1 is local to CS1. >>>>>>> >>>>>>>> >>>>>>>> 2) There can be same Media Stream across multiple CS. >>>>>>>> RS1--- CS1--- MS1 >>>>>>>> RS2--CS2--MS1 >>>>>>>> Examples are Multicast MoH played to multiple end points who > are >>>>>>>> potentially part of disjoint CSs where each CS is recorded >>>>>>> as part of >>>>>>>> separate RS. >>>>>>>> >>>>>>>> Of course the above is arguable where the stream is same or >>>>>>> different. >>>>>>>> My view is since the UA (that supplies the Multicast MoH) and >> its >>>>>>>> media are same across all CS, I think it can be represented >>>>>>> as same MS >>>>>>> >>>>>>>> block. >>>>>>> [JRE] I would argue these are different MSs. I agree that a >> medium >>>>>>> such as music on hold might be sent, in synch, to multiple >>>>>>> participants in multiple CSs. In that particular situation >>>>>> there might >>>>>> >>>>>>> be some efficiency saving by calling it the same MS. >>>>>> However, I would >>>>>>> suggest (although this is not my field of expertise) it would >> make >>>>>>> life a lot harder for the SRS and its database. I would >>>>>> have expected >>>>>>> to want to record a complete CS (all its participants and media >>>>>>> streams) as a complete recording, which could be deleted, >>>>>> copied, and >>>>>> >>>>>>> so on without having to go looking for other objects that >> complete >>>>>>> that recording and are shared with other recordings. For >>>>>> example, if >>>>>>> you delete a recording, you would want to delete all its >>>>>> MSs, but not >>>>>>> those used by other recordings, although you would need a > garbage >>>>>>> collection mechanism to delete an MS recording when it is no >>> longer >>>>>>> used by any CS recordings. Rather ugly. Making a MS local to a > CS >>>>>>> would simplify all this. >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> However it is still possible to treat each as separate >>>>>>> stream in the >>>>>>>> model, in which case the information that it is the same MS >>>>>>> played by >>>>>>>> a UA to different CS will be lost. I don't know if there is an >>>>>>>> interest to capture this level of detail and if it is of >>>>>> any use to >>>>>>>> SRS. >>>>>>> [JRE] I assume what you are saying here is not that >>>>>> information will >>>>>>> be lost, but that you will be unable to tell, without doing a >>>>>>> comparison, whether two different MSs played to participants in >>> two >>>>>>> different CSs are identical or not for the particular time >>>>>> span that >>>>>>> is common. I don't see where such a requirement would come from. >>>>>>> >>>>>>> John (as individual) >>>>>>> >>>>>>> >>>>>> >>>>> >>>> _______________________________________________ >>>> 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. >>> >>> > > > ------------------------------------------------------------------------------------------------------------------- > 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 Leon.Portman@nice.com Thu Apr 28 08:57: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 D6A12E0670 for ; Thu, 28 Apr 2011 08:57:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.41 X-Spam-Level: X-Spam-Status: No, score=-1.41 tagged_above=-999 required=5 tests=[AWL=-0.915, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 Zy5dFhnUZAzm for ; Thu, 28 Apr 2011 08:57:52 -0700 (PDT) Received: from mailil.nice.com (unknown [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id 2BA1DE0669 for ; Thu, 28 Apr 2011 08:57:51 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Thu, 28 Apr 2011 18:57:49 +0300 From: Leon Portman To: Paul Kyzivat , Henry Lum Date: Thu, 28 Apr 2011 18:57:47 +0300 Thread-Topic: [siprec] Does MS have life outside a particular CS? (was RE: comments on draft-ram-siprec-metadata-04) Thread-Index: AcwFuuvxdSy9/XTRSVq5DE/JiXPmDAAAgTPw Message-ID: <07465C1D981ABC41A344374066AE1A2C38AB7A20DB@TLVMBX01.nice.com> References: <35BCE99A477D6A4986FB2216D8CF2CFD06133DD4@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD06133E6B@XMB-BGL-417.cisco.com> <4DB81F8A.8000306@cisco.com> <059AF07365DC474393A19A3AF187DF7406F8FBA1@NAHALD.us.int.genesyslab.com> <4DB89EE3.8070504@cisco.com> <059AF07365DC474393A19A3AF187DF7406F8FCDC@NAHALD.us.int.genesyslab.com> <4DB98AED.3060005@cisco.com> In-Reply-To: <4DB98AED.3060005@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 Cc: "siprec@ietf.org" Subject: Re: [siprec] Does MS have life outside a particular CS? (was RE: comments on draft-ram-siprec-metadata-04) X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 28 Apr 2011 15:57:54 -0000 I agree that we should have all IDs to be globally unique. Leon -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Paul Kyzivat Sent: Thursday, April 28, 2011 6:43 PM To: Henry Lum Cc: siprec@ietf.org Subject: Re: [siprec] Does MS have life outside a particular CS? (was RE: c= omments on draft-ram-siprec-metadata-04) On 4/28/2011 11:19 AM, Henry Lum wrote: > I agree it would be out of scope for two different SRCs to refer to > the same CS. The metadata model currently does not seem to prevent > such scenario, as long as there is a way to identify the same CS > across different SRC. The CS Identifier currently states that it is a > unique identifier, and I don't think we should mandate that to be > globally unique across multiple SRCs like the CSG identifier. Once you decide to have a "unique" id assigned by the SRC, its very little = harder to make it globally unique rather than simply unique to an RS or an = SRC. And there is very little benefit to the SRS to narrowing the scope eit= her. We only get to make this decision once. Its really hard to retrofit later t= o extend the scope. IMO all of the IDs should be globally unique. That gives us a lot more flexibility in how this evolves in the future. How we convey the id (as a URL, or something else) is another matter, and m= uch less of a big deal. If the concern is how many bytes it consumes in the= message then we can work on that. In any case, while proposed mechanisms must satisfy the requirements, AFAIK= there is no reason that a proposed mechanism cannot go beyond the stated r= equirements. If there are multiple proposed mechanisms, and one has ids mor= e global than another, then people can decide which they like better. But t= he choice is only among what is proposed. So if there are two philosophies = in this regard, then maybe there had better be two proposed mechanisms. Or, I guess someone could propose a new requirement: "Unique IDs in the mec= hanism MUST NOT be globally scoped - they MUST be locally scoped to an RS a= nd duplicated across RSs". (I won't support that one.) Thanks, Paul > Regards, > Henry > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Wednesday, April 27, 2011 6:56 PM >> To: Henry Lum >> Cc: Parthasarathi R (partr); siprec@ietf.org >> Subject: Re: [siprec] Does MS have life outside a particular CS? (was >> RE: comments on draft-ram-siprec-metadata-04) >> >> >> >> On 4/27/2011 5:01 PM, Henry Lum wrote: >>>> Presumably the RTP streams associated with the RS end when the RS >>> ends. >>>> That does not necessarily mean that the media stream of a CS also >> ends >>> at >>>> that time. It could be picked up again in a different RS by the > same >>> or >>>> different SRC. >>> >>> IIUC, a single CS is only mapped to a single SRC. If we have a media >>> stream of a CS picked by another SRC, then it should be a different >> CS >>> but can be related to the same CS group. >> >> Two things: >> >> It could be the same SRC but two different RSs. (Perhaps it drops the >> RS during a long pause, or because the SRS crashed and restarted and >> the SRC had to reconnect.) >> >> If there are two different SRCs, and they happen to know it is the > same >> CS (I'm not proposing *how* they know), it would be better to refer >> to the same CS. >> >> I'm not saying we should require SRCs to do such things - only that a >> design that permits this is better than one that does not. >> >> Thanks, >> Paul >> >>> Henry >>> >>>> -----Original Message----- >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>> Behalf >>>> Of Paul Kyzivat >>>> Sent: April-27-11 9:52 AM >>>> To: Parthasarathi R (partr) >>>> Cc: siprec@ietf.org >>>> Subject: Re: [siprec] Does MS have life outside a particular CS? >> (was >>> RE: >>>> comments on draft-ram-siprec-metadata-04) >>>> >>>> There seems to be some confusion in this discussion about what a MS >>> is. >>>> >>>> On one hand there is an m-line in the SDP of the RS, and a >>> corresponding RTP >>>> stream. >>>> >>>> On another hand there is an m-line in a CS and a corresponding RTP >>> stream. >>>> >>>> And then there is an MS described in the metadata conveyed over the >>> RS. >>>> >>>> And for both of the above, a single m-line might correspond to >>> different RTP >>>> streams over time, due to renegotiating the address and/or port of >> the >>>> recipient, or by a different sender sending to the same port. >>>> >>>> There is a mapping between one or more RTP streams in the CS (or >>> multiple >>>> CSs?) and one or more RTP streams in the RS. The metadata hopefully >>>> describes that mapping. >>>> >>>> But perhaps we don't have full agreement on what sorts of mappings >> are >>>> possible. Some that I think we allow are: >>>> - one CS RTP stream to one RS RTP stream. >>>> - multiple concurrent CS RTP streams mixed to one >>>> RS RTP stream >>>> - multiple CS RTP streams sequentially mapped to the same >>>> RS RTP stream >>>> ... >>>> >>>> Presumably the RTP streams associated with the RS end when the RS >>> ends. >>>> That does not necessarily mean that the media stream of a CS also >> ends >>> at >>>> that time. It could be picked up again in a different RS by the > same >>> or >>>> different SRC. >>>> >>>> Thanks, >>>> Paul >>>> >>>> On 4/27/2011 2:30 AM, Parthasarathi R (partr) wrote: >>>>> John, >>>>> >>>>> My intention is show the complexity in the metadata model in the >>>>> current form. Global unique id solves the issue but let us explore >>> for >>>>> better optimized solution with more local unique id if any exists. >>>>> >>>>> I have created another mail thread for adding the recording type >>>>> attribute which helps in most of the metadata blocks to have local >>>>> unique id rather than global unique id. Let us see how others >>>>> visualize that attribute. >>>>> >>>>> IMO, it may better to have globally unique id with the current >>>>> metadata model attributes. We may be able to add the normative >>>>> statement that "Media stream (MS) MUST be terminated when CS is >>>>> terminated" in the metadata but in reality, MS is within the scope >>> of >>>>> RS which is forced to delete for no reason. These sort will be >>>>> restrictive for few SRC implementation. For eg: RS may created MS >>> with >>>>> RSVP which may not prefer to terminate the resource during RS >>>>> mid-session changes like CS changes even though intermediate time >>> with >>>>> no media but the above normative statement forces to break those >> SRC >>>> implementation. >>>>> >>>>> Please read inline for more comments. >>>>> >>>>> Thanks >>>>> Partha >>>>> >>>>> -----Original Message----- >>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>>>> Sent: Friday, April 22, 2011 1:48 AM >>>>> To: Parthasarathi R (partr); Ram Mohan R (rmohanr); Paul Kyzivat >>>>> (pkyzivat) >>>>> Cc: siprec@ietf.org >>>>> Subject: RE: Does MS have life outside a particular CS? (was RE: >>>>> [siprec] comments on draft-ram-siprec-metadata-04) >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] >>>>>> Sent: 21 April 2011 17:20 >>>>>> To: Elwell, John; Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) >>>>>> Cc: siprec@ietf.org >>>>>> Subject: RE: Does MS have life outside a particular CS? (was >>>>>> RE: [siprec] comments on draft-ram-siprec-metadata-04) >>>>>> >>>>>> John, >>>>>> >>>>>> Please read inline. >>>>>> >>>>>> Thanks >>>>>> Partha >>>>>> >>>>>> -----Original Message----- >>>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>>>>> Sent: Thursday, April 21, 2011 9:12 PM >>>>>> To: Parthasarathi R (partr); Ram Mohan R (rmohanr); Paul Kyzivat >>>>>> (pkyzivat) >>>>>> Cc: siprec@ietf.org >>>>>> Subject: RE: Does MS have life outside a particular CS? (was RE: >>>>>> [siprec] comments on draft-ram-siprec-metadata-04) >>>>>> >>>>>> Partha, >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Parthasarathi R (partr) [mailto:partr@cisco.com] >>>>>>> Sent: 21 April 2011 14:25 >>>>>>> To: Elwell, John; Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) >>>>>>> Cc: siprec@ietf.org >>>>>>> Subject: RE: Does MS have life outside a particular CS? (was >>>>>>> RE: [siprec] comments on draft-ram-siprec-metadata-04) >>>>>>> >>>>>>> John, >>>>>>> >>>>>>> I could think of one usecase wherein MS is outside CS but within >>>>>>> single RS. The usecase is multiple CS within single RS and MS. >>> The >>>>>>> usecase is as follows: >>>>>>> >>>>>>> B2BUA acts as SRC. A, B, C are participants within single B2BUA. >> A >>>>>>> creates single RS for a CSG. >>>>>>> >>>>>>> 1) A calls B through B2BUA. B2BUA creates RS towards SRS with >>> CSG1, >>>>>>> CS1, >>>>>>> MS1 (A's media stream), MS2 (B's media stream), Participant1 as >> A& >>>>>>> Participant2 as B. >>>>>> [JRE] Why two media streams? Why not a single MS, with both A and >> B >>>>>> sending and receiving that MS? >>>>>> The media streams are un-mixed, MS1 points to RTP from >> A >>>>>> through label attribute in MS1 SDP, MS2 points to RTP from B >>> through >>>>>> label attribute in MS2 SDP >>>>> [JRE] Reading the metadata model again, I think it does seem to >>> imply >>>>> two Media Stream objects if the two directions for a 2-party call >>> are >>>>> sent unmixed (as two m-lines in the RS SDP), so I will concede > that >>> we >>>>> have two Media Stream objects here. I had been thinking of a >>> slightly >>>>> different model, where there is one Media Stream, but associations >>>>> between the Media Stream and Participants pointed to different >>> m-lines >>>>> in the RS SDP. >>>>> >>>>>> >>>>>>> 2) B connects with C through B2BUA >>>>>>> 3) B transfer the call of A& B to C using REFER, B2BUA >>>>>> converts REFER >>>>>> >>>>>>> to RE-INVITE towards A& C and A& C are connected. B2BUA >>>>>> updates RS >>>>>>> with CS2, Participant1 as A& participant2 as C, MS1(A's media >>>>>>> stream), MS2(C's media stream). >>>>>> [JRE] I would have expected, from my understanding of the > metadata >>>>>> model, that the CS2 would have a new MS, with both A and B > sending >>>>>> and >>>>> >>>>>> receiving that new MS. >>>>>> >>>>>> It is not mandatory because participant information >> will >>> be >>>>>> updated and pointing to the same m-line in RS with same label >>>>>> attribute. >>>>>> From SRS perspective, the same media stream with the update in >> the >>>>>> participant name only. Say MS2 is stored as one record with B as >>>>>> participant for T0 to T1 timelines and C as participant from T1 > to >>> T2. >>>>>> >>>>> [JRE] Or alternatively it could be modelled that when a new CS >>> starts >>>>> there is a new Media Stream object, still pointing to the same >>> m-line >>>>> in the RS SDP. >>>>> >>>>> The purpose of unique-id will go for toss here. The > same >>>>> media stream (MS) has unique id "id1" initially and later it will >>> have "id2" >>>>> which will not be good for replay. Of course, MS life is always >>> within >>>>> RS in this scenario but not within CS. So, Unique Id within RS > will >>>>> serve the purpose >>>>> >>>>> This would avoid the need for a Media Stream object to survive >>>>> beyond the lifetime of a CS, and therefore allow local >>> identification. >>>>> While there is no CS in progress, the m-line would be disabled >> (port >>>>> 0) and would not be referenced by any Media Stream. >>>>> >>>>> RS m-line is not required to 0 because it shall change >>> into >>>>> "a=3Dinactive" as well. There is no change in the resource >> reservation >>>>> in both SRC and SRS >>>>> >>>>>> >>>>>>> There is no update on RS1, CSG1, MS1, MS2. MS2 will become MS2 >>> with >>>>>>> the new association and in terms of format, it will associate >> with >>>>>>> tag. >>>>>>> >>>>>>> In the above scenario, MS have life outside CS but it is within >>> RS. >>>>>> [JRE] I can see how it COULD work like that, but it is not >>> intuitive. >>>>>> >>>>>> In SIPREC solution, UPDATE message with CS2(session >>>>>> element) , >>>>>> participant "C" element are received in SRS. This partial update >> of >>>>>> UPDATE helps to make this scenario work. There is no change in >> term >>>>>> stream element or RS SDP >>>>>> >>>>>> To me, a new CS means the existing media stream stops and a new >>> media >>>>>> stream is created. >>>>>> >>>>>> I'm interested knowing whether you propose that MS > MUST >>>>>> stop in case CS ends and the above scenario is outside the scope >> of >>>> SIPREC? >>>>>> >>>>>> >>>>>>> The >>>>>>> unique id shall be within RS scope as mentioned in IETF-80 >>> meeting. >>>>>>> But in another situation, MS is outside the scope of RS but >>>>>> within CS >>>>>>> and the usecase is Multiple RS for single CS, details are >>>>>> as follows: >>>>>>> >>>>>>> A, B are pariticipants. A acts as SRC which tear down RS >>>>>> whenever hold >>>>>> >>>>>>> happens& creates new RS when resume happens. >>>>>>> >>>>>>> 1) A calls B. A creates RS1 towards SRS with CS1, MS1 (A's media >>>>>>> stream), MS2 (B's Media stream),Participant1 as A& >>>>>> Participant2 as B. >>>>>> [JRE] Again, I would model this as a single MS, to which both A >> and >>> B >>>>>> contribute. >>>>>> Again, unmixed stream from A and B >>>>>>> 2) A put B on hold. A tear down RS1. >>>>>>> 3) A resume B. A creates RS2 towards SRS with CS1, MS1 (A's > media >>>>>>> stream), MS2 (B's Media stream),Participant1 as A& >>>>>> Participant2 as B >>>>>>> >>>>>>> Here MS1& MS2 needs to be same across RS to group media > streams >>>>>>> correctly. Please let me know your opinion here. >>>>>> >>>>>> [JRE] Although I disagree that we have two Media Streams here, I >> do >>>>>> agree that the single Media Stream could be considered to survive >>> the >>>>>> hold/resume, and hence survive from RS1 to RS2. But the MS is >>> within >>>>>> the context of the same CS (CS1), and therefore this is outside >> the >>>>>> scope of this particular thread, which is asking whether an MS > can >>>>>> have a life outside a particular CS. In this case the MS > continues >>> to >>>>>> be associated with the CS, so I don't have a problem with that. >>>>>> >>>>>> I have 2nd example to illustrate MS have life outside >> RS. >>>>>> >>>>>> >>>>>> So you have failed to convince me that an MS needs to have a life >>>>>> outside a CS. >>>>>> >>>>>> In case the above scenario-1 way of recording is >> outside >>>>>> the scope of SIPREC, I agree with you that MS does not have life >>>>>> outside a >>>>> >>>>>> particular CS >>>>> [JRE] I assume you are talking about the call transfer case. I am >>> not >>>>> saying that use case is outside the scope of SIPREC. I am just >>> saying >>>>> that it can be modelled a different way, which may be advantageous >>> in >>>>> terms of the number of globally unique identifiers needed. >>>>> >>>>> >>>>> John (as individual) >>>>> >>>>> >>>>> >>>>>> >>>>>> John (as individual) >>>>>> >>>>>> >>>>>>> >>>>>>> Having said that MS have life outside a particular CS, I create >>>>>>> separate thread within unique how it shall be handled. >>>>>>> >>>>>>> Thanks >>>>>>> Partha >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>>>>>> Sent: Thursday, April 21, 2011 12:01 PM >>>>>>> To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) >>>>>>> Cc: Parthasarathi R (partr); siprec@ietf.org >>>>>>> Subject: Does MS have life outside a particular CS? (was >>>>>> RE: [siprec] >>>>>>> comments on draft-ram-siprec-metadata-04) >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] >>>>>>>> Sent: 20 April 2011 18:08 >>>>>>>> To: Elwell, John; Paul Kyzivat (pkyzivat) >>>>>>>> Cc: Parthasarathi R (partr); siprec@ietf.org >>>>>>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 >>>>>>>> >>>>>>>> Hi John, >>>>>>>> >>>>>>>> Please see inline [RAM] >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>>>>>>>> Sent: Wednesday, April 20, 2011 8:19 PM >>>>>>>>> To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) >>>>>>>>> Cc: Parthasarathi R (partr); siprec@ietf.org >>>>>>>>> Subject: RE: [siprec] comments on draft-ram-siprec-metadata-04 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] >>>>>>>>>> Sent: 20 April 2011 14:52 >>>>>>>>>> To: Elwell, John; Paul Kyzivat (pkyzivat) >>>>>>>>>> Cc: Parthasarathi R (partr); siprec@ietf.org >>>>>>>>>> Subject: RE: [siprec] comments on > draft-ram-siprec-metadata-04 >>>>>>>>>> >>>>>>>>>> John, >>>>>>>>>> >>>>>>>>>> I agree with you that normal cases RS will remain at >>>>>>> least for the >>>>>>> >>>>>>>>>> duration of CS. However it is common to have use cases where >>>>>>>>> recording >>>>>>>>>> is done for first few mins of a CS and then stopped, >>>>>>>> re-started at a >>>>>>>>>> later point (e.g Recording of a company meeting where >>>>>>> you may want >>>>>>>> to >>>>>>>>>> record only portions of meeting). >>>>>>>>>> >>>>>>>>>> In any case, the point I like to high light here is, MS >>>>>>>> block could >>>>>>>>> be >>>>>>>>>> common across RS and even across CS[ due to consult >>>>>>>> transfer e.t.c]. >>>>>>>>>> These use cases indicate the need to have a unique ID >>>>>>> for MS block >>>>>>> >>>>>>>>>> (similar to the UUID that we have defined in format) as >>>>>>> we cannot >>>>>>>>>> depend on neither CS ID or RS ID. >>>>>>>>> [JRE] I am having a hard time understanding the concept >>>>>>> of a single >>>>>>>>> Media Stream that survives across multiple CSs. For >>>>>>> example, in the >>>>>>>>> case of transfer, I would have thought new Media >>>>>> Streams would be >>>>>>>>> created. >>>>>>>> >>>>>>>> [RAM] >>>>>>>> Here is my thoughts. >>>>>>>> 1) There can be multiple RS per CS >>>>>>>> RS1 --- CS1--MS1 >>>>>>>> RS2----CS1--MS1 >>>>>>>> Examples are partial recording of CS (like recording parts >>>>>>> of meeting, >>>>>>> >>>>>>>> redundant recording where there are multiple SRCs recording >>>>>>> the same >>>>>>>> CS) >>>>>>> [JRE] Agreed. In this case MS1 is local to CS1. >>>>>>> >>>>>>>> >>>>>>>> 2) There can be same Media Stream across multiple CS. >>>>>>>> RS1--- CS1--- MS1 >>>>>>>> RS2--CS2--MS1 >>>>>>>> Examples are Multicast MoH played to multiple end points who > are >>>>>>>> potentially part of disjoint CSs where each CS is recorded >>>>>>> as part of >>>>>>>> separate RS. >>>>>>>> >>>>>>>> Of course the above is arguable where the stream is same or >>>>>>> different. >>>>>>>> My view is since the UA (that supplies the Multicast MoH) and >> its >>>>>>>> media are same across all CS, I think it can be represented >>>>>>> as same MS >>>>>>> >>>>>>>> block. >>>>>>> [JRE] I would argue these are different MSs. I agree that a >> medium >>>>>>> such as music on hold might be sent, in synch, to multiple >>>>>>> participants in multiple CSs. In that particular situation >>>>>> there might >>>>>> >>>>>>> be some efficiency saving by calling it the same MS. >>>>>> However, I would >>>>>>> suggest (although this is not my field of expertise) it would >> make >>>>>>> life a lot harder for the SRS and its database. I would >>>>>> have expected >>>>>>> to want to record a complete CS (all its participants and media >>>>>>> streams) as a complete recording, which could be deleted, >>>>>> copied, and >>>>>> >>>>>>> so on without having to go looking for other objects that >> complete >>>>>>> that recording and are shared with other recordings. For >>>>>> example, if >>>>>>> you delete a recording, you would want to delete all its >>>>>> MSs, but not >>>>>>> those used by other recordings, although you would need a > garbage >>>>>>> collection mechanism to delete an MS recording when it is no >>> longer >>>>>>> used by any CS recordings. Rather ugly. Making a MS local to a > CS >>>>>>> would simplify all this. >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> However it is still possible to treat each as separate >>>>>>> stream in the >>>>>>>> model, in which case the information that it is the same MS >>>>>>> played by >>>>>>>> a UA to different CS will be lost. I don't know if there is an >>>>>>>> interest to capture this level of detail and if it is of >>>>>> any use to >>>>>>>> SRS. >>>>>>> [JRE] I assume what you are saying here is not that >>>>>> information will >>>>>>> be lost, but that you will be unable to tell, without doing a >>>>>>> comparison, whether two different MSs played to participants in >>> two >>>>>>> different CSs are identical or not for the particular time >>>>>> span that >>>>>>> is common. I don't see where such a requirement would come from. >>>>>>> >>>>>>> John (as individual) >>>>>>> >>>>>>> >>>>>> >>>>> >>>> _______________________________________________ >>>> 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. >>> >>> > > > ---------------------------------------------------------------------- > --------------------------------------------- > CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain co= nfidential and proprietary information of Alcatel-Lucent and/or its affilia= ted entities. Access by the intended recipient only is authorized. Any liab= ility arising from any party acting, or refraining from acting, on any info= rmation contained in this e-mail is hereby excluded. If you are not the int= ended recipient, please notify the sender immediately, destroy the original= transmission and its attachments and do not disclose the contents to any o= ther person, use it for any purpose, or store or copy the information in an= y medium. Copyright in this e-mail and any attachments belongs to Alcatel-L= ucent and/or its affiliated entities. > > _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From partr@cisco.com Thu Apr 28 23:24:08 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 AD482E0695 for ; Thu, 28 Apr 2011 23:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.964 X-Spam-Level: X-Spam-Status: No, score=-9.964 tagged_above=-999 required=5 tests=[AWL=0.635, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 z0ZupfIFKyi1 for ; Thu, 28 Apr 2011 23:24:04 -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 D2B79E068C for ; Thu, 28 Apr 2011 23:24:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=5586; q=dns/txt; s=iport; t=1304058244; x=1305267844; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=+UF2/eUKpIMBEtR3Oynrh1DFRrOZ23zTZO5Idd6iVqg=; b=V38Pem1s3W78N2+GW7saV7pQ6mf6ys2bHEYTKB2Ba8DDazoZURorOV9a J8XIEixK03f+lgCaapu4fLOFOT6RWHm9yUrAYi0GvfcUV/3Vo1qDYp+6l 2qCbaYnER5MrznA8EHOTBEijqgqw+1WMjYm+4wOFz003/2HA99TeeejM4 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMBACZZuk2Q/khLgWdsb2JhbACYCo14FAEBFiYliHGeYp0CgwCCegSGCox6igE X-IronPort-AV: E=Sophos;i="4.64,285,1301875200"; d="scan'208";a="85897306" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 29 Apr 2011 06:24:02 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3T6Nnrq027692; Fri, 29 Apr 2011 06:24:02 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 29 Apr 2011 11:54:01 +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: Fri, 29 Apr 2011 11:54:00 +0530 Message-ID: In-Reply-To: <4DB820DA.1080200@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] RS to CS relationship as an attribute inRecording block Thread-Index: AcwE4x8YD7/cu+lQR+eb7/Ocm6GbsgBSQS2Q References: <4DB58BC7.5090603@cisco.com> <4DB820DA.1080200@cisco.com> From: "Parthasarathi R (partr)" To: "Paul Kyzivat (pkyzivat)" , "Elwell, John" X-OriginalArrivalTime: 29 Apr 2011 06:24:01.0417 (UTC) FILETIME=[07B47790:01CC0636] Cc: siprec@ietf.org Subject: Re: [siprec] RS to CS relationship as an attribute inRecording block X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 29 Apr 2011 06:24:08 -0000 John, Please clarify whether you propose to use RS dialog id as "recording" element unique id for the session. I had the same impression and mentioned at http://www.ietf.org/mail-archive/web/siprec/current/msg01751.html. From the metadata XML format perspective, "recording" element unique id will be defined by its application which is nothing but SIP (RS dialog-id). "recording" Unique-id is created after the dialog is established with SRS for "to-tag" portion of dialog-id. Even in case multiple SRC to single SRS, RS dialog-id is unique. "recording" element does not require any id in Metadata XML because only one instance of "recording" element per RS.=20 In the same line, Please let me know your opinion of "recording" element start/stop time which shall be derived from "Date" header in INVITE & BYE of RS SIP dialog. The intention is to use some of the metadata information from RS dialog rather than duplicating in XML. Having said that, I understand Paul point of view for having URN UUID within XML scope. There is no dependency on current URN UUID from SRS side. =20 Thanks Partha -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat (pkyzivat) Sent: Wednesday, April 27, 2011 7:28 PM To: Elwell, John Cc: siprec@ietf.org Subject: Re: [siprec] RS to CS relationship as an attribute inRecording block On 4/27/2011 4:00 AM, Elwell, John wrote: > I agree with Paul. > > Also, it is not at all clear to me why we need any unique identification for the RS - doesn't the SIP dialog identifier achieve this? The RS is only a vehicle for delivering one or more recordings (media and metadata) to the SRS, and once the delivered information is stored for future playback, the delivery mechanism, i.e., the RS identity, is no longer relevant. I don't think we *need* explicit metadata for the RS. But I think the SRS will want to keep track of where it got the various pieces of data and metadata it receives and records. It could capture basic info from the SIP dialog for that purpose. But it might be useful for the SRC to be able to transmit additional data about itself and its reason for establishing the RS. Perhaps that is all "extension data", but I think its useful to have some mechanism in place to transmit it. Thanks, Paul > However, I have a feeling we have been round this loop before, so apologies if we came to a resolution. > > John (as individual) > >> -----Original Message----- >> From: siprec-bounces@ietf.org >> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: 25 April 2011 15:57 >> To: siprec@ietf.org >> Subject: Re: [siprec] RS to CS relationship as an attribute in=20 >> Recording block >> >> Given all the combinations you cite, I'm inclined to simply plan to=20 >> accommodate many RS to many CS in all cases. >> >> Having to specify which type is to be used when establishing the RS=20 >> seems like a problem waiting to happen. I think the SRC won't always=20 >> know, or worse - it will think it knows but turn out to be wrong. >> >> Thanks, >> Paul >> >> On 4/25/2011 10:35 AM, Parthasarathi R (partr) wrote: >>> Hi all, >>> The context for this attribute is whether globally unique >> id is required >>> in each metadata block or whether it is required only in some of the >>> block only. One of the compelling reason for globally unique id is=20 >>> because of the complex relationship between RS and CS which is not=20 >>> currently passed from SRC to SRS. I'm trying to find >> whether passing the >>> information will reduce the complexity of globally unique >> id in some blocks. >>> In case RS to CS relationship between SRC& SRS, there is a >> possibility >>> of three types and they are as follows: >>> 1) One RS to one CS: Simple mechanism and every CS is >> directly mapped to >>> RS. Here, RS needs to be global unique id whereas those block is not >>> required to be global. >>> 2) One RS to many CS: >>> Usecases are as follows: >>> a) Persistent recording >>> b) Recording with single CSG >>> Here as well, RS needs to be global unique id whereas those >> block is not >>> required to be global. >>> 3) Many RS to one CS: >>> Use case are as follows: >>> a) start/stop recording session during single CS. >>> Here. RS needs global unique id as well as CS needs global >> unique id. >>> Please note that this mechanism will not co-exist with >> above two mechanism. >>> The attribute name is recording_type wherein the value of >> the attributes >>> will be >>> a) one_rs_one_cs >>> b) one_rs_many_cs >>> c) many_rs_one_cs >>> By knowing this attribute, SRS will be able to manage >> unique-id and its >>> scope as SRS aware of SRC mechanism. Say in case of >> one_rs_many_cs SRC, >>> media stream (MS) will never exceed RS wherein in case of=20 >>> many_rs_one_cs, MS will never exceed CS and in both scenario, MS is=20 >>> local to RS or CS. Please let me know whether it is worth >> to add this >>> attribute in Metadata model. >>> Thanks >>> Partha >>> >>> >>> >>> _______________________________________________ >>> siprec mailing list >>> siprec@ietf.org >>> https://www.ietf.org/mailman/listinfo/siprec >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >> _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From eckelcu@cisco.com Fri Apr 29 08:47: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 27C84E06CC for ; Fri, 29 Apr 2011 08:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.428 X-Spam-Level: X-Spam-Status: No, score=-10.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 JjxIwAKDZEhg for ; Fri, 29 Apr 2011 08:47:47 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 0EFC7E06A7 for ; Fri, 29 Apr 2011 08:47:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=7029; q=dns/txt; s=iport; t=1304092067; x=1305301667; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=r0jnn3a7B90m8VBZ5mtUXoqOsbZGiDIO628cE5LtRA8=; b=Q2Lj8YR3NSFUG6w0ZIYFtYlyrhxWc/InO/cCX0i3rN90N8kS3iZysJi4 JAc71X//mm4oKHu2AuSWWWbfnF/OOyyJTyVCS/aVVq99TufUi6aWc+EI7 7VChYw7DnIBu7UrMGgQA/YacDwkvA0sHdsRU/Y1jZ2a8V2c7xcy9ow1qd I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIBACbduk2rRDoJ/2dsb2JhbACYC44Ad4hxniiceYMDAYJ6BIYNjHuKGhw X-IronPort-AV: E=Sophos;i="4.64,288,1301875200"; d="scan'208";a="347280965" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-2.cisco.com with ESMTP; 29 Apr 2011 15:47:45 +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 p3TFljaQ030842; Fri, 29 Apr 2011 15:47: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); Fri, 29 Apr 2011 08:47: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: Fri, 29 Apr 2011 08:47:43 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] RS to CS relationship as an attribute inRecording block Thread-Index: AcwE4x8YD7/cu+lQR+eb7/Ocm6GbsgBSQS2QABW0nfA= References: <4DB58BC7.5090603@cisco.com><4DB820DA.1080200@cisco.com> From: "Charles Eckel (eckelcu)" To: "Parthasarathi R (partr)" , "Paul Kyzivat (pkyzivat)" , "Elwell, John" X-OriginalArrivalTime: 29 Apr 2011 15:47:45.0440 (UTC) FILETIME=[C864CA00:01CC0684] Cc: siprec@ietf.org Subject: Re: [siprec] RS to CS relationship as an attribute inRecording block X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 29 Apr 2011 15:47:52 -0000 Hi Partha, Use of the RS dialog-id seems ok to me. However, if I understood John's point, he was suggesting a unique id within the metadata to identify the RS is not required. This is different than requiring a unique ID to identify the recording. I think the unique ID for the recording should not be required to be the RS dialog-id. Doing so would preclude things such as having the SRC re-establish a new RS the SRS for the purpose of continuing a recording.=20 Regarding use of the Date header, one problem is that Date is optional, so you would need SIPREC to make it mandatory for SRC and SRS, else they may not include it. Cheers, Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi R (partr) > Sent: Thursday, April 28, 2011 11:24 PM > To: Paul Kyzivat (pkyzivat); Elwell, John > Cc: siprec@ietf.org > Subject: Re: [siprec] RS to CS relationship as an attribute inRecording block >=20 > John, >=20 > Please clarify whether you propose to use RS dialog id as "recording" > element unique id for the session. I had the same impression and > mentioned at > http://www.ietf.org/mail-archive/web/siprec/current/msg01751.html. From > the metadata XML format perspective, "recording" element unique id will > be defined by its application which is nothing but SIP (RS dialog-id). > "recording" Unique-id is created after the dialog is established with > SRS for "to-tag" portion of dialog-id. Even in case multiple SRC to > single SRS, RS dialog-id is unique. > "recording" element does not require any id in Metadata XML because only > one instance of "recording" element per RS. >=20 > In the same line, Please let me know your opinion of "recording" element > start/stop time which shall be derived from "Date" header in INVITE & > BYE of RS SIP dialog. The intention is to use some of the metadata > information from RS dialog rather than duplicating in XML. >=20 > Having said that, I understand Paul point of view for having URN UUID > within XML scope. There is no dependency on current URN UUID from SRS > side. >=20 > Thanks > Partha >=20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf > Of Paul Kyzivat (pkyzivat) > Sent: Wednesday, April 27, 2011 7:28 PM > To: Elwell, John > Cc: siprec@ietf.org > Subject: Re: [siprec] RS to CS relationship as an attribute inRecording > block >=20 >=20 >=20 > On 4/27/2011 4:00 AM, Elwell, John wrote: > > I agree with Paul. > > > > Also, it is not at all clear to me why we need any unique > identification for the RS - doesn't the SIP dialog identifier achieve > this? The RS is only a vehicle for delivering one or more recordings > (media and metadata) to the SRS, and once the delivered information is > stored for future playback, the delivery mechanism, i.e., the RS > identity, is no longer relevant. >=20 > I don't think we *need* explicit metadata for the RS. > But I think the SRS will want to keep track of where it got the various > pieces of data and metadata it receives and records. It could capture > basic info from the SIP dialog for that purpose. But it might be useful > for the SRC to be able to transmit additional data about itself and its > reason for establishing the RS. Perhaps that is all "extension data", > but I think its useful to have some mechanism in place to transmit it. >=20 > Thanks, > Paul >=20 > > However, I have a feeling we have been round this loop before, so > apologies if we came to a resolution. > > > > John (as individual) > > > >> -----Original Message----- > >> From: siprec-bounces@ietf.org > >> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > >> Sent: 25 April 2011 15:57 > >> To: siprec@ietf.org > >> Subject: Re: [siprec] RS to CS relationship as an attribute in > >> Recording block > >> > >> Given all the combinations you cite, I'm inclined to simply plan to > >> accommodate many RS to many CS in all cases. > >> > >> Having to specify which type is to be used when establishing the RS > >> seems like a problem waiting to happen. I think the SRC won't always > >> know, or worse - it will think it knows but turn out to be wrong. > >> > >> Thanks, > >> Paul > >> > >> On 4/25/2011 10:35 AM, Parthasarathi R (partr) wrote: > >>> Hi all, > >>> The context for this attribute is whether globally unique > >> id is required > >>> in each metadata block or whether it is required only in some of the >=20 > >>> block only. One of the compelling reason for globally unique id is > >>> because of the complex relationship between RS and CS which is not > >>> currently passed from SRC to SRS. I'm trying to find > >> whether passing the > >>> information will reduce the complexity of globally unique > >> id in some blocks. > >>> In case RS to CS relationship between SRC& SRS, there is a > >> possibility > >>> of three types and they are as follows: > >>> 1) One RS to one CS: Simple mechanism and every CS is > >> directly mapped to > >>> RS. Here, RS needs to be global unique id whereas those block is not >=20 > >>> required to be global. > >>> 2) One RS to many CS: > >>> Usecases are as follows: > >>> a) Persistent recording > >>> b) Recording with single CSG > >>> Here as well, RS needs to be global unique id whereas those > >> block is not > >>> required to be global. > >>> 3) Many RS to one CS: > >>> Use case are as follows: > >>> a) start/stop recording session during single CS. > >>> Here. RS needs global unique id as well as CS needs global > >> unique id. > >>> Please note that this mechanism will not co-exist with > >> above two mechanism. > >>> The attribute name is recording_type wherein the value of > >> the attributes > >>> will be > >>> a) one_rs_one_cs > >>> b) one_rs_many_cs > >>> c) many_rs_one_cs > >>> By knowing this attribute, SRS will be able to manage > >> unique-id and its > >>> scope as SRS aware of SRC mechanism. Say in case of > >> one_rs_many_cs SRC, > >>> media stream (MS) will never exceed RS wherein in case of > >>> many_rs_one_cs, MS will never exceed CS and in both scenario, MS is > >>> local to RS or CS. Please let me know whether it is worth > >> to add this > >>> attribute in Metadata model. > >>> Thanks > >>> Partha > >>> > >>> > >>> > >>> _______________________________________________ > >>> siprec mailing list > >>> siprec@ietf.org > >>> https://www.ietf.org/mailman/listinfo/siprec > >> _______________________________________________ > >> siprec mailing list > >> siprec@ietf.org > >> https://www.ietf.org/mailman/listinfo/siprec > >> > _______________________________________________ > siprec mailing 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@cisco.com Fri Apr 29 17:37:57 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 398CFE06AD for ; Fri, 29 Apr 2011 17:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.487 X-Spam-Level: X-Spam-Status: No, score=-110.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 faBWd19BU5Lu for ; Fri, 29 Apr 2011 17:37:56 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 267B3E0677 for ; Fri, 29 Apr 2011 17:37:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=7932; q=dns/txt; s=iport; t=1304123876; x=1305333476; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=u9Pdtty7xmO14cJ+r3b9nbb6RX9ZFgIQUrAXXUKoveo=; b=Y4qJNUYkHyUenxZenK/k69Mql8FSHuu7Ihh5/KmSnS8uOO1sduCrIdru FDh6fv41LeP8c6Wgxj/mVXw2FaAa/JFFKpsjWcgiPcFYDRO1tmRf68uLh Fz9yPj3+gWkJctXewDx3JOpw5EV3+cB0Rkz1I2/4WkENTFihAve26wwUD c=; X-IronPort-AV: E=Sophos;i="4.64,291,1301875200"; d="scan'208";a="347577646" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-2.cisco.com with ESMTP; 30 Apr 2011 00:37:56 +0000 Received: from [161.44.174.124] (dhcp-161-44-174-124.cisco.com [161.44.174.124]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3U0btE4008987; Sat, 30 Apr 2011 00:37:55 GMT Message-ID: <4DBB59E2.9040200@cisco.com> Date: Fri, 29 Apr 2011 20:37:54 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Charles Eckel (eckelcu)" References: <4DB58BC7.5090603@cisco.com><4DB820DA.1080200@cisco.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] RS to CS relationship as an attribute inRecording block X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 30 Apr 2011 00:37:57 -0000 On 4/29/2011 11:47 AM, Charles Eckel (eckelcu) wrote: > Hi Partha, > > Use of the RS dialog-id seems ok to me. However, if I understood John's > point, he was suggesting a unique id within the metadata to identify the > RS is not required. This is different than requiring a unique ID to > identify the recording. I think the unique ID for the recording should > not be required to be the RS dialog-id. Doing so would preclude things > such as having the SRC re-establish a new RS the SRS for the purpose of > continuing a recording. Yes, I agree. A "recording" is really just all the data and metadata accumulated about a CS or CSG. That data has been received through one *or more* RSs. Each RS has some metadata of its own (such as who the SRC was.) To track that, when the SRS receives message from the SRC, it should associate each independent hunk of metadata in that message with its info about the RS. Then for example, the elements in the time series of updates to each CS, MS, etc. will each link to the RS that delivered it. An SRS that wanted to be lazy might not bother to keep all that. Thanks, Paul > Regarding use of the Date header, one problem is that Date is optional, > so you would need SIPREC to make it mandatory for SRC and SRS, else they > may not include it. True. I guess we could either make its use mandatory with siprec, or else convey the data separately in the metadata. Thanks, Paul > Cheers, > Charles > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Parthasarathi R (partr) >> Sent: Thursday, April 28, 2011 11:24 PM >> To: Paul Kyzivat (pkyzivat); Elwell, John >> Cc: siprec@ietf.org >> Subject: Re: [siprec] RS to CS relationship as an attribute > inRecording block >> >> John, >> >> Please clarify whether you propose to use RS dialog id as "recording" >> element unique id for the session. I had the same impression and >> mentioned at >> http://www.ietf.org/mail-archive/web/siprec/current/msg01751.html. > From >> the metadata XML format perspective, "recording" element unique id > will >> be defined by its application which is nothing but SIP (RS dialog-id). >> "recording" Unique-id is created after the dialog is established with >> SRS for "to-tag" portion of dialog-id. Even in case multiple SRC to >> single SRS, RS dialog-id is unique. >> "recording" element does not require any id in Metadata XML because > only >> one instance of "recording" element per RS. >> >> In the same line, Please let me know your opinion of "recording" > element >> start/stop time which shall be derived from "Date" header in INVITE& >> BYE of RS SIP dialog. The intention is to use some of the metadata >> information from RS dialog rather than duplicating in XML. >> >> Having said that, I understand Paul point of view for having URN UUID >> within XML scope. There is no dependency on current URN UUID from SRS >> side. >> >> Thanks >> Partha >> >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf >> Of Paul Kyzivat (pkyzivat) >> Sent: Wednesday, April 27, 2011 7:28 PM >> To: Elwell, John >> Cc: siprec@ietf.org >> Subject: Re: [siprec] RS to CS relationship as an attribute > inRecording >> block >> >> >> >> On 4/27/2011 4:00 AM, Elwell, John wrote: >>> I agree with Paul. >>> >>> Also, it is not at all clear to me why we need any unique >> identification for the RS - doesn't the SIP dialog identifier achieve >> this? The RS is only a vehicle for delivering one or more recordings >> (media and metadata) to the SRS, and once the delivered information is >> stored for future playback, the delivery mechanism, i.e., the RS >> identity, is no longer relevant. >> >> I don't think we *need* explicit metadata for the RS. >> But I think the SRS will want to keep track of where it got the > various >> pieces of data and metadata it receives and records. It could capture >> basic info from the SIP dialog for that purpose. But it might be > useful >> for the SRC to be able to transmit additional data about itself and > its >> reason for establishing the RS. Perhaps that is all "extension data", >> but I think its useful to have some mechanism in place to transmit it. >> >> Thanks, >> Paul >> >>> However, I have a feeling we have been round this loop before, so >> apologies if we came to a resolution. >>> >>> John (as individual) >>> >>>> -----Original Message----- >>>> From: siprec-bounces@ietf.org >>>> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat >>>> Sent: 25 April 2011 15:57 >>>> To: siprec@ietf.org >>>> Subject: Re: [siprec] RS to CS relationship as an attribute in >>>> Recording block >>>> >>>> Given all the combinations you cite, I'm inclined to simply plan to >>>> accommodate many RS to many CS in all cases. >>>> >>>> Having to specify which type is to be used when establishing the RS >>>> seems like a problem waiting to happen. I think the SRC won't > always >>>> know, or worse - it will think it knows but turn out to be wrong. >>>> >>>> Thanks, >>>> Paul >>>> >>>> On 4/25/2011 10:35 AM, Parthasarathi R (partr) wrote: >>>>> Hi all, >>>>> The context for this attribute is whether globally unique >>>> id is required >>>>> in each metadata block or whether it is required only in some of > the >> >>>>> block only. One of the compelling reason for globally unique id is >>>>> because of the complex relationship between RS and CS which is not >>>>> currently passed from SRC to SRS. I'm trying to find >>>> whether passing the >>>>> information will reduce the complexity of globally unique >>>> id in some blocks. >>>>> In case RS to CS relationship between SRC& SRS, there is a >>>> possibility >>>>> of three types and they are as follows: >>>>> 1) One RS to one CS: Simple mechanism and every CS is >>>> directly mapped to >>>>> RS. Here, RS needs to be global unique id whereas those block is > not >> >>>>> required to be global. >>>>> 2) One RS to many CS: >>>>> Usecases are as follows: >>>>> a) Persistent recording >>>>> b) Recording with single CSG >>>>> Here as well, RS needs to be global unique id whereas those >>>> block is not >>>>> required to be global. >>>>> 3) Many RS to one CS: >>>>> Use case are as follows: >>>>> a) start/stop recording session during single CS. >>>>> Here. RS needs global unique id as well as CS needs global >>>> unique id. >>>>> Please note that this mechanism will not co-exist with >>>> above two mechanism. >>>>> The attribute name is recording_type wherein the value of >>>> the attributes >>>>> will be >>>>> a) one_rs_one_cs >>>>> b) one_rs_many_cs >>>>> c) many_rs_one_cs >>>>> By knowing this attribute, SRS will be able to manage >>>> unique-id and its >>>>> scope as SRS aware of SRC mechanism. Say in case of >>>> one_rs_many_cs SRC, >>>>> media stream (MS) will never exceed RS wherein in case of >>>>> many_rs_one_cs, MS will never exceed CS and in both scenario, MS > is >>>>> local to RS or CS. Please let me know whether it is worth >>>> to add this >>>>> attribute in Metadata model. >>>>> Thanks >>>>> Partha >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> siprec mailing list >>>>> siprec@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/siprec >>>> _______________________________________________ >>>> siprec mailing list >>>> siprec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/siprec >>>> >> _______________________________________________ >> siprec mailing 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 Sat Apr 30 03:12: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 C7D2AE06F3 for ; Sat, 30 Apr 2011 03:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.999 X-Spam-Level: X-Spam-Status: No, score=-104.999 tagged_above=-999 required=5 tests=[AWL=1.600, 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 hF1lUhv0EoF0 for ; Sat, 30 Apr 2011 03:11:59 -0700 (PDT) Received: from mail174.messagelabs.com (mail174.messagelabs.com [85.158.138.51]) by ietfa.amsl.com (Postfix) with SMTP id 1CF08E06CA for ; Sat, 30 Apr 2011 03:11:55 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-4.tower-174.messagelabs.com!1304158314!18412905!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 13757 invoked from network); 30 Apr 2011 10:11:54 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-4.tower-174.messagelabs.com with SMTP; 30 Apr 2011 10:11:54 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id E2E771EB83E3; Sat, 30 Apr 2011 12:11:54 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Sat, 30 Apr 2011 12:11:55 +0200 From: "Elwell, John" To: Paul Kyzivat , "Charles Eckel (eckelcu)" Date: Sat, 30 Apr 2011 12:11:55 +0200 Thread-Topic: [siprec] RS to CS relationship as an attribute inRecording block Thread-Index: AcwGztrLnXFeZgk1S0yQ9SbXcp9ZCAAT5NJg Message-ID: References: <4DB58BC7.5090603@cisco.com><4DB820DA.1080200@cisco.com> <4DBB59E2.9040200@cisco.com> In-Reply-To: <4DBB59E2.9040200@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 Cc: "siprec@ietf.org" Subject: Re: [siprec] RS to CS relationship as an attribute inRecording block X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 30 Apr 2011 10:12:00 -0000 I am confused, because this thread has suddenly started to talk about a "re= cording", whereas metadata-00 has an object called "Recording Session", whi= ch seems to imply it has a 1:1 relationship with the SIP dialog for the RS.= If people have a notion of a recording object that does not have a 1:1 rel= ationship with an RS, and therefore a single SIP dialog, I would suggest th= ey articulate why this would be needed, with a view to getting it into the = metadata model. John =20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: 30 April 2011 01:38 > To: Charles Eckel (eckelcu) > Cc: Parthasarathi R (partr); Elwell, John; siprec@ietf.org > Subject: Re: [siprec] RS to CS relationship as an attribute=20 > inRecording block >=20 >=20 >=20 > On 4/29/2011 11:47 AM, Charles Eckel (eckelcu) wrote: > > Hi Partha, > > > > Use of the RS dialog-id seems ok to me. However, if I=20 > understood John's > > point, he was suggesting a unique id within the metadata to=20 > identify the > > RS is not required. This is different than requiring a unique ID to > > identify the recording. I think the unique ID for the=20 > recording should > > not be required to be the RS dialog-id. Doing so would=20 > preclude things > > such as having the SRC re-establish a new RS the SRS for=20 > the purpose of > > continuing a recording. >=20 > Yes, I agree. >=20 > A "recording" is really just all the data and metadata=20 > accumulated about=20 > a CS or CSG. That data has been received through one *or=20 > more* RSs. Each=20 > RS has some metadata of its own (such as who the SRC was.) >=20 > To track that, when the SRS receives message from the SRC, it should=20 > associate each independent hunk of metadata in that message with its=20 > info about the RS. >=20 > Then for example, the elements in the time series of updates=20 > to each CS,=20 > MS, etc. will each link to the RS that delivered it. >=20 > An SRS that wanted to be lazy might not bother to keep all that. >=20 > Thanks, > Paul >=20 > > Regarding use of the Date header, one problem is that Date=20 > is optional, > > so you would need SIPREC to make it mandatory for SRC and=20 > SRS, else they > > may not include it. >=20 > True. I guess we could either make its use mandatory with siprec, or=20 > else convey the data separately in the metadata. >=20 > Thanks, > Paul >=20 > > Cheers, > > Charles > > > >> -----Original Message----- > >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Parthasarathi R (partr) > >> Sent: Thursday, April 28, 2011 11:24 PM > >> To: Paul Kyzivat (pkyzivat); Elwell, John > >> Cc: siprec@ietf.org > >> Subject: Re: [siprec] RS to CS relationship as an attribute > > inRecording block > >> > >> John, > >> > >> Please clarify whether you propose to use RS dialog id as=20 > "recording" > >> element unique id for the session. I had the same impression and > >> mentioned at > >> http://www.ietf.org/mail-archive/web/siprec/current/msg01751.html. > > From > >> the metadata XML format perspective, "recording" element unique id > > will > >> be defined by its application which is nothing but SIP (RS=20 > dialog-id). > >> "recording" Unique-id is created after the dialog is=20 > established with > >> SRS for "to-tag" portion of dialog-id. Even in case multiple SRC to > >> single SRS, RS dialog-id is unique. > >> "recording" element does not require any id in Metadata XML because > > only > >> one instance of "recording" element per RS. > >> > >> In the same line, Please let me know your opinion of "recording" > > element > >> start/stop time which shall be derived from "Date" header=20 > in INVITE& > >> BYE of RS SIP dialog. The intention is to use some of the metadata > >> information from RS dialog rather than duplicating in XML. > >> > >> Having said that, I understand Paul point of view for=20 > having URN UUID > >> within XML scope. There is no dependency on current URN=20 > UUID from SRS > >> side. > >> > >> Thanks > >> Partha > >> > >> -----Original Message----- > >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf > >> Of Paul Kyzivat (pkyzivat) > >> Sent: Wednesday, April 27, 2011 7:28 PM > >> To: Elwell, John > >> Cc: siprec@ietf.org > >> Subject: Re: [siprec] RS to CS relationship as an attribute > > inRecording > >> block > >> > >> > >> > >> On 4/27/2011 4:00 AM, Elwell, John wrote: > >>> I agree with Paul. > >>> > >>> Also, it is not at all clear to me why we need any unique > >> identification for the RS - doesn't the SIP dialog=20 > identifier achieve > >> this? The RS is only a vehicle for delivering one or more=20 > recordings > >> (media and metadata) to the SRS, and once the delivered=20 > information is > >> stored for future playback, the delivery mechanism, i.e., the RS > >> identity, is no longer relevant. > >> > >> I don't think we *need* explicit metadata for the RS. > >> But I think the SRS will want to keep track of where it got the > > various > >> pieces of data and metadata it receives and records. It=20 > could capture > >> basic info from the SIP dialog for that purpose. But it might be > > useful > >> for the SRC to be able to transmit additional data about itself and > > its > >> reason for establishing the RS. Perhaps that is all=20 > "extension data", > >> but I think its useful to have some mechanism in place to=20 > transmit it. > >> > >> Thanks, > >> Paul > >> > >>> However, I have a feeling we have been round this loop before, so > >> apologies if we came to a resolution. > >>> > >>> John (as individual) > >>> > >>>> -----Original Message----- > >>>> From: siprec-bounces@ietf.org > >>>> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > >>>> Sent: 25 April 2011 15:57 > >>>> To: siprec@ietf.org > >>>> Subject: Re: [siprec] RS to CS relationship as an attribute in > >>>> Recording block > >>>> > >>>> Given all the combinations you cite, I'm inclined to=20 > simply plan to > >>>> accommodate many RS to many CS in all cases. > >>>> > >>>> Having to specify which type is to be used when=20 > establishing the RS > >>>> seems like a problem waiting to happen. I think the SRC won't > > always > >>>> know, or worse - it will think it knows but turn out to be wrong. > >>>> > >>>> Thanks, > >>>> Paul > >>>> > >>>> On 4/25/2011 10:35 AM, Parthasarathi R (partr) wrote: > >>>>> Hi all, > >>>>> The context for this attribute is whether globally unique > >>>> id is required > >>>>> in each metadata block or whether it is required only in some of > > the > >> > >>>>> block only. One of the compelling reason for globally=20 > unique id is > >>>>> because of the complex relationship between RS and CS=20 > which is not > >>>>> currently passed from SRC to SRS. I'm trying to find > >>>> whether passing the > >>>>> information will reduce the complexity of globally unique > >>>> id in some blocks. > >>>>> In case RS to CS relationship between SRC& SRS, there is a > >>>> possibility > >>>>> of three types and they are as follows: > >>>>> 1) One RS to one CS: Simple mechanism and every CS is > >>>> directly mapped to > >>>>> RS. Here, RS needs to be global unique id whereas those block is > > not > >> > >>>>> required to be global. > >>>>> 2) One RS to many CS: > >>>>> Usecases are as follows: > >>>>> a) Persistent recording > >>>>> b) Recording with single CSG > >>>>> Here as well, RS needs to be global unique id whereas those > >>>> block is not > >>>>> required to be global. > >>>>> 3) Many RS to one CS: > >>>>> Use case are as follows: > >>>>> a) start/stop recording session during single CS. > >>>>> Here. RS needs global unique id as well as CS needs global > >>>> unique id. > >>>>> Please note that this mechanism will not co-exist with > >>>> above two mechanism. > >>>>> The attribute name is recording_type wherein the value of > >>>> the attributes > >>>>> will be > >>>>> a) one_rs_one_cs > >>>>> b) one_rs_many_cs > >>>>> c) many_rs_one_cs > >>>>> By knowing this attribute, SRS will be able to manage > >>>> unique-id and its > >>>>> scope as SRS aware of SRC mechanism. Say in case of > >>>> one_rs_many_cs SRC, > >>>>> media stream (MS) will never exceed RS wherein in case of > >>>>> many_rs_one_cs, MS will never exceed CS and in both scenario, MS > > is > >>>>> local to RS or CS. Please let me know whether it is worth > >>>> to add this > >>>>> attribute in Metadata model. > >>>>> Thanks > >>>>> Partha > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> siprec mailing list > >>>>> siprec@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/siprec > >>>> _______________________________________________ > >>>> siprec mailing list > >>>> siprec@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/siprec > >>>> > >> _______________________________________________ > >> siprec mailing list > >> siprec@ietf.org > >> https://www.ietf.org/mailman/listinfo/siprec > >> _______________________________________________ > >> siprec mailing list > >> siprec@ietf.org > >> https://www.ietf.org/mailman/listinfo/siprec > > > =