From Henry.Lum@alcatel-lucent.com Sun May 1 20:09: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 8A798E06B4 for ; Sun, 1 May 2011 20:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.738 X-Spam-Level: X-Spam-Status: No, score=-5.738 tagged_above=-999 required=5 tests=[AWL=0.860, 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 iHqmPxtVCCFN for ; Sun, 1 May 2011 20:09:11 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 03E5FE062A for ; Sun, 1 May 2011 20:09:10 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p42399XD020877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 1 May 2011 22:09:09 -0500 (CDT) Received: from relay-out2.dc (relay-out2.dc.genesyslab.com [172.22.68.188]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p423977T013786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 1 May 2011 22:09:09 -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 p42396i7028355 for ; Sun, 1 May 2011 20:09:06 -0700 (PDT) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.93]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 1 May 2011 20:09:06 -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_01CC0876.4BDF482C" Date: Sun, 1 May 2011 20:09:01 -0700 Message-ID: <059AF07365DC474393A19A3AF187DF7407028E4B@NAHALD.us.int.genesyslab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: summary of changes for draft-portman-siprec-protocol-04 Thread-Index: AcwIaR0YuGqr5XvNSMqltXB+NekCpQ== From: "Henry Lum" To: X-OriginalArrivalTime: 02 May 2011 03:09:06.0057 (UTC) FILETIME=[4BF76790:01CC0876] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: [siprec] summary of changes for draft-portman-siprec-protocol-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: Mon, 02 May 2011 03:09:12 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC0876.4BDF482C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I want to summarize the list of changes we are planning to include in the next revision of the document: =20 - Remove use of INFO - Both INVITE or UPDATE can be used for metadata transport through content-disposition - Recording indication is placed at SDP media level - Recording awareness is indicated at SIP level with options; feature tag was also considered - Recording preference is placed at SDP media level - RTP model discussion and time synchronization; so far we seem to agree to handle different RTP models rather than requiring a single model. There are 3 models we have identified so far: o RTP mixer - SRC mixes media streams and can directly synchronize timestamps with metadata and also generate RTCP o RTP translator - Media streams are simply forwarded to the SRS by the SRC. SRC is only capable to indicating start/stop times to the SRS in metadata. o RTP endpoint (is that the right term?) - SRC is neither a mixer nor translator, but is capable of rewriting RTP and RTCP in order to synchronize on the timestamps with metadata. =20 Regards, Henry =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_01CC0876.4BDF482C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I wa= nt to summarize the list of changes we are planning to include in the nex= t revision of the document:

 = ;

= -    &nb= sp;     Remove use of INFO

-    &n= bsp;     Both INVITE or UPDAT= E can be used for metadata transport through content-disposition

-     &n= bsp;    Recording indication is pl= aced at SDP media level

-&= nbsp;         Recording awareness is indicated at SIP level with options; feature = tag was also considered

-&= nbsp;         Recording preference is placed at SDP media level

-       =    RTP model discussion and time synchr= onization; so far we seem to agree to handle different RTP models rather = than requiring a single model. There are 3 models we have identified so f= ar:

o   RTP mixer – SRC mixes media streams and can directly sy= nchronize timestamps with metadata and also generate RTCP

<= p class=3DMsoListParagraph style=3D'margin-left:72.0pt;text-indent:-18.0p= t;mso-list:l0 level2 lfo1'>o   RTP tra= nslator – Media streams are simply forwarded to the SRS by the SRC.= SRC is only capable to indicating start/stop times to the SRS in metadat= a.

o   RTP endpoint (is that the right term?) – SRC is neither = a mixer nor translator, but is capable of rewriting RTP and RTCP in order= to synchronize on the timestamps with metadata.

 

Regards,

Henry

 


CONFIDENTIALITY NOTICE: This e-mail and any files attached= may contain confidential and proprietary information of Alcatel-Lucent a= nd/or its affiliated entities. Access by the intended recipient only is a= uthorized. Any liability arising from any party acting, or refraining fro= m acting, on any information contained in this e-mail is hereby excluded.= If you are not the intended recipient, please notify the sender immediat= ely, destroy the original transmission and its attachments and do not dis= close 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 a= ttachments belongs to Alcatel-Lucent and/or its affiliated entities. ------_=_NextPart_001_01CC0876.4BDF482C-- From eckelcu@cisco.com Mon May 2 06:33:49 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 95BDBE067C for ; Mon, 2 May 2011 06:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.439 X-Spam-Level: X-Spam-Status: No, score=-10.439 tagged_above=-999 required=5 tests=[AWL=0.160, 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 qnYeQYPQDPce for ; Mon, 2 May 2011 06:33:48 -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 804BBE0678 for ; Mon, 2 May 2011 06:33:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=10778; q=dns/txt; s=iport; t=1304343228; x=1305552828; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=qmfZ6JxZqFVAJ52I4S4z7A1UBA1UPGsQxsqiTAx6S/Y=; b=jrQW3oQ5WwmecPiQoPEkg/XOa0TRXw7xKuCxOmFU9PFkCr1x6YSWGrcU hBcmTrffUzG+n2N78YrRiMwPZHwvvvQ4H4F1I2DRrLH3aC9YAZouYp07z +1SDfHdcaDd+9p6Gdbufva2aM65SJAZEt4cjn851KDysaZmI3E4YgwjCG A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlABAKyxvk2rRDoJ/2dsb2JhbACYFI4Id6Q7m2uDBQGCegSGDo0NiiAc X-IronPort-AV: E=Sophos;i="4.64,302,1301875200"; d="scan'208";a="440073589" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-1.cisco.com with ESMTP; 02 May 2011 13:33:47 +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 p42DXlwW001839; Mon, 2 May 2011 13:33:47 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, 2 May 2011 06:33:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 2 May 2011 06:33:46 -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: AcwGztrLnXFeZgk1S0yQ9SbXcp9ZCAAT5NJgAGtWU+A= References: <4DB58BC7.5090603@cisco.com><4DB820DA.1080200@cisco.com> <4DBB59E2.9040200@cisco.com> From: "Charles Eckel (eckelcu)" To: "Elwell, John" , "Paul Kyzivat (pkyzivat)" X-OriginalArrivalTime: 02 May 2011 13:33:48.0127 (UTC) FILETIME=[910566F0:01CC08CD] 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: Mon, 02 May 2011 13:33:49 -0000 Hi John, Having a recording exist outside of the RS provides, among other things, a way for a SRC to establish a new RS to continue a recording in the event something goes wrong with initial RS. It also facilitates having multiple SRCs participate in the same recording, which we agreed was out of scope, but is at least possible if a recording exists outside of an RS. I suppose the argument could be made this is not really necessary. Rather, one could, outside of the scope of SIPREC, decide to associate multiple RSs in various ways, including stitching them together for the purpose of failover or distributed recordings. Is that what you have in mind? Cheers, Charles > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Saturday, April 30, 2011 3:12 AM > To: Paul Kyzivat (pkyzivat); Charles Eckel (eckelcu) > Cc: Parthasarathi R (partr); siprec@ietf.org > Subject: RE: [siprec] RS to CS relationship as an attribute inRecording block >=20 > I am confused, because this thread has suddenly started to talk about a "recording", whereas metadata- > 00 has an object called "Recording Session", which 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 > relationship with an RS, and therefore a single SIP dialog, I would suggest they articulate why this > would be needed, with a view to getting it into the metadata model. >=20 > John >=20 >=20 > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > 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 > > inRecording block > > > > > > > > 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 partr@cisco.com Mon May 2 11:22:19 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9525AE06F6 for ; Mon, 2 May 2011 11:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.022 X-Spam-Level: X-Spam-Status: No, score=-10.022 tagged_above=-999 required=5 tests=[AWL=0.577, 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 fv2SyZ+kDVyd for ; Mon, 2 May 2011 11:22:18 -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 DABEEE0678 for ; Mon, 2 May 2011 11:22:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=4044; q=dns/txt; s=iport; t=1304360538; x=1305570138; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=5iVfJhPME8YOEAdHuU8XCnZlzhdNud3WpZ0HC/bQwmM=; b=dHBUDuxrEgu/HDFXGlBEWF+PrOVu7A+OH9lHAlM9qNBGt9wBu6Gj4Ep5 +A7fIskE1bBvIXWNc5+9z9JAQbzmuyfOPi0SzRULplMseTbby9/NSz90T 1NoGJtvvJQzk8ce8UhGUw9WWBo6nhlfCsZFW6TS7YNGNiVGbuwHGoAQI/ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At4AAK71vk2Q/khRgWdsb2JhbACYFY4KFAEBFiYlpS+cFoYABIYMjQ+KCA X-IronPort-AV: E=Sophos;i="4.64,303,1301875200"; d="scan'208";a="28297595" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 02 May 2011 18:22:17 +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 p42IMGKP009148 for ; Mon, 2 May 2011 18:22:16 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, 2 May 2011 23:52: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: Mon, 2 May 2011 23:52:14 +0530 Message-ID: In-Reply-To: <20110413140001.12509.2089.idtracker@ietfc.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] I-D Action:draft-ietf-siprec-architecture-02.txt Thread-Index: Acv54yOePwZLBlTgQPChIkDA4jWhawPDzBjg References: <20110413140001.12509.2089.idtracker@ietfc.amsl.com> From: "Parthasarathi R (partr)" To: X-OriginalArrivalTime: 02 May 2011 18:22:15.0524 (UTC) FILETIME=[DD089A40:01CC08F5] Subject: Re: [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: Mon, 02 May 2011 18:22:19 -0000 As part of the discussion about Metadata and RTP model with lot of folks, I realized that it is better to show "UA instance" which is associated with SRC to create RS as a separate instance. Fig 4 in the draft shall be updated as=20 Session Recording Server (SRS) +----------+ (Recording Session) | | +-----------SIP------------------------->| UA-A | | | (SRS) | | +----------+ | Session Recording Client (SRC) | +----------------------------------------+ | | +-----------+ | | | | Session | +------------+ | | | | Recording | | | | | +---------+ | | UA | | Media | | <--RTP--+ | | | +-----------+ | | | | | | ^ | | | | | | | | | | | | | V | | | | | | +-----------+ | Server | | | UA-B | | | MediaCtrl |MEDIACTRL | |<-----RTP------>| | | |Application|<-------->| | | +---------+ | | Server | +------------+ | ^ | +-----------+ | | +--------^-------------------------------+ | | | +-----------------------SIP-------------------------+ (Communication Session) Figure 4: Example of Session Recording Client using MEDIACTRL Here in the above figure, session recording UA is a separate UA instance apart from CS creating UA (Mediactrl application server) instance. Cooridination between Session Recording UA and Mediactrl application server is outside the scope of SIPREC. The same logical figure shall be extended to other SRC architecture figure by which the importance of SIP based RS UA with non-sip CS is clear. Please let me know opinion on the same. Thanks Partha =20 -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Wednesday, April 13, 2011 7:30 PM To: i-d-announce@ietf.org Cc: siprec@ietf.org Subject: [siprec] I-D Action:draft-ietf-siprec-architecture-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP Recording Working Group of the IETF. Title : An Architecture for Media Recording using the Session Initiation Protocol Author(s) : 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.tx t 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. From john.elwell@siemens-enterprise.com Mon May 2 23:50:55 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63F67E0768 for ; Mon, 2 May 2011 23:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.026 X-Spam-Level: X-Spam-Status: No, score=-105.026 tagged_above=-999 required=5 tests=[AWL=1.573, 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 2mw8isGFgB3r for ; Mon, 2 May 2011 23:50:54 -0700 (PDT) Received: from mail21.messagelabs.com (mail21.messagelabs.com [85.158.143.35]) by ietfa.amsl.com (Postfix) with SMTP id 2BEABE06E1 for ; Mon, 2 May 2011 23:50:54 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-6.tower-21.messagelabs.com!1304405466!22842113!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 25398 invoked from network); 3 May 2011 06:51:06 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-6.tower-21.messagelabs.com with SMTP; 3 May 2011 06:51:06 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 30DDA1EB83EE for ; Tue, 3 May 2011 08:50:52 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 3 May 2011 08:50:52 +0200 From: "Elwell, John" To: "siprec@ietf.org" Date: Tue, 3 May 2011 08:50:50 +0200 Thread-Topic: Preparation for interim call 2011-05-09 Thread-Index: AcwJXnC5Zbqiae7nQgO+46NpELXgTw== 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] Preparation for interim call 2011-05-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, 03 May 2011 06:50:55 -0000 Webex / audio details are available here: http://kenrehor.com/ietf/siprec/IETF80.1/ The agenda and slides will also appear there. At present I plan to split the agenda as follows: Architecture: 15 minutes (Andy) Metadata model: 40 minutes (Ram/Partha) Metadata format: 40 minutes (Ram/Partha) Protocol: 20 minutes (Henry) Please let me have any change requests. Also please let me have your slides by Friday latest. John = From john.elwell@siemens-enterprise.com Tue May 3 09:38: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 43E22E088D for ; Tue, 3 May 2011 09:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.052 X-Spam-Level: X-Spam-Status: No, score=-105.052 tagged_above=-999 required=5 tests=[AWL=1.547, 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 a4NGKYFSH4In for ; Tue, 3 May 2011 09:38:54 -0700 (PDT) Received: from mail182.messagelabs.com (mail182.messagelabs.com [85.158.139.83]) by ietfa.amsl.com (Postfix) with SMTP id 72646E0889 for ; Tue, 3 May 2011 09:38:46 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1304440724!5995535!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 9044 invoked from network); 3 May 2011 16:38:45 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-3.tower-182.messagelabs.com with SMTP; 3 May 2011 16:38:44 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id E157823F03E8; Tue, 3 May 2011 18:38:44 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 3 May 2011 18:38:44 +0200 From: "Elwell, John" To: "Charles Eckel (eckelcu)" , "Paul Kyzivat (pkyzivat)" Date: Tue, 3 May 2011 18:38:43 +0200 Thread-Topic: [siprec] RS to CS relationship as an attribute inRecording block Thread-Index: AcwGztrLnXFeZgk1S0yQ9SbXcp9ZCAAT5NJgAGtWU+AAORVp4A== Message-ID: References: <4DB58BC7.5090603@cisco.com><4DB820DA.1080200@cisco.com> <4DBB59E2.9040200@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] 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: Tue, 03 May 2011 16:38:57 -0000 I saw a "recording" as being as being a recording of a CS. So yes, a record= ing can exist outside of an RS, and might even span multiple RSs, but doesn= 't the CS object cover this? John=20 > -----Original Message----- > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com]=20 > Sent: 02 May 2011 14:34 > To: Elwell, John; Paul Kyzivat (pkyzivat) > Cc: Parthasarathi R (partr); siprec@ietf.org > Subject: RE: [siprec] RS to CS relationship as an attribute=20 > inRecording block >=20 > Hi John, >=20 > Having a recording exist outside of the RS provides, among=20 > other things, > a way for a SRC to establish a new RS to continue a recording in the > event something goes wrong with initial RS. It also facilitates having > multiple SRCs participate in the same recording, which we=20 > agreed was out > of scope, but is at least possible if a recording exists outside of an > RS. > I suppose the argument could be made this is not really necessary. > Rather, one could, outside of the scope of SIPREC, decide to associate > multiple RSs in various ways, including stitching them=20 > together for the > purpose of failover or distributed recordings. Is that what=20 > you have in > mind? >=20 > Cheers, > Charles >=20 > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Saturday, April 30, 2011 3:12 AM > > To: Paul Kyzivat (pkyzivat); Charles Eckel (eckelcu) > > Cc: Parthasarathi R (partr); siprec@ietf.org > > Subject: RE: [siprec] RS to CS relationship as an attribute > inRecording block > >=20 > > I am confused, because this thread has suddenly started to=20 > talk about > a "recording", whereas metadata- > > 00 has an object called "Recording Session", which 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 > > relationship with an RS, and therefore a single SIP dialog, I would > suggest they articulate why this > > would be needed, with a view to getting it into the metadata model. > >=20 > > John > >=20 > >=20 > > > -----Original Message----- > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > 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 > > > inRecording block > > > > > > > > > > > > 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=20 > SRC, it should > > > associate each independent hunk of metadata in that=20 > 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=20 > siprec, or > > > else convey the data separately in the metadata. > > > > > > Thanks, > > > Paul > > > > > > > Cheers, > > > > Charles > > > > > > > >> -----Original Message----- > > > >> From: siprec-bounces@ietf.org=20 > [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=20 > 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=20 > 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=20 > "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=20 > [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,=20 > 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=20 > 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=20 > 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=20 > 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=20 > 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=20 > 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 Tue May 3 09:43: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 9894DE0841 for ; Tue, 3 May 2011 09:43:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.077 X-Spam-Level: X-Spam-Status: No, score=-105.077 tagged_above=-999 required=5 tests=[AWL=1.522, 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 iTdd531h7r9w for ; Tue, 3 May 2011 09:43:53 -0700 (PDT) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfa.amsl.com (Postfix) with SMTP id C40BCE0843 for ; Tue, 3 May 2011 09:43:51 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1304441027!37841027!1 X-StarScan-Version: 6.2.16; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 6049 invoked from network); 3 May 2011 16:43:47 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-8.tower-27.messagelabs.com with SMTP; 3 May 2011 16:43:47 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 1883023F03E8; Tue, 3 May 2011 18:43:50 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 3 May 2011 18:43:50 +0200 From: "Elwell, John" To: Henry Lum , "siprec@ietf.org" Date: Tue, 3 May 2011 18:43:49 +0200 Thread-Topic: summary of changes for draft-portman-siprec-protocol-04 Thread-Index: AcwIaR0YuGqr5XvNSMqltXB+NekCpQBR+yhg Message-ID: References: <059AF07365DC474393A19A3AF187DF7407028E4B@NAHALD.us.int.genesyslab.com> In-Reply-To: <059AF07365DC474393A19A3AF187DF7407028E4B@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] summary of changes for draft-portman-siprec-protocol-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, 03 May 2011 16:43:53 -0000 Henry, Concerning the RTP model, I agree that the consensus to date seems to be to= cover different RTP models, but I feel we should get something into the ar= chitecture draft to start with, and then later see whether there is any imp= act on the protocol draft. John > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Henry Lum > Sent: 02 May 2011 04:09 > To: siprec@ietf.org > Subject: [siprec] summary of changes for=20 > draft-portman-siprec-protocol-04 >=20 > Hi, >=20 > =20 >=20 > I want to summarize the list of changes we are planning to=20 > include in the next revision of the document: >=20 > =20 >=20 > - Remove use of INFO >=20 > - Both INVITE or UPDATE can be used for metadata=20 > transport through content-disposition >=20 > - Recording indication is placed at SDP media level >=20 > - Recording awareness is indicated at SIP level with=20 > options; feature tag was also considered >=20 > - Recording preference is placed at SDP media level >=20 > - RTP model discussion and time synchronization; so=20 > far we seem to agree to handle different RTP models rather=20 > than requiring a single model. There are 3 models we have=20 > identified so far: >=20 > o RTP mixer - SRC mixes media streams and can directly=20 > synchronize timestamps with metadata and also generate RTCP >=20 > o RTP translator - Media streams are simply forwarded to=20 > the SRS by the SRC. SRC is only capable to indicating=20 > start/stop times to the SRS in metadata. >=20 > o RTP endpoint (is that the right term?) - SRC is neither a=20 > mixer nor translator, but is capable of rewriting RTP and=20 > RTCP in order to synchronize on the timestamps with metadata. >=20 > =20 >=20 > Regards, >=20 > Henry >=20 > =20 >=20 >=20 > CONFIDENTIALITY NOTICE: This e-mail and any files attached=20 > may contain confidential and proprietary information of=20 > Alcatel-Lucent and/or its affiliated entities. Access by the=20 > intended recipient only is authorized. Any liability arising=20 > from any party acting, or refraining from acting, on any=20 > information contained in this e-mail is hereby excluded. If=20 > you are not the intended recipient, please notify the sender=20 > immediately, destroy the original transmission and its=20 > attachments and do not disclose the contents to any other=20 > person, use it for any purpose, or store or copy the=20 > information in any medium. Copyright in this e-mail and any=20 > attachments belongs to Alcatel-Lucent and/or its affiliated entities.=20 > = From eckelcu@cisco.com Tue May 3 09:56: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 80DDCE06DE for ; Tue, 3 May 2011 09:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EC7ErpZdxUbe for ; Tue, 3 May 2011 09:56:12 -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 32643E06B3 for ; Tue, 3 May 2011 09:56:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=13098; q=dns/txt; s=iport; t=1304441772; x=1305651372; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=EXdUm9OcryNdddTbtSyv6QMunU7N40jHLB3QCO/CEvQ=; b=jvrLx+2IwttXtTqCGPydyTn6Ww/x2fmH8vAmGJtY7zw3I140Ude6TFJc b5hu0qejg5sa+Qtc+7sHBiDnuj4zE3AcrOSxgWYeHjV/Lz6EZxJU5kpcd HMR/Qnz3hBCin/nddPhh+4buDwRkOstotlxgsykaBnM3KTm7KUhWBnnrZ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjsBANAywE2rRDoJ/2dsb2JhbACYB44Ud4hynz6cfYMFAYJ8BIYljRaKLxw X-IronPort-AV: E=Sophos;i="4.64,310,1301875200"; d="scan'208";a="349519019" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-2.cisco.com with ESMTP; 03 May 2011 16:56:11 +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 p43GuBCW030792; Tue, 3 May 2011 16:56:11 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, 3 May 2011 09:56:11 -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, 3 May 2011 09:56:09 -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: AcwGztrLnXFeZgk1S0yQ9SbXcp9ZCAAT5NJgAGtWU+AAORVp4AAAnlOA References: <4DB58BC7.5090603@cisco.com><4DB820DA.1080200@cisco.com> <4DBB59E2.9040200@cisco.com> From: "Charles Eckel (eckelcu)" To: "Elwell, John" , "Paul Kyzivat (pkyzivat)" X-OriginalArrivalTime: 03 May 2011 16:56:11.0656 (UTC) FILETIME=[018AA080:01CC09B3] 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: Tue, 03 May 2011 16:56:13 -0000 I do not think the CS is sufficient. For example, how do you know if I want another recording of the same CS, or a single recording? Cheers, Charles > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Tuesday, May 03, 2011 9:39 AM > To: Charles Eckel (eckelcu); Paul Kyzivat (pkyzivat) > Cc: Parthasarathi R (partr); siprec@ietf.org > Subject: RE: [siprec] RS to CS relationship as an attribute inRecording block >=20 > I saw a "recording" as being as being a recording of a CS. So yes, a recording can exist outside of an > RS, and might even span multiple RSs, but doesn't the CS object cover this? >=20 > John >=20 > > -----Original Message----- > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > Sent: 02 May 2011 14:34 > > To: Elwell, John; Paul Kyzivat (pkyzivat) > > Cc: Parthasarathi R (partr); siprec@ietf.org > > Subject: RE: [siprec] RS to CS relationship as an attribute > > inRecording block > > > > Hi John, > > > > Having a recording exist outside of the RS provides, among > > other things, > > a way for a SRC to establish a new RS to continue a recording in the > > event something goes wrong with initial RS. It also facilitates having > > multiple SRCs participate in the same recording, which we > > agreed was out > > of scope, but is at least possible if a recording exists outside of an > > RS. > > I suppose the argument could be made this is not really necessary. > > Rather, one could, outside of the scope of SIPREC, decide to associate > > multiple RSs in various ways, including stitching them > > together for the > > purpose of failover or distributed recordings. Is that what > > you have in > > mind? > > > > Cheers, > > Charles > > > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > Sent: Saturday, April 30, 2011 3:12 AM > > > To: Paul Kyzivat (pkyzivat); Charles Eckel (eckelcu) > > > Cc: Parthasarathi R (partr); siprec@ietf.org > > > Subject: RE: [siprec] RS to CS relationship as an attribute > > inRecording block > > > > > > I am confused, because this thread has suddenly started to > > talk about > > a "recording", whereas metadata- > > > 00 has an object called "Recording Session", which 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 > > > relationship with an RS, and therefore a single SIP dialog, I would > > suggest they articulate why this > > > would be needed, with a view to getting it into the metadata model. > > > > > > John > > > > > > > > > > -----Original Message----- > > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > > 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 > > > > inRecording block > > > > > > > > > > > > > > > > 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 Henry.Lum@alcatel-lucent.com Tue May 3 11:18:30 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8953CE06F3 for ; Tue, 3 May 2011 11:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.882 X-Spam-Level: X-Spam-Status: No, score=-5.882 tagged_above=-999 required=5 tests=[AWL=0.717, 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 VqVD91ofqvt4 for ; Tue, 3 May 2011 11:18:29 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id EBB3BE06B1 for ; Tue, 3 May 2011 11:18:28 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p43IIQoN002687 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 3 May 2011 13:18:26 -0500 (CDT) Received: from relay-out1.wc.genesyslab.com (relay-out1.wc.genesyslab.com [172.22.70.114]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p43IIOTD030769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 May 2011 13:18:25 -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 p43IIOFv028045; Tue, 3 May 2011 11:18: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); Tue, 3 May 2011 11:18:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 3 May 2011 11:18:21 -0700 Message-ID: <059AF07365DC474393A19A3AF187DF74070292B2@NAHALD.us.int.genesyslab.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: summary of changes for draft-portman-siprec-protocol-04 Thread-Index: AcwIaR0YuGqr5XvNSMqltXB+NekCpQBR+yhgAAMNUZA= References: <059AF07365DC474393A19A3AF187DF7407028E4B@NAHALD.us.int.genesyslab.com> From: "Henry Lum" To: "Elwell, John" , X-OriginalArrivalTime: 03 May 2011 18:18:23.0201 (UTC) FILETIME=[7CF8AD10:01CC09BE] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: Re: [siprec] summary of changes for draft-portman-siprec-protocol-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, 03 May 2011 18:18:30 -0000 Hi John, Okay, let's discuss this topic further in the interim meeting to determine whether there is any need to specify any protocol related changes. Regards, Henry > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Tuesday, May 03, 2011 12:44 PM > To: Henry Lum; siprec@ietf.org > Subject: RE: summary of changes for draft-portman-siprec-protocol-04 >=20 > Henry, >=20 > Concerning the RTP model, I agree that the consensus to date seems to > be to cover different RTP models, but I feel we should get something > into the architecture draft to start with, and then later see whether > there is any impact on the protocol draft. >=20 > John >=20 >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf Of Henry Lum > > Sent: 02 May 2011 04:09 > > To: siprec@ietf.org > > Subject: [siprec] summary of changes for > > draft-portman-siprec-protocol-04 > > > > Hi, > > > > > > > > I want to summarize the list of changes we are planning to > > include in the next revision of the document: > > > > > > > > - Remove use of INFO > > > > - Both INVITE or UPDATE can be used for metadata > > transport through content-disposition > > > > - Recording indication is placed at SDP media level > > > > - Recording awareness is indicated at SIP level with > > options; feature tag was also considered > > > > - Recording preference is placed at SDP media level > > > > - RTP model discussion and time synchronization; so > > far we seem to agree to handle different RTP models rather > > than requiring a single model. There are 3 models we have > > identified so far: > > > > o RTP mixer - SRC mixes media streams and can directly > > synchronize timestamps with metadata and also generate RTCP > > > > o RTP translator - Media streams are simply forwarded to > > the SRS by the SRC. SRC is only capable to indicating > > start/stop times to the SRS in metadata. > > > > o RTP endpoint (is that the right term?) - SRC is neither a > > mixer nor translator, but is capable of rewriting RTP and > > RTCP in order to synchronize on the timestamps with metadata. > > > > > > > > Regards, > > > > Henry > > > > > > > > > > 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 john.elwell@siemens-enterprise.com Tue May 3 12:54: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 1C05CE073B for ; Tue, 3 May 2011 12:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.101 X-Spam-Level: X-Spam-Status: No, score=-105.101 tagged_above=-999 required=5 tests=[AWL=1.498, 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 it+-fxFqDM-i for ; Tue, 3 May 2011 12:54:50 -0700 (PDT) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfa.amsl.com (Postfix) with SMTP id 247EAE06ED for ; Tue, 3 May 2011 12:54:49 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1304452485!37854125!1 X-StarScan-Version: 6.2.16; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 29989 invoked from network); 3 May 2011 19:54:45 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-8.tower-27.messagelabs.com with SMTP; 3 May 2011 19:54:45 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id C29881EB83E3; Tue, 3 May 2011 21:54:48 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 3 May 2011 21:54:49 +0200 From: "Elwell, John" To: "Charles Eckel (eckelcu)" , "Paul Kyzivat (pkyzivat)" Date: Tue, 3 May 2011 21:54:45 +0200 Thread-Topic: [siprec] RS to CS relationship as an attribute inRecording block Thread-Index: AcwGztrLnXFeZgk1S0yQ9SbXcp9ZCAAT5NJgAGtWU+AAORVp4AAAnlOAAAZTezA= Message-ID: References: <4DB58BC7.5090603@cisco.com><4DB820DA.1080200@cisco.com> <4DBB59E2.9040200@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] 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: Tue, 03 May 2011 19:54:52 -0000 Why would I want two recordings of the same CS at the same SRS? John > -----Original Message----- > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > Sent: 03 May 2011 17:56 > To: Elwell, John; Paul Kyzivat (pkyzivat) > Cc: Parthasarathi R (partr); siprec@ietf.org > Subject: RE: [siprec] RS to CS relationship as an attribute > inRecording block > > I do not think the CS is sufficient. For example, how do you know if I > want another recording of the same CS, or a single recording? > > Cheers, > Charles > > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Tuesday, May 03, 2011 9:39 AM > > To: Charles Eckel (eckelcu); Paul Kyzivat (pkyzivat) > > Cc: Parthasarathi R (partr); siprec@ietf.org > > Subject: RE: [siprec] RS to CS relationship as an attribute > inRecording block > > > > I saw a "recording" as being as being a recording of a CS. So yes, a > recording can exist outside of an > > RS, and might even span multiple RSs, but doesn't the CS > object cover > this? > > > > John > > > > > -----Original Message----- > > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > Sent: 02 May 2011 14:34 > > > To: Elwell, John; Paul Kyzivat (pkyzivat) > > > Cc: Parthasarathi R (partr); siprec@ietf.org > > > Subject: RE: [siprec] RS to CS relationship as an attribute > > > inRecording block > > > > > > Hi John, > > > > > > Having a recording exist outside of the RS provides, among > > > other things, > > > a way for a SRC to establish a new RS to continue a > recording in the > > > event something goes wrong with initial RS. It also facilitates > having > > > multiple SRCs participate in the same recording, which we > > > agreed was out > > > of scope, but is at least possible if a recording exists > outside of > an > > > RS. > > > I suppose the argument could be made this is not really necessary. > > > Rather, one could, outside of the scope of SIPREC, decide to > associate > > > multiple RSs in various ways, including stitching them > > > together for the > > > purpose of failover or distributed recordings. Is that what > > > you have in > > > mind? > > > > > > Cheers, > > > Charles > > > > > > > -----Original Message----- > > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > Sent: Saturday, April 30, 2011 3:12 AM > > > > To: Paul Kyzivat (pkyzivat); Charles Eckel (eckelcu) > > > > Cc: Parthasarathi R (partr); siprec@ietf.org > > > > Subject: RE: [siprec] RS to CS relationship as an attribute > > > inRecording block > > > > > > > > I am confused, because this thread has suddenly started to > > > talk about > > > a "recording", whereas metadata- > > > > 00 has an object called "Recording Session", which > 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 > > > > relationship with an RS, and therefore a single SIP dialog, I > would > > > suggest they articulate why this > > > > would be needed, with a view to getting it into the metadata > model. > > > > > > > > John > > > > > > > > > > > > > -----Original Message----- > > > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > > > 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 > > > > > inRecording block > > > > > > > > > > > > > > > > > > > > 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 eckelcu@cisco.com Tue May 3 13:25:28 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88F3DE0717 for ; Tue, 3 May 2011 13:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.458 X-Spam-Level: X-Spam-Status: No, score=-10.458 tagged_above=-999 required=5 tests=[AWL=0.141, 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 h795Pkx1On4j for ; Tue, 3 May 2011 13:25:27 -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 EE128E0769 for ; Tue, 3 May 2011 13:25:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=15723; q=dns/txt; s=iport; t=1304454326; x=1305663926; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=Th+/d4hXEYYtecFeGh/VZwZhsGMadktMqZz/WCGEoiI=; b=AP8s7b2lDKa1NBLrc2+RkZPvbcse1jODvzib46ZD5QO8TCP5RSbT7/NM QlQST5VkD6aTc2OwdVkmdfEiI6K6jLCMSgEiMc4lIF0LIf+B4a/KAXDm/ yMUHJlfjwPDnMZxo6xiykFSxNrnHmtKeNa/k0GXxGlFcaLnuMDG+ZLeYa o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjsBAP1jwE2rRDoG/2dsb2JhbACYCI4Ud4hynk6cfIMFAYJ8BIYljRaKLxw X-IronPort-AV: E=Sophos;i="4.64,310,1301875200"; d="scan'208";a="349666933" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-2.cisco.com with ESMTP; 03 May 2011 20:25:26 +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 p43KPQL0012226; Tue, 3 May 2011 20:25:26 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, 3 May 2011 13:25: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: Tue, 3 May 2011 13:25:25 -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: AcwGztrLnXFeZgk1S0yQ9SbXcp9ZCAAT5NJgAGtWU+AAORVp4AAAnlOAAAZTezAAAL33EA== References: <4DB58BC7.5090603@cisco.com><4DB820DA.1080200@cisco.com> <4DBB59E2.9040200@cisco.com> From: "Charles Eckel (eckelcu)" To: "Elwell, John" , "Paul Kyzivat (pkyzivat)" X-OriginalArrivalTime: 03 May 2011 20:25:26.0377 (UTC) FILETIME=[3CBD0590:01CC09D0] 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: Tue, 03 May 2011 20:25:28 -0000 Because one is mine and the other is yours and you want to record yours in one format and in combination with other CSs, and I want mine in another format and with other CSs. For example you want yours recorded a single mixed audio and composited video stream, and I want all separate streams. Cheers, Charles > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Tuesday, May 03, 2011 12:55 PM > To: Charles Eckel (eckelcu); Paul Kyzivat (pkyzivat) > Cc: Parthasarathi R (partr); siprec@ietf.org > Subject: RE: [siprec] RS to CS relationship as an attribute inRecording block >=20 > Why would I want two recordings of the same CS at the same SRS? >=20 > John >=20 > > -----Original Message----- > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > Sent: 03 May 2011 17:56 > > To: Elwell, John; Paul Kyzivat (pkyzivat) > > Cc: Parthasarathi R (partr); siprec@ietf.org > > Subject: RE: [siprec] RS to CS relationship as an attribute > > inRecording block > > > > I do not think the CS is sufficient. For example, how do you know if I > > want another recording of the same CS, or a single recording? > > > > Cheers, > > Charles > > > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > Sent: Tuesday, May 03, 2011 9:39 AM > > > To: Charles Eckel (eckelcu); Paul Kyzivat (pkyzivat) > > > Cc: Parthasarathi R (partr); siprec@ietf.org > > > Subject: RE: [siprec] RS to CS relationship as an attribute > > inRecording block > > > > > > I saw a "recording" as being as being a recording of a CS. So yes, a > > recording can exist outside of an > > > RS, and might even span multiple RSs, but doesn't the CS > > object cover > > this? > > > > > > John > > > > > > > -----Original Message----- > > > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > > Sent: 02 May 2011 14:34 > > > > To: Elwell, John; Paul Kyzivat (pkyzivat) > > > > Cc: Parthasarathi R (partr); siprec@ietf.org > > > > Subject: RE: [siprec] RS to CS relationship as an attribute > > > > inRecording block > > > > > > > > Hi John, > > > > > > > > Having a recording exist outside of the RS provides, among > > > > other things, > > > > a way for a SRC to establish a new RS to continue a > > recording in the > > > > event something goes wrong with initial RS. It also facilitates > > having > > > > multiple SRCs participate in the same recording, which we > > > > agreed was out > > > > of scope, but is at least possible if a recording exists > > outside of > > an > > > > RS. > > > > I suppose the argument could be made this is not really necessary. > > > > Rather, one could, outside of the scope of SIPREC, decide to > > associate > > > > multiple RSs in various ways, including stitching them > > > > together for the > > > > purpose of failover or distributed recordings. Is that what > > > > you have in > > > > mind? > > > > > > > > Cheers, > > > > Charles > > > > > > > > > -----Original Message----- > > > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > > Sent: Saturday, April 30, 2011 3:12 AM > > > > > To: Paul Kyzivat (pkyzivat); Charles Eckel (eckelcu) > > > > > Cc: Parthasarathi R (partr); siprec@ietf.org > > > > > Subject: RE: [siprec] RS to CS relationship as an attribute > > > > inRecording block > > > > > > > > > > I am confused, because this thread has suddenly started to > > > > talk about > > > > a "recording", whereas metadata- > > > > > 00 has an object called "Recording Session", which > > 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 > > > > > relationship with an RS, and therefore a single SIP dialog, I > > would > > > > suggest they articulate why this > > > > > would be needed, with a view to getting it into the metadata > > model. > > > > > > > > > > John > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > > > > 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 > > > > > > inRecording block > > > > > > > > > > > > > > > > > > > > > > > > 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 Tue May 3 13:33:15 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4E98E0800 for ; Tue, 3 May 2011 13:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.124 X-Spam-Level: X-Spam-Status: No, score=-105.124 tagged_above=-999 required=5 tests=[AWL=1.475, 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 h582z4x0kPC3 for ; Tue, 3 May 2011 13:33:14 -0700 (PDT) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfa.amsl.com (Postfix) with SMTP id 762E9E0830 for ; Tue, 3 May 2011 13:33:13 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1304454787!30633194!1 X-StarScan-Version: 6.2.16; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 30278 invoked from network); 3 May 2011 20:33:07 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-10.tower-27.messagelabs.com with SMTP; 3 May 2011 20:33:07 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 3FA471EB83D3; Tue, 3 May 2011 22:33:12 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 3 May 2011 22:33:12 +0200 From: "Elwell, John" To: "Charles Eckel (eckelcu)" , "Paul Kyzivat (pkyzivat)" Date: Tue, 3 May 2011 22:33:10 +0200 Thread-Topic: [siprec] RS to CS relationship as an attribute inRecording block Thread-Index: AcwGztrLnXFeZgk1S0yQ9SbXcp9ZCAAT5NJgAGtWU+AAORVp4AAAnlOAAAZTezAAAL33EAAAlUcw Message-ID: References: <4DB58BC7.5090603@cisco.com><4DB820DA.1080200@cisco.com> <4DBB59E2.9040200@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] 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: Tue, 03 May 2011 20:33:15 -0000 In that case, I would assert that we need a "Recording" object in the metad= ata model, not a "Recording Session" object. John > -----Original Message----- > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > Sent: 03 May 2011 21:25 > To: Elwell, John; Paul Kyzivat (pkyzivat) > Cc: Parthasarathi R (partr); siprec@ietf.org > Subject: RE: [siprec] RS to CS relationship as an attribute > inRecording block > > Because one is mine and the other is yours and you want to > record yours > in one format and in combination with other CSs, and I want mine in > another format and with other CSs. > For example you want yours recorded a single mixed audio and > composited > video stream, and I want all separate streams. > > Cheers, > Charles > > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Tuesday, May 03, 2011 12:55 PM > > To: Charles Eckel (eckelcu); Paul Kyzivat (pkyzivat) > > Cc: Parthasarathi R (partr); siprec@ietf.org > > Subject: RE: [siprec] RS to CS relationship as an attribute > inRecording block > > > > Why would I want two recordings of the same CS at the same SRS? > > > > John > > > > > -----Original Message----- > > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > Sent: 03 May 2011 17:56 > > > To: Elwell, John; Paul Kyzivat (pkyzivat) > > > Cc: Parthasarathi R (partr); siprec@ietf.org > > > Subject: RE: [siprec] RS to CS relationship as an attribute > > > inRecording block > > > > > > I do not think the CS is sufficient. For example, how do > you know if > I > > > want another recording of the same CS, or a single recording? > > > > > > Cheers, > > > Charles > > > > > > > -----Original Message----- > > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > Sent: Tuesday, May 03, 2011 9:39 AM > > > > To: Charles Eckel (eckelcu); Paul Kyzivat (pkyzivat) > > > > Cc: Parthasarathi R (partr); siprec@ietf.org > > > > Subject: RE: [siprec] RS to CS relationship as an attribute > > > inRecording block > > > > > > > > I saw a "recording" as being as being a recording of a > CS. So yes, > a > > > recording can exist outside of an > > > > RS, and might even span multiple RSs, but doesn't the CS > > > object cover > > > this? > > > > > > > > John > > > > > > > > > -----Original Message----- > > > > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > > > Sent: 02 May 2011 14:34 > > > > > To: Elwell, John; Paul Kyzivat (pkyzivat) > > > > > Cc: Parthasarathi R (partr); siprec@ietf.org > > > > > Subject: RE: [siprec] RS to CS relationship as an attribute > > > > > inRecording block > > > > > > > > > > Hi John, > > > > > > > > > > Having a recording exist outside of the RS provides, among > > > > > other things, > > > > > a way for a SRC to establish a new RS to continue a > > > recording in the > > > > > event something goes wrong with initial RS. It also > facilitates > > > having > > > > > multiple SRCs participate in the same recording, which we > > > > > agreed was out > > > > > of scope, but is at least possible if a recording exists > > > outside of > > > an > > > > > RS. > > > > > I suppose the argument could be made this is not really > necessary. > > > > > Rather, one could, outside of the scope of SIPREC, decide to > > > associate > > > > > multiple RSs in various ways, including stitching them > > > > > together for the > > > > > purpose of failover or distributed recordings. Is that what > > > > > you have in > > > > > mind? > > > > > > > > > > Cheers, > > > > > Charles > > > > > > > > > > > -----Original Message----- > > > > > > From: Elwell, John > [mailto:john.elwell@siemens-enterprise.com] > > > > > > Sent: Saturday, April 30, 2011 3:12 AM > > > > > > To: Paul Kyzivat (pkyzivat); Charles Eckel (eckelcu) > > > > > > Cc: Parthasarathi R (partr); siprec@ietf.org > > > > > > Subject: RE: [siprec] RS to CS relationship as an attribute > > > > > inRecording block > > > > > > > > > > > > I am confused, because this thread has suddenly started to > > > > > talk about > > > > > a "recording", whereas metadata- > > > > > > 00 has an object called "Recording Session", which > > > 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 > > > > > > relationship with an RS, and therefore a single SIP > dialog, I > > > would > > > > > suggest they articulate why this > > > > > > would be needed, with a view to getting it into the metadata > > > model. > > > > > > > > > > > > John > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > > > > > 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 > > > > > > > inRecording block > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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 eckelcu@cisco.com Tue May 3 14:29:56 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 9CA2BE069D for ; Tue, 3 May 2011 14:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.466 X-Spam-Level: X-Spam-Status: No, score=-10.466 tagged_above=-999 required=5 tests=[AWL=0.133, 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 bRJGXSd6D4aR for ; Tue, 3 May 2011 14:29:55 -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 0F600E0663 for ; Tue, 3 May 2011 14:29:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=18370; q=dns/txt; s=iport; t=1304458195; x=1305667795; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=DYK1HlMq/UbD9QAqwowLmkpL6+7tLrK/vHLuLCckmYQ=; b=PXOT+0UZIiT3YHxVL2xkMlpbCVXCpCjhvysWk4atvQAqx2cTsedf7jPI IjJ7Wvr5vj1cmADr5R8Oa6HczMqYFAX1RpBcgZPMXahV6bZRVlOP1jm2R oBS6cea4X7oTsarYNbl70w9GKKvVvgJsOJLRVefnLiPdycoP8NIARXI2Z U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai4BAERzwE2rRDoG/2dsb2JhbACYCo4Ud4hynwGeG4MFAYJ8BIYljRaKLxw X-IronPort-AV: E=Sophos;i="4.64,311,1301875200"; d="scan'208";a="691367420" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-6.cisco.com with ESMTP; 03 May 2011 21:29:50 +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 p43LTgRD012922; Tue, 3 May 2011 21:29:50 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, 3 May 2011 14:29:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 3 May 2011 14:29:47 -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: AcwGztrLnXFeZgk1S0yQ9SbXcp9ZCAAT5NJgAGtWU+AAORVp4AAAnlOAAAZTezAAAL33EAAAlUcwAAIBSSA= References: <4DB58BC7.5090603@cisco.com><4DB820DA.1080200@cisco.com> <4DBB59E2.9040200@cisco.com> From: "Charles Eckel (eckelcu)" To: "Elwell, John" , "Paul Kyzivat (pkyzivat)" X-OriginalArrivalTime: 03 May 2011 21:29:48.0712 (UTC) FILETIME=[3ADE9280:01CC09D9] 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: Tue, 03 May 2011 21:29:56 -0000 Works for me. > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Tuesday, May 03, 2011 1:33 PM > To: Charles Eckel (eckelcu); Paul Kyzivat (pkyzivat) > Cc: Parthasarathi R (partr); siprec@ietf.org > Subject: RE: [siprec] RS to CS relationship as an attribute inRecording block >=20 > In that case, I would assert that we need a "Recording" object in the metadata model, not a "Recording > Session" object. >=20 > John >=20 > > -----Original Message----- > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > Sent: 03 May 2011 21:25 > > To: Elwell, John; Paul Kyzivat (pkyzivat) > > Cc: Parthasarathi R (partr); siprec@ietf.org > > Subject: RE: [siprec] RS to CS relationship as an attribute > > inRecording block > > > > Because one is mine and the other is yours and you want to > > record yours > > in one format and in combination with other CSs, and I want mine in > > another format and with other CSs. > > For example you want yours recorded a single mixed audio and > > composited > > video stream, and I want all separate streams. > > > > Cheers, > > Charles > > > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > Sent: Tuesday, May 03, 2011 12:55 PM > > > To: Charles Eckel (eckelcu); Paul Kyzivat (pkyzivat) > > > Cc: Parthasarathi R (partr); siprec@ietf.org > > > Subject: RE: [siprec] RS to CS relationship as an attribute > > inRecording block > > > > > > Why would I want two recordings of the same CS at the same SRS? > > > > > > John > > > > > > > -----Original Message----- > > > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > > Sent: 03 May 2011 17:56 > > > > To: Elwell, John; Paul Kyzivat (pkyzivat) > > > > Cc: Parthasarathi R (partr); siprec@ietf.org > > > > Subject: RE: [siprec] RS to CS relationship as an attribute > > > > inRecording block > > > > > > > > I do not think the CS is sufficient. For example, how do > > you know if > > I > > > > want another recording of the same CS, or a single recording? > > > > > > > > Cheers, > > > > Charles > > > > > > > > > -----Original Message----- > > > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > > Sent: Tuesday, May 03, 2011 9:39 AM > > > > > To: Charles Eckel (eckelcu); Paul Kyzivat (pkyzivat) > > > > > Cc: Parthasarathi R (partr); siprec@ietf.org > > > > > Subject: RE: [siprec] RS to CS relationship as an attribute > > > > inRecording block > > > > > > > > > > I saw a "recording" as being as being a recording of a > > CS. So yes, > > a > > > > recording can exist outside of an > > > > > RS, and might even span multiple RSs, but doesn't the CS > > > > object cover > > > > this? > > > > > > > > > > John > > > > > > > > > > > -----Original Message----- > > > > > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > > > > Sent: 02 May 2011 14:34 > > > > > > To: Elwell, John; Paul Kyzivat (pkyzivat) > > > > > > Cc: Parthasarathi R (partr); siprec@ietf.org > > > > > > Subject: RE: [siprec] RS to CS relationship as an attribute > > > > > > inRecording block > > > > > > > > > > > > Hi John, > > > > > > > > > > > > Having a recording exist outside of the RS provides, among > > > > > > other things, > > > > > > a way for a SRC to establish a new RS to continue a > > > > recording in the > > > > > > event something goes wrong with initial RS. It also > > facilitates > > > > having > > > > > > multiple SRCs participate in the same recording, which we > > > > > > agreed was out > > > > > > of scope, but is at least possible if a recording exists > > > > outside of > > > > an > > > > > > RS. > > > > > > I suppose the argument could be made this is not really > > necessary. > > > > > > Rather, one could, outside of the scope of SIPREC, decide to > > > > associate > > > > > > multiple RSs in various ways, including stitching them > > > > > > together for the > > > > > > purpose of failover or distributed recordings. Is that what > > > > > > you have in > > > > > > mind? > > > > > > > > > > > > Cheers, > > > > > > Charles > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Elwell, John > > [mailto:john.elwell@siemens-enterprise.com] > > > > > > > Sent: Saturday, April 30, 2011 3:12 AM > > > > > > > To: Paul Kyzivat (pkyzivat); Charles Eckel (eckelcu) > > > > > > > Cc: Parthasarathi R (partr); siprec@ietf.org > > > > > > > Subject: RE: [siprec] RS to CS relationship as an attribute > > > > > > inRecording block > > > > > > > > > > > > > > I am confused, because this thread has suddenly started to > > > > > > talk about > > > > > > a "recording", whereas metadata- > > > > > > > 00 has an object called "Recording Session", which > > > > 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 > > > > > > > relationship with an RS, and therefore a single SIP > > dialog, I > > > > would > > > > > > suggest they articulate why this > > > > > > > would be needed, with a view to getting it into the metadata > > > > model. > > > > > > > > > > > > > > John > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > > > > > > 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 > > > > > > > > inRecording block > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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 partr@cisco.com Tue May 3 17:44:24 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 7F5C0E06D1 for ; Tue, 3 May 2011 17:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.07 X-Spam-Level: X-Spam-Status: No, score=-10.07 tagged_above=-999 required=5 tests=[AWL=0.529, 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 zg8ev6RrVgDI for ; Tue, 3 May 2011 17:44:23 -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 D9EC6E06CE for ; Tue, 3 May 2011 17:44:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=4822; q=dns/txt; s=iport; t=1304469863; x=1305679463; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=kIhYGBBlZAanVOCYXurPRUtKpzdDm5BrRb7tXms2Jk4=; b=OCrbqXJmCoNMk5oa5dP7QY2RSapr892L2uFY2Cq4bMI8JAMwXwaN/VdA mVqzPtry09kNCMbB6nH2V9XB5ZrXZQhIueBYp7ZwxLm04Ub1iFtiq6+u3 TyOzGukcGr6n5rp8kIc5j9XGmOJXM/UHFWFBw5rq4ZzJcHmNQddOaNBF1 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggBAESgwE2Q/khLgWdsb2JhbACYC44VFAEBFiYliHKeNp4agwaCfASGI40Yihc X-IronPort-AV: E=Sophos;i="4.64,312,1301875200"; d="scan'208";a="28519304" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 04 May 2011 00:44:21 +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 p440iKTw025717; Wed, 4 May 2011 00:44:21 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, 4 May 2011 06:14:19 +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, 4 May 2011 06:14:19 +0530 Message-ID: In-Reply-To: <07465C1D981ABC41A344374066AE1A2C38AB7A1BAB@TLVMBX01.nice.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] RS to CS relationship as an attributein Recording block Thread-Index: AcwDWRLgHjT1vcDDTPej6dPykApc6QBV5SagAAozkoABRmlekA== References: <4DB58BC7.5090603@cisco.com> <07465C1D981ABC41A344374066AE1A2C38AB7A1BAB@TLVMBX01.nice.com> From: "Parthasarathi R (partr)" To: "Leon Portman" , "Elwell, John" , "Paul Kyzivat (pkyzivat)" , X-OriginalArrivalTime: 04 May 2011 00:44:19.0860 (UTC) FILETIME=[676A6D40:01CC09F4] Subject: Re: [siprec] RS to CS relationship as an attributein 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, 04 May 2011 00:44:24 -0000 All the folks in the mail thread indicates that SIPREC solution will be designed in a generic fashion of "Many RS to Many CS" relationship in SRS by default. Even current metadata format draft(-01) is written with the same assumption. In case anybody have disagreement with this approach, Please speak for it. Thanks Partha -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Leon Portman Sent: Wednesday, April 27, 2011 6:20 PM To: Elwell, John; Paul Kyzivat (pkyzivat); siprec@ietf.org Subject: Re: [siprec] RS to CS relationship as an attributein Recording block 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 block 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. 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 > > 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 >=20 _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From pkyzivat@cisco.com Tue May 3 18:21:58 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA128E06AC for ; Tue, 3 May 2011 18:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.509 X-Spam-Level: X-Spam-Status: No, score=-110.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 l+vBfFqceIbq for ; Tue, 3 May 2011 18:21:57 -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 66E38E0618 for ; Tue, 3 May 2011 18:21:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=15798; q=dns/txt; s=iport; t=1304472117; x=1305681717; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=k4Sh/g0NTP8kUF28Jd/sDFxBeYFsEE1+NLU8jjMciJg=; b=Qb5AjgS4R5bigZd/fmP2HYMlRv8yYE5f9mHsdtyTMg+25lJfcOXZR25J nxXIiCFBaGFPUtNL+kAgHUkdukAzOOCjQOCDbP5IpwuczCs9Tf066n5Pv a+jiWge7iMBP6n8244ImnnbDDeQ+p+LJaAWjgBDdR+BImmIYrizrPR3dK w=; X-IronPort-AV: E=Sophos;i="4.64,312,1301875200"; d="scan'208";a="691462238" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by sj-iport-6.cisco.com with ESMTP; 04 May 2011 01:21:56 +0000 Received: from [161.44.174.124] (dhcp-161-44-174-124.cisco.com [161.44.174.124]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p441Ltom031425; Wed, 4 May 2011 01:21:56 GMT Message-ID: <4DC0AA33.80205@cisco.com> Date: Tue, 03 May 2011 21:21:55 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Elwell, John" References: <4DB58BC7.5090603@cisco.com><4DB820DA.1080200@cisco.com> <4DBB59E2.9040200@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: Wed, 04 May 2011 01:21:59 -0000 Of course this could be accomplished simply by dumb luck: If you and I have separate SRCs and are asking for separate recordings of the "same" CS, it will only be recognized as the same CS if the two SRCs coordinate among themselves to use the same UUID for it. If they don't (likely in this case) the SRS with thing it is two CSs and so you get two recodings. Thanks, Paul On 5/3/2011 4:33 PM, Elwell, John wrote: > In that case, I would assert that we need a "Recording" object in the metadata model, not a "Recording Session" object. > > John > >> -----Original Message----- >> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] >> Sent: 03 May 2011 21:25 >> To: Elwell, John; Paul Kyzivat (pkyzivat) >> Cc: Parthasarathi R (partr); siprec@ietf.org >> Subject: RE: [siprec] RS to CS relationship as an attribute >> inRecording block >> >> Because one is mine and the other is yours and you want to >> record yours >> in one format and in combination with other CSs, and I want mine in >> another format and with other CSs. >> For example you want yours recorded a single mixed audio and >> composited >> video stream, and I want all separate streams. >> >> Cheers, >> Charles >> >>> -----Original Message----- >>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>> Sent: Tuesday, May 03, 2011 12:55 PM >>> To: Charles Eckel (eckelcu); Paul Kyzivat (pkyzivat) >>> Cc: Parthasarathi R (partr); siprec@ietf.org >>> Subject: RE: [siprec] RS to CS relationship as an attribute >> inRecording block >>> >>> Why would I want two recordings of the same CS at the same SRS? >>> >>> John >>> >>>> -----Original Message----- >>>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] >>>> Sent: 03 May 2011 17:56 >>>> To: Elwell, John; Paul Kyzivat (pkyzivat) >>>> Cc: Parthasarathi R (partr); siprec@ietf.org >>>> Subject: RE: [siprec] RS to CS relationship as an attribute >>>> inRecording block >>>> >>>> I do not think the CS is sufficient. For example, how do >> you know if >> I >>>> want another recording of the same CS, or a single recording? >>>> >>>> Cheers, >>>> Charles >>>> >>>>> -----Original Message----- >>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>>>> Sent: Tuesday, May 03, 2011 9:39 AM >>>>> To: Charles Eckel (eckelcu); Paul Kyzivat (pkyzivat) >>>>> Cc: Parthasarathi R (partr); siprec@ietf.org >>>>> Subject: RE: [siprec] RS to CS relationship as an attribute >>>> inRecording block >>>>> >>>>> I saw a "recording" as being as being a recording of a >> CS. So yes, >> a >>>> recording can exist outside of an >>>>> RS, and might even span multiple RSs, but doesn't the CS >>>> object cover >>>> this? >>>>> >>>>> John >>>>> >>>>>> -----Original Message----- >>>>>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] >>>>>> Sent: 02 May 2011 14:34 >>>>>> To: Elwell, John; Paul Kyzivat (pkyzivat) >>>>>> Cc: Parthasarathi R (partr); siprec@ietf.org >>>>>> Subject: RE: [siprec] RS to CS relationship as an attribute >>>>>> inRecording block >>>>>> >>>>>> Hi John, >>>>>> >>>>>> Having a recording exist outside of the RS provides, among >>>>>> other things, >>>>>> a way for a SRC to establish a new RS to continue a >>>> recording in the >>>>>> event something goes wrong with initial RS. It also >> facilitates >>>> having >>>>>> multiple SRCs participate in the same recording, which we >>>>>> agreed was out >>>>>> of scope, but is at least possible if a recording exists >>>> outside of >>>> an >>>>>> RS. >>>>>> I suppose the argument could be made this is not really >> necessary. >>>>>> Rather, one could, outside of the scope of SIPREC, decide to >>>> associate >>>>>> multiple RSs in various ways, including stitching them >>>>>> together for the >>>>>> purpose of failover or distributed recordings. Is that what >>>>>> you have in >>>>>> mind? >>>>>> >>>>>> Cheers, >>>>>> Charles >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Elwell, John >> [mailto:john.elwell@siemens-enterprise.com] >>>>>>> Sent: Saturday, April 30, 2011 3:12 AM >>>>>>> To: Paul Kyzivat (pkyzivat); Charles Eckel (eckelcu) >>>>>>> Cc: Parthasarathi R (partr); siprec@ietf.org >>>>>>> Subject: RE: [siprec] RS to CS relationship as an attribute >>>>>> inRecording block >>>>>>> >>>>>>> I am confused, because this thread has suddenly started to >>>>>> talk about >>>>>> a "recording", whereas metadata- >>>>>>> 00 has an object called "Recording Session", which >>>> 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 >>>>>>> relationship with an RS, and therefore a single SIP >> dialog, I >>>> would >>>>>> suggest they articulate why this >>>>>>> would be needed, with a view to getting it into the metadata >>>> model. >>>>>>> >>>>>>> John >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>>>>> 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 >>>>>>>> inRecording block >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 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 partr@cisco.com Tue May 3 21:46: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 C3463E0692 for ; Tue, 3 May 2011 21:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.21 X-Spam-Level: X-Spam-Status: No, score=-9.21 tagged_above=-999 required=5 tests=[AWL=-0.412, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFW7omo7jiCd for ; Tue, 3 May 2011 21:46:05 -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 DA9C3E065A for ; Tue, 3 May 2011 21:46:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=21786; q=dns/txt; s=iport; t=1304484364; x=1305693964; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=StQ3RbCLVyrM+6ic4RRWeR9hJ8AALSyddFyzzYu66xo=; b=MxGpy7jpnLHYH86X+MbFoAGqFLKghd2uTQeXnL9tIO9d5acBSUm2aNd5 jNvesJ3prSPX0jI4WUYwgjlXdJ7Ke1Vk9nsoW33lgz1ubCeGh3rTiNpCj jo0E8eYs4y2FKLs3mwOQ6tJFpQdYYmirlCtQupZP7zcdn44+144yojBuA 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au4AAGjZwE2Q/khLgWdsb2JhbACYCY4ZFAEBFiYliHKdMZ4SgwuCfASGK40nihw X-IronPort-AV: E=Sophos;i="4.64,313,1301875200"; d="scan'208";a="86655461" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 04 May 2011 04:46:02 +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 p444jwIV012259; Wed, 4 May 2011 04:46:02 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, 4 May 2011 10:16: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: Wed, 4 May 2011 10:15:57 +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+AAEAO1UAANZylQAXAZhbAAHzy2EALO3FmA References: <4D9CB8E1.7030402@cisco.com> From: "Parthasarathi R (partr)" To: "Charles Eckel (eckelcu)" , "Elwell, John" , "Paul Kyzivat (pkyzivat)" , X-OriginalArrivalTime: 04 May 2011 04:46:00.0954 (UTC) FILETIME=[2ABDC5A0:01CC0A16] 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: Wed, 04 May 2011 04:46:06 -0000 Hi Charles, In case participants id has to be unique for single RS with multiple CS as you mentioned below mail and also, participant id has to be unique within single CS which span across multiple RS (start & stop of recording within CS scenario), then participant unique id needs to be global (URN UUID) rather than local id like xml:id. Please let me know in case you have any other opinion on the same. Thanks Partha -----Original Message----- From: Charles Eckel (eckelcu)=20 Sent: Wednesday, April 20, 2011 2:54 AM 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 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-=20 > archive/web/siprec/current/msg01864.html), there is no known usecase=20 > wherein participant involved in RS but not involved in CS directly.=20 > IOW, participant is always within CS. This change in metadata model=20 > 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 &=20 > 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=20 > 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);=20 > siprec@ietf.org > Cc: Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr); Hadriel=20 > 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,=20 > 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=20 > > Behalf Of Elwell, John > > Sent: Monday, April 11, 2011 9:46 AM > > To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat);=20 > > 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=20 > > weeks/months ago about the participants obtained from the conference > > event package. I was never particularly comfortable with the fact=20 > > these were not considered part of the CS. While that might be=20 > > correct if we consider the CS to be the SIP dialog between the SRC=20 > > and the conference focus, taking a broader view of CS those=20 > > participants behind the focus could be > considered part of the CS. I don't particularly want to open up the=20 > 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=20 > > CS, and if we don't have specific information about their=20 > > 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=20 > > 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=20 > > with are between the mixer and the > SRC. > > > > 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=20 > 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);=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,=20 > > > > (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=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=20 > > > 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 > > > 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=20 > > > 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=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=20 > > > 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=20 > > > > 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=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=20 > > > scenario was considered as a blocking in -03 version of metadata.=20 > > > 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=20 > > > related) but they contributed for the mixed stream. > > > > > > That user is sending/receiving Media Streams that are part of a=20 > > > 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 > > > (SRC) and SRS. Here tangling (conference event package)=20 > > > participant has to be grouped together in RS1, RS2 by some means=20 > > > 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=20 > > > > > 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=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 > > > > > 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*=20 > > > > > 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=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=20 > > > > > 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=20 > > > > > 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=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 > > > > > 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=20 > > > > > > 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=20 > > > > > 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=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 May 3 22:35:34 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A99D4E0651 for ; Tue, 3 May 2011 22:35:34 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t+pMsDSZUDhx for ; Tue, 3 May 2011 22:35:33 -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 32831E06E6 for ; Tue, 3 May 2011 22:35:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=6141; q=dns/txt; s=iport; t=1304487333; x=1305696933; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=Qyiih/sEfhkvjiXrjDCVoMx3WzoBt0p9DhiDk5ZDWas=; b=dFSMLewUGgHkQfZ2QcHtt8S+pUFsAc5vqI2ocuLEeDDOgWzGbOsr/pry UhQ0lJx80qiIfw7DOvnMp5d+IEIVpefSL5H+LoyOqUNBS2lR0U0CYteLb o2BjkHDYA9kGcn/LqcnC5tEmvjon9QrlPvXpk1WD8Z/QHnxH2lZ8yJAwB 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au4AAHTkwE2Q/khMgWdsb2JhbACYCo4ZFAEBFiYlpieeGYMLgnwEhiuNJ4oc X-IronPort-AV: E=Sophos;i="4.64,313,1301875200"; d="scan'208";a="28545231" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 04 May 2011 05:35:32 +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 p445ZSII000364; Wed, 4 May 2011 05:35:31 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, 4 May 2011 11:05: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, 4 May 2011 11:05:28 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD06357480@XMB-BGL-417.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] RS to CS relationship as an attributein Recording block Thread-Index: AcwDWRLgHjT1vcDDTPej6dPykApc6QBV5SagAAozkoABRmlekAAJ/Rfg References: <4DB58BC7.5090603@cisco.com><07465C1D981ABC41A344374066AE1A2C38AB7A1BAB@TLVMBX01.nice.com> From: "Ram Mohan R (rmohanr)" To: "Parthasarathi R (partr)" , "Leon Portman" , "Elwell, John" , "Paul Kyzivat (pkyzivat)" , X-OriginalArrivalTime: 04 May 2011 05:35:31.0176 (UTC) FILETIME=[1521AE80:01CC0A1D] Subject: Re: [siprec] RS to CS relationship as an attributein 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, 04 May 2011 05:35:34 -0000 I think this is something we discussed earlier w.r.t model also to accommodate "Many RS to many CS" http://www.ietf.org/mail-archive/web/siprec/current/msg01746.html The associations with that change in model can allow: A CS to be associated with multiple RS [ to take care of use case 3 mentioned by Partha way below in this mail thread]=20 A RS to have Zero or more CSs [ to support use case 1 and 2] In any case I will add this item to model slide and we can discuss during the Interim meeting on May 9th to close it. Regards, Ram > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Parthasarathi R (partr) > Sent: Wednesday, May 04, 2011 6:14 AM > To: Leon Portman; Elwell, John; Paul Kyzivat (pkyzivat); > siprec@ietf.org > Subject: Re: [siprec] RS to CS relationship as an attributein Recording > block >=20 > All the folks in the mail thread indicates that SIPREC solution will be > designed in a generic fashion of "Many RS to Many CS" relationship in > SRS by default. Even current metadata format draft(-01) is written with > the same assumption. >=20 > In case anybody have disagreement with this approach, Please speak for > it. >=20 > Thanks > Partha >=20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf > Of Leon Portman > Sent: Wednesday, April 27, 2011 6:20 PM > To: Elwell, John; Paul Kyzivat (pkyzivat); siprec@ietf.org > Subject: Re: [siprec] RS to CS relationship as an attributein Recording > block >=20 > 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 >=20 > Leon >=20 > -----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 > block >=20 > I agree with Paul. >=20 > 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 > However, I have a feeling we have been round this loop before, so > apologies if we came to a resolution. >=20 > 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 > > 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 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From Internet-Drafts@ietf.org Wed May 4 00:00:02 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61BB7E071B; Wed, 4 May 2011 00:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VkdjFemrZFu0; Wed, 4 May 2011 00:00:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5A9DE0756; Wed, 4 May 2011 00: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.53 Message-ID: <20110504070001.7597.66969.idtracker@ietfa.amsl.com> Date: Wed, 04 May 2011 00:00:01 -0700 Cc: siprec@ietf.org Subject: [siprec] I-D Action:draft-ietf-siprec-req-10.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, 04 May 2011 07: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 : Use Cases and Requirements for SIP-based Media Recording (SIPREC) Author(s) : K. Rehor, et al. Filename : draft-ietf-siprec-req-10.txt Pages : 16 Date : 2011-05-03 Session recording is a critical requirement in many business communications environments such as call centers and financial trading floors. In some of these environments, all calls must be recorded for regulatory and compliance reasons. In others, calls may be recorded for quality control or business analytics. Recording is typically performed by sending a copy of the session media to the recording devices. This document specifies requirements for extensions to SIP that will manage delivery of RTP media to a recording device. This is being referred to as SIP-based Media Recording. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-siprec-req-10.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-req-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-05-03234612.I-D@ietf.org> --NextPart-- From rmohanr@cisco.com Wed May 4 04:51: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 0B18BE0748 for ; Wed, 4 May 2011 04:51:06 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5KAOroPE+Kg4 for ; Wed, 4 May 2011 04:51:04 -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 B6DF4E067A for ; Wed, 4 May 2011 04:51:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=17841; q=dns/txt; s=iport; t=1304509863; x=1305719463; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=S6Psbmdi2mX5scIBsE1sW9+bku3mQK3a6RWEu4YKqhk=; b=UoZxzFEGMnezECX8evCUMvE+Ie/Qv8KmQ999f1gEi1o2tCmSOnot6iWf EzrWi90txw3CRvQVadVkg50C7M91SgN1A+4zqqFIQuoN0Qtgk/7ih7Cjd sz/g93a1pHl8GrCPWf32Lw4vqwVkKxMzlxBteoqUsL0DM3/I/ovKf3cOJ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8BAF48wU2Q/khMgWdsb2JhbACYCY4OFAEBFiYlpiqeLYMKAYJ8BIYtjS2KHTQ X-IronPort-AV: E=Sophos;i="4.64,313,1301875200"; d="scan'208";a="28610410" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 04 May 2011 11:51:02 +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 p44BoxjV017154; Wed, 4 May 2011 11:51:02 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, 4 May 2011 17:20:59 +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, 4 May 2011 17:20:55 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD0635764C@XMB-BGL-417.cisco.com> In-Reply-To: <4DC0AA33.80205@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] RS to CS relationship as an attribute inRecording block Thread-Index: AcwJ+biFoOO41i/hQIKAJCEft7se1gAVN5rw References: <4DB58BC7.5090603@cisco.com><4DB820DA.1080200@cisco.com><4DBB59E2.9040200@cisco.com> <4DC0AA33.80205@cisco.com> From: "Ram Mohan R (rmohanr)" To: "Paul Kyzivat (pkyzivat)" , "Elwell, John" X-OriginalArrivalTime: 04 May 2011 11:50:59.0381 (UTC) FILETIME=[88FCF650:01CC0A51] 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: Wed, 04 May 2011 11:51:06 -0000 I agree with Paul here.=20 The below use-case that Charles mentions is a good example of two SRCs recording the same CS simultaneously via different RS. In these cases these are two Recording Sessions each recording the same CS and the current model is sufficient for the same. John, so I don't see a need to change "Recording Session" to "Recording" object in the model. Or are you talking here about grouping of recordings ? As Paul mentioned it will only be recognized as the same CS only if the two SRCs coordinate among themselves to use the same UUID for it. Otherwise we will get two recordings. Ram > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Paul Kyzivat (pkyzivat) > Sent: Wednesday, May 04, 2011 6:52 AM > To: Elwell, John > Cc: siprec@ietf.org > Subject: Re: [siprec] RS to CS relationship as an attribute inRecording > block >=20 > Of course this could be accomplished simply by dumb luck: >=20 > If you and I have separate SRCs and are asking for separate recordings > of the "same" CS, it will only be recognized as the same CS if the two > SRCs coordinate among themselves to use the same UUID for it. If they > don't (likely in this case) the SRS with thing it is two CSs and so you > get two recodings. >=20 > Thanks, > Paul >=20 > On 5/3/2011 4:33 PM, Elwell, John wrote: > > In that case, I would assert that we need a "Recording" object in the > metadata model, not a "Recording Session" object. > > > > John > > > >> -----Original Message----- > >> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > >> Sent: 03 May 2011 21:25 > >> To: Elwell, John; Paul Kyzivat (pkyzivat) > >> Cc: Parthasarathi R (partr); siprec@ietf.org > >> Subject: RE: [siprec] RS to CS relationship as an attribute > >> inRecording block > >> > >> Because one is mine and the other is yours and you want to > >> record yours > >> in one format and in combination with other CSs, and I want mine in > >> another format and with other CSs. > >> For example you want yours recorded a single mixed audio and > >> composited > >> video stream, and I want all separate streams. > >> > >> Cheers, > >> Charles > >> > >>> -----Original Message----- > >>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > >>> Sent: Tuesday, May 03, 2011 12:55 PM > >>> To: Charles Eckel (eckelcu); Paul Kyzivat (pkyzivat) > >>> Cc: Parthasarathi R (partr); siprec@ietf.org > >>> Subject: RE: [siprec] RS to CS relationship as an attribute > >> inRecording block > >>> > >>> Why would I want two recordings of the same CS at the same SRS? > >>> > >>> John > >>> > >>>> -----Original Message----- > >>>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > >>>> Sent: 03 May 2011 17:56 > >>>> To: Elwell, John; Paul Kyzivat (pkyzivat) > >>>> Cc: Parthasarathi R (partr); siprec@ietf.org > >>>> Subject: RE: [siprec] RS to CS relationship as an attribute > >>>> inRecording block > >>>> > >>>> I do not think the CS is sufficient. For example, how do > >> you know if > >> I > >>>> want another recording of the same CS, or a single recording? > >>>> > >>>> Cheers, > >>>> Charles > >>>> > >>>>> -----Original Message----- > >>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > >>>>> Sent: Tuesday, May 03, 2011 9:39 AM > >>>>> To: Charles Eckel (eckelcu); Paul Kyzivat (pkyzivat) > >>>>> Cc: Parthasarathi R (partr); siprec@ietf.org > >>>>> Subject: RE: [siprec] RS to CS relationship as an attribute > >>>> inRecording block > >>>>> > >>>>> I saw a "recording" as being as being a recording of a > >> CS. So yes, > >> a > >>>> recording can exist outside of an > >>>>> RS, and might even span multiple RSs, but doesn't the CS > >>>> object cover > >>>> this? > >>>>> > >>>>> John > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > >>>>>> Sent: 02 May 2011 14:34 > >>>>>> To: Elwell, John; Paul Kyzivat (pkyzivat) > >>>>>> Cc: Parthasarathi R (partr); siprec@ietf.org > >>>>>> Subject: RE: [siprec] RS to CS relationship as an attribute > >>>>>> inRecording block > >>>>>> > >>>>>> Hi John, > >>>>>> > >>>>>> Having a recording exist outside of the RS provides, among > >>>>>> other things, > >>>>>> a way for a SRC to establish a new RS to continue a > >>>> recording in the > >>>>>> event something goes wrong with initial RS. It also > >> facilitates > >>>> having > >>>>>> multiple SRCs participate in the same recording, which we > >>>>>> agreed was out > >>>>>> of scope, but is at least possible if a recording exists > >>>> outside of > >>>> an > >>>>>> RS. > >>>>>> I suppose the argument could be made this is not really > >> necessary. > >>>>>> Rather, one could, outside of the scope of SIPREC, decide to > >>>> associate > >>>>>> multiple RSs in various ways, including stitching them > >>>>>> together for the > >>>>>> purpose of failover or distributed recordings. Is that what > >>>>>> you have in > >>>>>> mind? > >>>>>> > >>>>>> Cheers, > >>>>>> Charles > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Elwell, John > >> [mailto:john.elwell@siemens-enterprise.com] > >>>>>>> Sent: Saturday, April 30, 2011 3:12 AM > >>>>>>> To: Paul Kyzivat (pkyzivat); Charles Eckel (eckelcu) > >>>>>>> Cc: Parthasarathi R (partr); siprec@ietf.org > >>>>>>> Subject: RE: [siprec] RS to CS relationship as an attribute > >>>>>> inRecording block > >>>>>>> > >>>>>>> I am confused, because this thread has suddenly started to > >>>>>> talk about > >>>>>> a "recording", whereas metadata- > >>>>>>> 00 has an object called "Recording Session", which > >>>> 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 > >>>>>>> relationship with an RS, and therefore a single SIP > >> dialog, I > >>>> would > >>>>>> suggest they articulate why this > >>>>>>> would be needed, with a view to getting it into the metadata > >>>> model. > >>>>>>> > >>>>>>> John > >>>>>>> > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>>>>>>> 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 > >>>>>>>> inRecording block > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> 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 > >>>>>>>>> > >>>>>>>> > >>>>>> > >>>> > >> > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From john.elwell@siemens-enterprise.com Wed May 4 06:40:15 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51FCBE0799 for ; Wed, 4 May 2011 06:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.169 X-Spam-Level: X-Spam-Status: No, score=-105.169 tagged_above=-999 required=5 tests=[AWL=1.430, 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 u6qzkfkbOBtc for ; Wed, 4 May 2011 06:40:13 -0700 (PDT) Received: from mail21.messagelabs.com (mail21.messagelabs.com [85.158.143.35]) by ietfa.amsl.com (Postfix) with SMTP id E5914E06BA for ; Wed, 4 May 2011 06:40:12 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-6.tower-21.messagelabs.com!1304516425!23025410!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 32649 invoked from network); 4 May 2011 13:40:25 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-6.tower-21.messagelabs.com with SMTP; 4 May 2011 13:40:25 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 29EDD23F03DB; Wed, 4 May 2011 15:40:11 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 4 May 2011 15:40:11 +0200 From: "Elwell, John" To: "Ram Mohan R (rmohanr)" , "Paul Kyzivat (pkyzivat)" Date: Wed, 4 May 2011 15:40:08 +0200 Thread-Topic: [siprec] RS to CS relationship as an attribute inRecording block Thread-Index: AcwJ+biFoOO41i/hQIKAJCEft7se1gAVN5rwAARo/LA= Message-ID: References: <4DB58BC7.5090603@cisco.com><4DB820DA.1080200@cisco.com><4DBB59E2.9040200@cisco.com> <4DC0AA33.80205@cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD0635764C@XMB-BGL-417.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD0635764C@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] 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: Wed, 04 May 2011 13:40:15 -0000 Ram, If we don't think a Recording object is needed for the case that Charles de= scribes, fine. But I would also argue that we don't need a Recording Sessio= n object. John (as individual) > -----Original Message----- > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > Sent: 04 May 2011 12:51 > To: Paul Kyzivat (pkyzivat); Elwell, John > Cc: siprec@ietf.org > Subject: RE: [siprec] RS to CS relationship as an attribute > inRecording block > > I agree with Paul here. > The below use-case that Charles mentions is a good example of two SRCs > recording the same CS simultaneously via different RS. > In these cases these are two Recording Sessions each > recording the same > CS and the current model is sufficient for the same. > > John, > > so I don't see a need to change "Recording Session" to "Recording" > object in the model. Or are you talking here about grouping of > recordings ? > > As Paul mentioned it will only be recognized as the same CS > only if the > two SRCs coordinate among themselves to use the same UUID for it. > Otherwise we will get two recordings. > > Ram > > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Paul Kyzivat (pkyzivat) > > Sent: Wednesday, May 04, 2011 6:52 AM > > To: Elwell, John > > Cc: siprec@ietf.org > > Subject: Re: [siprec] RS to CS relationship as an attribute > inRecording > > block > > > > Of course this could be accomplished simply by dumb luck: > > > > If you and I have separate SRCs and are asking for separate > recordings > > of the "same" CS, it will only be recognized as the same CS > if the two > > SRCs coordinate among themselves to use the same UUID for > it. If they > > don't (likely in this case) the SRS with thing it is two CSs and so > you > > get two recodings. > > > > Thanks, > > Paul > > > > On 5/3/2011 4:33 PM, Elwell, John wrote: > > > In that case, I would assert that we need a "Recording" object in > the > > metadata model, not a "Recording Session" object. > > > > > > John > > > > > >> -----Original Message----- > > >> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > >> Sent: 03 May 2011 21:25 > > >> To: Elwell, John; Paul Kyzivat (pkyzivat) > > >> Cc: Parthasarathi R (partr); siprec@ietf.org > > >> Subject: RE: [siprec] RS to CS relationship as an attribute > > >> inRecording block > > >> > > >> Because one is mine and the other is yours and you want to > > >> record yours > > >> in one format and in combination with other CSs, and I > want mine in > > >> another format and with other CSs. > > >> For example you want yours recorded a single mixed audio and > > >> composited > > >> video stream, and I want all separate streams. > > >> > > >> Cheers, > > >> Charles > > >> > > >>> -----Original Message----- > > >>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > >>> Sent: Tuesday, May 03, 2011 12:55 PM > > >>> To: Charles Eckel (eckelcu); Paul Kyzivat (pkyzivat) > > >>> Cc: Parthasarathi R (partr); siprec@ietf.org > > >>> Subject: RE: [siprec] RS to CS relationship as an attribute > > >> inRecording block > > >>> > > >>> Why would I want two recordings of the same CS at the same SRS? > > >>> > > >>> John > > >>> > > >>>> -----Original Message----- > > >>>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > >>>> Sent: 03 May 2011 17:56 > > >>>> To: Elwell, John; Paul Kyzivat (pkyzivat) > > >>>> Cc: Parthasarathi R (partr); siprec@ietf.org > > >>>> Subject: RE: [siprec] RS to CS relationship as an attribute > > >>>> inRecording block > > >>>> > > >>>> I do not think the CS is sufficient. For example, how do > > >> you know if > > >> I > > >>>> want another recording of the same CS, or a single recording? > > >>>> > > >>>> Cheers, > > >>>> Charles > > >>>> > > >>>>> -----Original Message----- > > >>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > >>>>> Sent: Tuesday, May 03, 2011 9:39 AM > > >>>>> To: Charles Eckel (eckelcu); Paul Kyzivat (pkyzivat) > > >>>>> Cc: Parthasarathi R (partr); siprec@ietf.org > > >>>>> Subject: RE: [siprec] RS to CS relationship as an attribute > > >>>> inRecording block > > >>>>> > > >>>>> I saw a "recording" as being as being a recording of a > > >> CS. So yes, > > >> a > > >>>> recording can exist outside of an > > >>>>> RS, and might even span multiple RSs, but doesn't the CS > > >>>> object cover > > >>>> this? > > >>>>> > > >>>>> John > > >>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > >>>>>> Sent: 02 May 2011 14:34 > > >>>>>> To: Elwell, John; Paul Kyzivat (pkyzivat) > > >>>>>> Cc: Parthasarathi R (partr); siprec@ietf.org > > >>>>>> Subject: RE: [siprec] RS to CS relationship as an attribute > > >>>>>> inRecording block > > >>>>>> > > >>>>>> Hi John, > > >>>>>> > > >>>>>> Having a recording exist outside of the RS provides, among > > >>>>>> other things, > > >>>>>> a way for a SRC to establish a new RS to continue a > > >>>> recording in the > > >>>>>> event something goes wrong with initial RS. It also > > >> facilitates > > >>>> having > > >>>>>> multiple SRCs participate in the same recording, which we > > >>>>>> agreed was out > > >>>>>> of scope, but is at least possible if a recording exists > > >>>> outside of > > >>>> an > > >>>>>> RS. > > >>>>>> I suppose the argument could be made this is not really > > >> necessary. > > >>>>>> Rather, one could, outside of the scope of SIPREC, decide to > > >>>> associate > > >>>>>> multiple RSs in various ways, including stitching them > > >>>>>> together for the > > >>>>>> purpose of failover or distributed recordings. Is that what > > >>>>>> you have in > > >>>>>> mind? > > >>>>>> > > >>>>>> Cheers, > > >>>>>> Charles > > >>>>>> > > >>>>>>> -----Original Message----- > > >>>>>>> From: Elwell, John > > >> [mailto:john.elwell@siemens-enterprise.com] > > >>>>>>> Sent: Saturday, April 30, 2011 3:12 AM > > >>>>>>> To: Paul Kyzivat (pkyzivat); Charles Eckel (eckelcu) > > >>>>>>> Cc: Parthasarathi R (partr); siprec@ietf.org > > >>>>>>> Subject: RE: [siprec] RS to CS relationship as an attribute > > >>>>>> inRecording block > > >>>>>>> > > >>>>>>> I am confused, because this thread has suddenly started to > > >>>>>> talk about > > >>>>>> a "recording", whereas metadata- > > >>>>>>> 00 has an object called "Recording Session", which > > >>>> 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 > > >>>>>>> relationship with an RS, and therefore a single SIP > > >> dialog, I > > >>>> would > > >>>>>> suggest they articulate why this > > >>>>>>> would be needed, with a view to getting it into the metadata > > >>>> model. > > >>>>>>> > > >>>>>>> John > > >>>>>>> > > >>>>>>> > > >>>>>>>> -----Original Message----- > > >>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > >>>>>>>> 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 > > >>>>>>>> inRecording block > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> 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 > > >>>>>>>>> > > >>>>>>>> > > >>>>>> > > >>>> > > >> > > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > From Henry.Lum@alcatel-lucent.com Wed May 4 08:25: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 7948CE07A1 for ; Wed, 4 May 2011 08:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.985 X-Spam-Level: X-Spam-Status: No, score=-5.985 tagged_above=-999 required=5 tests=[AWL=0.614, 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 A-8EgRcypeqd for ; Wed, 4 May 2011 08:25:09 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3ACF6E0740 for ; Wed, 4 May 2011 08:25:08 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p44FP7or026426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 4 May 2011 10:25:07 -0500 (CDT) Received: from relay-out2.dc (relay-out2.dc.genesyslab.com [172.22.68.188]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p44FP5bU012314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 4 May 2011 10:25:07 -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 p44FP5Yn005472 for ; Wed, 4 May 2011 08:25: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); Wed, 4 May 2011 08:25:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Wed, 4 May 2011 08:24:57 -0700 Message-ID: <059AF07365DC474393A19A3AF187DF74070294C9@NAHALD.us.int.genesyslab.com> In-Reply-To: <20110504152410.25362.33625.idtracker@ietfa.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-portman-siprec-protocol-04.txt Thread-Index: AcwKb1KobIcAERSRS46OmJCN0KcmvwAABILg References: <20110504152410.25362.33625.idtracker@ietfa.amsl.com> From: "Henry Lum" To: X-OriginalArrivalTime: 04 May 2011 15:25:05.0025 (UTC) FILETIME=[7196AF10:01CC0A6F] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: [siprec] FW: New Version Notification for draft-portman-siprec-protocol-04.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 15:25:09 -0000 DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogTWF5LTA0LTEx IDExOjI0IEFNDQpUbzogSGVucnkgTHVtDQpDYzogSGVucnkgTHVtOyBsZW9uLnBvcnRtYW5Abmlj ZS5jb207IGFsYW4uYi5qb2huc3RvbkBnbWFpbC5jb207IGFuZHJldy5odXR0b25Ac2llbWVucy1l bnRlcnByaXNlLmNvbQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFm dC1wb3J0bWFuLXNpcHJlYy1wcm90b2NvbC0wNC50eHQNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQs IGRyYWZ0LXBvcnRtYW4tc2lwcmVjLXByb3RvY29sLTA0LnR4dCBoYXMgYmVlbiBzdWNjZXNzZnVs bHkgc3VibWl0dGVkIGJ5IEhlbnJ5IEx1bSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRv cnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtcG9ydG1hbi1zaXByZWMtcHJvdG9jb2wNClJldmlzaW9u OgkgMDQNClRpdGxlOgkJIFNlc3Npb24gUmVjb3JkaW5nIFByb3RvY29sDQpDcmVhdGlvbiBkYXRl OgkgMjAxMS0wNS0wMw0KV0cgSUQ6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2Yg cGFnZXM6IDIwDQoNCkFic3RyYWN0Og0KICAgVGhlIFNlc3Npb24gUmVjb3JkaW5nIFByb3RvY29s IGlzIHVzZWQgZm9yIGVzdGFibGlzaGluZyByZWNvcmRpbmcNCiAgIHNlc3Npb24gYW5kIHJlcG9y dGluZyBvZiB0aGUgbWV0YWRhdGEgb2YgdGhlIGNvbW11bmljYXRpb24gc2Vzc2lvbi4NCg0KICAg VGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgdGhlIFNlc3Npb24gUmVjb3JkaW5nIFByb3RvY29sLiAg VGhlIHByb3RvY29sDQogICBpcyB1c2VkIGJldHdlZW4gU2Vzc2lvbiBSZWNvcmRpbmcgQ2xpZW50 IChTUkMpIGFuZCBTZXNzaW9uIFJlY29yZGluZw0KICAgU2VydmVyIChTUlMpLg0KDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KCQkJCQkNCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N CkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZS1tYWlsIGFuZCBhbnkgZmlsZXMgYXR0YWNo ZWQgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbiBv ZiBBbGNhdGVsLUx1Y2VudCBhbmQvb3IgaXRzIGFmZmlsaWF0ZWQgZW50aXRpZXMuIEFjY2VzcyBi eSB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9ubHkgaXMgYXV0aG9yaXplZC4gQW55IGxpYWJpbGl0 eSBhcmlzaW5nIGZyb20gYW55IHBhcnR5IGFjdGluZywgb3IgcmVmcmFpbmluZyBmcm9tIGFjdGlu Zywgb24gYW55IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGUtbWFpbCBpcyBoZXJlYnkg ZXhjbHVkZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBu b3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSwgZGVzdHJveSB0aGUgb3JpZ2luYWwgdHJhbnNt aXNzaW9uIGFuZCBpdHMgYXR0YWNobWVudHMgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVu dHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUg b3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gQ29weXJpZ2h0IGluIHRoaXMg ZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYmVsb25ncyB0byBBbGNhdGVsLUx1Y2VudCBhbmQv b3IgaXRzIGFmZmlsaWF0ZWQgZW50aXRpZXMuDQoJCQkJCQ0K From eckelcu@cisco.com Wed May 4 16:17:22 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 320A7E0820 for ; Wed, 4 May 2011 16:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.473 X-Spam-Level: X-Spam-Status: No, score=-10.473 tagged_above=-999 required=5 tests=[AWL=0.126, 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 QVJvjJoKMeKO for ; Wed, 4 May 2011 16:17:20 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by ietfa.amsl.com (Postfix) with ESMTP id DEA0FE081C for ; Wed, 4 May 2011 16:17:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=14407; q=dns/txt; s=iport; t=1304551040; x=1305760640; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=JCfjxrdqwIg+CUzWm7WWND7Oi6Uz/46Pm4uPfqN8X98=; b=h+yZOsPM6ABcOYW01YdFLrMx6RRZQdB5CK+s3jSgaaAUPK3kAu7sw3dQ MzjqaaWA5DtVmffj65QZTPHojYSxy4Qm4YC6xv9CClrz0s3gN5BqST369 uZ7uf3SSW34IE9PNFQz+JFD+ClRu/F0SF/ew8Okl899BK84BDHEwqbnPt A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnoBAJLdwU2rRDoH/2dsb2JhbACYD44Qd6llnimDCoJ9BIYvjSuKNQ X-IronPort-AV: E=Sophos;i="4.64,317,1301875200"; d="scan'208";a="355484530" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-5.cisco.com with ESMTP; 04 May 2011 23:17:20 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p44NGxWM025066; Wed, 4 May 2011 23:16:59 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); Wed, 4 May 2011 16:16:59 -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, 4 May 2011 16:16:58 -0700 Message-ID: In-Reply-To: <059AF07365DC474393A19A3AF187DF74070292B2@NAHALD.us.int.genesyslab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] summary of changes for draft-portman-siprec-protocol-04 Thread-Index: AcwIaR0YuGqr5XvNSMqltXB+NekCpQBR+yhgAAMNUZAAPOGiUA== References: <059AF07365DC474393A19A3AF187DF7407028E4B@NAHALD.us.int.genesyslab.com> <059AF07365DC474393A19A3AF187DF74070292B2@NAHALD.us.int.genesyslab.com> From: "Charles Eckel (eckelcu)" To: "Henry Lum" , "Elwell, John" , X-OriginalArrivalTime: 04 May 2011 23:16:59.0479 (UTC) FILETIME=[5E517E70:01CC0AB1] Subject: Re: [siprec] summary of changes for draft-portman-siprec-protocol-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, 04 May 2011 23:17:22 -0000 I intended to put together a draft covering RTP recommendations and models. Unfortunately, I did not have enough bandwidth to get this done in time for the interim meeting. Instead, I have attached my thoughts to get some feedback. I would be happy to continue work in this area if people think it is useful.=20 ------------------- Version 0.2 April 26, 2011 (1) Introduction This document provides recommendations and guidelines for RTP and RTCP in the context of SIPREC. In order to communicate most effectively, the Session Recording Client (SRC) and the Session Recording (SRS) should utilize the mechanisms provided by RTP in a well defined and predicable manner. It is the goal of this document to make the reader aware of these mechanisms and provide recommendations and guidelines. This document is completely informational. It includes no requirements and no normative language.=20 (2) Definitions This document uses the definitions provided in draft-ietf-siprec-architecture for all SIPREC modules. A Session Recording Client (SRC), as defined within SIPREC, is expected to implement one or more of a variety of RTP roles within the context of various SIPREC use cases. These roles include, but are not limited to, acting as an end system, a mixer, or a translator. This document uses the definitions provided in "RTP: A Transport Protocol for Real-Time Application" [RFC 3550] for these roles.=20 (3) RTCP The RTP data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery. RTCP, as defined in [RFC3550], is based on the periodic transmission of control packets to all participants in the RTP session, using the same distribution mechanism as the data packets.=20 Support for RTCP is recommended as it provides, among other things, the following important functionality in relation to SIPREC: 1) Feedback on the quality of the data distribution. This feedback is important for flow and congestion control functions, and to get feedback from the receivers to diagnose faults in the distribution. As such, RTCP is a well defined and efficient mechanism for the SRS to inform the SRC or any issues that arise in the reception of media that is to be recorded.=20 2) Carries a persistent transport-level identifier for an RTP source called the canonical name or CNAME. The SSRC identifier may change if a conflict is discovered or a program is restarted; in which case receivers can use the CNAME to keep track of each participant. Receivers may also use the CNAME to associate multiple data streams from a given participant in a set of related RTP sessions, for example to synchronize audio and video. Synchronization of media streams is also facilitated by the NTP and RTP timestamps included in RTCP packets by data senders. (4) RTP Profile The recommended RTP profiles for both the SRC and SRS are "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)", [RFC5124] when using encrypted RTP streams, and "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", [RFC4585] when using non encrypted media streams. However, as this is not a requirement, some implementations may use "The Secure Real-time Transport Protocol (SRTP)", [RFC 3711] and "RTP Profile for Audio and Video Conferences with Minimal Control", AVP [RFC 3551]. Therefore, it is recommended that the SRC and SRS not rely entirely on SAVPF or AVPF for core functionality that may be at least partially achievable using SAVP and AVP. AVPF and SAVPF provide an improved RTCP timer model that allows more flexible transmission of RTCP packets as response to events, rather than strictly according to bandwidth. SAVP and SAVPF provide media encryption, integrity protection, replay protection, and a limited form of source authentication. They do not contain or require a specific keying mechanism. (5) SRSC The synchronization source (SSRC), as defined in [RFC3550], is carried in the RTP header and in various fields of RTCP packets. It is a random 32-bit number that is required to be globally unique within an RTP session. It is crucial that the number be chosen with care in order that participants on the same network or starting at the same time are not likely to choose the same number. Guidelines regarding SSRC value selection and conflict resolution are provided in [RFC3550]. The SSRC may also be used to separate different sources of media within a single RTP session. For this reason as well as for conflict resolution, it is important that the SRC and SRC handle changes in SSRC values and properly identify the reason of the change. The CNAME values carried in RTCP facilitate this identification. (6) CSRC The contributing source (CSRC), as defined in [RFC3550], identifies the source of a stream of RTP packets that has contributed to the combined stream produced by an RTP mixer. The mixer inserts a list of the SSRC identifiers of the sources that contributed to the generation of a particular packet into the RTP header of that packet. This list is called the CSRC list. It is recommended that a SRC, when acting a mixer, sets the CSRC list accordingly, and that the SRS interprets the CSRC list appropriately when received. (7) SDES The Source Description (SDES), as defined in [RFC3550], contains an SSRC/CSRC identifier followed by a list of zero or more items, which carry information about the SSRC/CSRC. End systems send one SDES packet containing their own source identifier (the same as the SSRC in the fixed RTP header). A mixer sends one SDES packet containing a chunk for each contributing source from which it is receiving SDES information, or multiple complete SDES packets. (8) CNAME The Canonical End-Point Identifier (CNAME), as defined in [RFC3550], provide the binding from the SSRC identifier to an identifier for the source (sender or receiver) that remains constant. It is important the an SRC and SRS generate CNAMEs appropriately and use them for this purpose. Guidelines for generating CNAME values are provided in "Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)" [RFC6222]. (9) Keepalive It is anticipated that media streams in SIPREC may exist in inactive states for extended periods of times for an of a number of valid reasons. In order to the bindings and any pinholes in NATs/firewalls to remain active during such intervals, it is recommended to follow the keep-alive procedures in "Application Mechanism for keeping alive the Network Address Translator =20 (NAT) mappings associated to RTP/RTCP flows", [draft-ietf-avt-app-rtp-keepalive] for all RTP media streams.=20 (10) RTCP Feedback Messages "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)" [RFC 5104] specifies extensions to the messages defined in AVPF [RFC4585]. Support for and proper usage of these messages is important to SRC and SRS implementations. (10.1) Full Intra Request=20 A Full Intra Request (FIR) Command, when received by the designate media sender, requires that the media sender sends a Decoder Refresh Point at the earliest opportunity. Using a decoder refresh point implies refraining from using any picture sent prior to that point as a reference for the encoding process of any subsequent picture sent in the stream. Decoder refresh points, especially Intra or IDR pictures for H.264 video codecs, are in general several times larger in size than predicted pictures. Thus, in scenarios in which the available bit rate is small, the use of a decoder refresh point implies a delay that is significantly longer than the typical picture duration. (10.1.1) SIP INFO for FIR "XML Schema for Media Control" [RFC5168] defines an Extensible Markup Language (XML) Schema for video fast update. Implementations are discouraged from using the method described except for backward compatibility purposes. Implementations should use FIR messages, as described in (10.1) instead. (10.2) Picture Loss Indicator Using the FIR command to recover from errors is explicitly disallowed, and instead the PLI message defined in AVPF [RFC4585] should be used. The PLI message reports lost pictures and has been included in AVPF for precisely that purpose. (10.3) Temporary Maximum Media Stream Bit Rate Request A receiver, translator, or mixer uses the Temporary Maximum Media Stream Bit Rate Request (TMMBR) to request a sender to limit the maximum bit rate for a media stream to the provided value. Appropriate use of TMMBR facilitates rapid adaptation to changes in available bandwidth.=20 (10.3.1) Renegotiation of SDP bandwidth attribute If it is likely that the new value indicated by TMMBR will be valid for the remainder of the session, the TMMBR sender is expected to perform a renegotiation of the session upper limit using the session signaling protocol. Therefore for SIPREC, implementations are recommended to use TMMBR for temporary changes, and renegotiation of bandwidth via SDP offer/answer of more permanent changes. (11) Symmetric RTP/RTCP Within the SDP offer/answer, RTP entities choose the RTP and RTCP transport addresses (i.e., IP addresses and port numbers) on which to receive packets. When sending RTP packets; however, they may use a different IP address or port number for RTP, RTCP, or both. Symmetric RTP/RTCP requires that the IP address and port number for sending and receiving RTP/RTCP packets are identical. Using Symmetric RTP and RTCP [RFC4961] is recommended. --------------------- Cheers, Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Henry Lum > Sent: Tuesday, May 03, 2011 11:18 AM > To: Elwell, John; siprec@ietf.org > Subject: Re: [siprec] summary of changes for draft-portman-siprec-protocol-04 >=20 > Hi John, >=20 > Okay, let's discuss this topic further in the interim meeting to > determine whether there is any need to specify any protocol related > changes. >=20 > Regards, > Henry >=20 > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Tuesday, May 03, 2011 12:44 PM > > To: Henry Lum; siprec@ietf.org > > Subject: RE: summary of changes for draft-portman-siprec-protocol-04 > > > > Henry, > > > > Concerning the RTP model, I agree that the consensus to date seems to > > be to cover different RTP models, but I feel we should get something > > into the architecture draft to start with, and then later see whether > > there is any impact on the protocol draft. > > > > John > > > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Henry Lum > > > Sent: 02 May 2011 04:09 > > > To: siprec@ietf.org > > > Subject: [siprec] summary of changes for > > > draft-portman-siprec-protocol-04 > > > > > > Hi, > > > > > > > > > > > > I want to summarize the list of changes we are planning to > > > include in the next revision of the document: > > > > > > > > > > > > - Remove use of INFO > > > > > > - Both INVITE or UPDATE can be used for metadata > > > transport through content-disposition > > > > > > - Recording indication is placed at SDP media level > > > > > > - Recording awareness is indicated at SIP level with > > > options; feature tag was also considered > > > > > > - Recording preference is placed at SDP media level > > > > > > - RTP model discussion and time synchronization; so > > > far we seem to agree to handle different RTP models rather > > > than requiring a single model. There are 3 models we have > > > identified so far: > > > > > > o RTP mixer - SRC mixes media streams and can directly > > > synchronize timestamps with metadata and also generate RTCP > > > > > > o RTP translator - Media streams are simply forwarded to > > > the SRS by the SRC. SRC is only capable to indicating > > > start/stop times to the SRS in metadata. > > > > > > o RTP endpoint (is that the right term?) - SRC is neither a > > > mixer nor translator, but is capable of rewriting RTP and > > > RTCP in order to synchronize on the timestamps with metadata. > > > > > > > > > > > > Regards, > > > > > > Henry > > > > > > > > > > > > > > > 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 >=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 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From Leon.Portman@nice.com Wed May 4 23:59:40 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35E56E06D1 for ; Wed, 4 May 2011 23:59:40 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lb8+lOx3T-GW for ; Wed, 4 May 2011 23:59:38 -0700 (PDT) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id A4F7BE0651 for ; Wed, 4 May 2011 23:59:37 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Thu, 5 May 2011 09:59:34 +0300 From: Leon Portman To: "Charles Eckel (eckelcu)" , Henry Lum , "Elwell, John" , "siprec@ietf.org" Date: Thu, 5 May 2011 09:59:33 +0300 Thread-Topic: [siprec] summary of changes for draft-portman-siprec-protocol-04 Thread-Index: AcwIaR0YuGqr5XvNSMqltXB+NekCpQBR+yhgAAMNUZAAPOGiUAAQSSSw Message-ID: <07465C1D981ABC41A344374066AE1A2C38AB8483D6@TLVMBX01.nice.com> References: <059AF07365DC474393A19A3AF187DF7407028E4B@NAHALD.us.int.genesyslab.com> <059AF07365DC474393A19A3AF187DF74070292B2@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] summary of changes for draft-portman-siprec-protocol-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, 05 May 2011 06:59:40 -0000 Charles Hi I think it is very important and helpful. Regards Leon -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Charles Eckel (eckelcu) Sent: Thursday, May 05, 2011 2:17 AM To: Henry Lum; Elwell, John; siprec@ietf.org Subject: Re: [siprec] summary of changes for draft-portman-siprec-protocol-= 04 I intended to put together a draft covering RTP recommendations and models.= Unfortunately, I did not have enough bandwidth to get this done in time fo= r the interim meeting. Instead, I have attached my thoughts to get some fee= dback. I would be happy to continue work in this area if people think it is= useful.=20 ------------------- Version 0.2 April 26, 2011 (1) Introduction This document provides recommendations and guidelines for RTP and RTCP in t= he context of SIPREC. In order to communicate most effectively, the Session= Recording Client (SRC) and the Session Recording (SRS) should utilize the = mechanisms provided by RTP in a well defined and predicable manner. It is t= he goal of this document to make the reader aware of these mechanisms and p= rovide recommendations and guidelines. This document is completely informat= ional. It includes no requirements and no normative language.=20 (2) Definitions This document uses the definitions provided in draft-ietf-siprec-architectu= re for all SIPREC modules. A Session Recording Client (SRC), as defined wit= hin SIPREC, is expected to implement one or more of a variety of RTP roles = within the context of various SIPREC use cases. These roles include, but ar= e not limited to, acting as an end system, a mixer, or a translator. This d= ocument uses the definitions provided in "RTP: A Transport Protocol for Rea= l-Time Application" [RFC 3550] for these roles.=20 (3) RTCP The RTP data transport is augmented by a control protocol (RTCP) to allow m= onitoring of the data delivery. RTCP, as defined in [RFC3550], is based on = the periodic transmission of control packets to all participants in the RTP= session, using the same distribution mechanism as the data packets.=20 Support for RTCP is recommended as it provides, among other things, the fol= lowing important functionality in relation to SIPREC: 1) Feedback on the quality of the data distribution. This feedback is impor= tant for flow and congestion control functions, and to get feedback from th= e receivers to diagnose faults in the distribution. As such, RTCP is a well= defined and efficient mechanism for the SRS to inform the SRC or any issue= s that arise in the reception of media that is to be recorded.=20 2) Carries a persistent transport-level identifier for an RTP source called= the canonical name or CNAME. The SSRC identifier may change if a conflict = is discovered or a program is restarted; in which case receivers can use th= e CNAME to keep track of each participant. Receivers may also use the CNAME to associate multiple data streams from a = given participant in a set of related RTP sessions, for example to synchron= ize audio and video. Synchronization of media streams is also facilitated b= y the NTP and RTP timestamps included in RTCP packets by data senders. (4) RTP Profile The recommended RTP profiles for both the SRC and SRS are "Extended Secure = RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback = (RTP/SAVPF)", [RFC5124] when using encrypted RTP streams, and "Extended RTP= Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RT= P/AVPF)", [RFC4585] when using non encrypted media streams. However, as thi= s is not a requirement, some implementations may use "The Secure Real-time = Transport Protocol (SRTP)", [RFC 3711] and "RTP Profile for Audio and Video= Conferences with Minimal Control", AVP [RFC 3551]. Therefore, it is recomm= ended that the SRC and SRS not rely entirely on SAVPF or AVPF for core func= tionality that may be at least partially achievable using SAVP and AVP. AVPF and SAVPF provide an improved RTCP timer model that allows more flexib= le transmission of RTCP packets as response to events, rather than strictly= according to bandwidth. SAVP and SAVPF provide media encryption, integrity protection, replay prote= ction, and a limited form of source authentication. They do not contain or = require a specific keying mechanism. (5) SRSC The synchronization source (SSRC), as defined in [RFC3550], is carried in t= he RTP header and in various fields of RTCP packets. It is a random 32-bit = number that is required to be globally unique within an RTP session. It is= crucial that the number be chosen with care in order that participants on = the same network or starting at the same time are not likely to choose the = same number. Guidelines regarding SSRC value selection and conflict resolut= ion are provided in [RFC3550]. The SSRC may also be used to separate different sources of media within a s= ingle RTP session. For this reason as well as for conflict resolution, it i= s important that the SRC and SRC handle changes in SSRC values and properly= identify the reason of the change. The CNAME values carried in RTCP facili= tate this identification. (6) CSRC The contributing source (CSRC), as defined in [RFC3550], identifies the sou= rce of a stream of RTP packets that has contributed to the combined stream = produced by an RTP mixer. The mixer inserts a list of the SSRC identifiers = of the sources that contributed to the generation of a particular packet in= to the RTP header of that packet. This list is called the CSRC list. It is = recommended that a SRC, when acting a mixer, sets the CSRC list accordingly= , and that the SRS interprets the CSRC list appropriately when received. (7) SDES The Source Description (SDES), as defined in [RFC3550], contains an SSRC/CS= RC identifier followed by a list of zero or more items, which carry informa= tion about the SSRC/CSRC. End systems send one SDES packet containing their= own source identifier (the same as the SSRC in the fixed RTP header). A m= ixer sends one SDES packet containing a chunk for each contributing source = from which it is receiving SDES information, or multiple complete SDES pack= ets. (8) CNAME The Canonical End-Point Identifier (CNAME), as defined in [RFC3550], provid= e the binding from the SSRC identifier to an identifier for the source (se= nder or receiver) that remains constant. It is important the an SRC and SR= S generate CNAMEs appropriately and use them for this purpose. Guidelines f= or generating CNAME values are provided in "Guidelines for Choosing RTP Con= trol Protocol (RTCP) Canonical Names (CNAMEs)" [RFC6222]. (9) Keepalive It is anticipated that media streams in SIPREC may exist in inactive states= for extended periods of times for an of a number of valid reasons. In orde= r to the bindings and any pinholes in NATs/firewalls to remain active durin= g such intervals, it is recommended to follow the keep-alive procedures in = "Application Mechanism for keeping alive the Network Address Translator =20 (NAT) mappings associated to RTP/RTCP flows", [draft-ietf-avt-app-rtp-keepa= live] for all RTP media streams.=20 (10) RTCP Feedback Messages "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF= )" [RFC 5104] specifies extensions to the messages defined in AVPF [RFC4585= ]. Support for and proper usage of these messages is important to SRC and S= RS implementations. (10.1) Full Intra Request=20 A Full Intra Request (FIR) Command, when received by the designate media se= nder, requires that the media sender sends a Decoder Refresh Point at the e= arliest opportunity. Using a decoder refresh point implies refraining from = using any picture sent prior to that point as a reference for the encoding = process of any subsequent picture sent in the stream. Decoder refresh points, especially Intra or IDR pictures for H.264 video co= decs, are in general several times larger in size than predicted pictures. = Thus, in scenarios in which the available bit rate is small, the use of a d= ecoder refresh point implies a delay that is significantly longer than the = typical picture duration. (10.1.1) SIP INFO for FIR "XML Schema for Media Control" [RFC5168] defines an Extensible Markup Langu= age (XML) Schema for video fast update. Implementations are discouraged fro= m using the method described except for backward compatibility purposes. Im= plementations should use FIR messages, as described in (10.1) instead. (10.2) Picture Loss Indicator Using the FIR command to recover from errors is explicitly disallowed, and = instead the PLI message defined in AVPF [RFC4585] should be used. The PLI message reports lost pictures and has been included in AVPF for pre= cisely that purpose. (10.3) Temporary Maximum Media Stream Bit Rate Request A receiver, translator, or mixer uses the Temporary Maximum Media Stream Bi= t Rate Request (TMMBR) to request a sender to limit the maximum bit rate fo= r a media stream to the provided value. Appropriate use of TMMBR facilitate= s rapid adaptation to changes in available bandwidth.=20 (10.3.1) Renegotiation of SDP bandwidth attribute If it is likely that the new value indicated by TMMBR will be valid for the= remainder of the session, the TMMBR sender is expected to perform a renego= tiation of the session upper limit using the session signaling protocol. Th= erefore for SIPREC, implementations are recommended to use TMMBR for tempor= ary changes, and renegotiation of bandwidth via SDP offer/answer of more pe= rmanent changes. (11) Symmetric RTP/RTCP Within the SDP offer/answer, RTP entities choose the RTP and RTCP transport= addresses (i.e., IP addresses and port numbers) on which to receive packet= s. When sending RTP packets; however, they may use a different IP address o= r port number for RTP, RTCP, or both. Symmetric RTP/RTCP requires that the= IP address and port number for sending and receiving RTP/RTCP packets are = identical. Using Symmetric RTP and RTCP [RFC4961] is recommended. --------------------- Cheers, Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Henry Lum > Sent: Tuesday, May 03, 2011 11:18 AM > To: Elwell, John; siprec@ietf.org > Subject: Re: [siprec] summary of changes for draft-portman-siprec-protocol-04 >=20 > Hi John, >=20 > Okay, let's discuss this topic further in the interim meeting to=20 > determine whether there is any need to specify any protocol related=20 > changes. >=20 > Regards, > Henry >=20 > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Tuesday, May 03, 2011 12:44 PM > > To: Henry Lum; siprec@ietf.org > > Subject: RE: summary of changes for draft-portman-siprec-protocol-04 > > > > Henry, > > > > Concerning the RTP model, I agree that the consensus to date seems to > > be to cover different RTP models, but I feel we should get something=20 > > into the architecture draft to start with, and then later see whether > > there is any impact on the protocol draft. > > > > John > > > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Henry Lum > > > Sent: 02 May 2011 04:09 > > > To: siprec@ietf.org > > > Subject: [siprec] summary of changes for > > > draft-portman-siprec-protocol-04 > > > > > > Hi, > > > > > > > > > > > > I want to summarize the list of changes we are planning to include=20 > > > in the next revision of the document: > > > > > > > > > > > > - Remove use of INFO > > > > > > - Both INVITE or UPDATE can be used for metadata > > > transport through content-disposition > > > > > > - Recording indication is placed at SDP media level > > > > > > - Recording awareness is indicated at SIP level with > > > options; feature tag was also considered > > > > > > - Recording preference is placed at SDP media level > > > > > > - RTP model discussion and time synchronization; so > > > far we seem to agree to handle different RTP models rather than=20 > > > requiring a single model. There are 3 models we have identified so=20 > > > far: > > > > > > o RTP mixer - SRC mixes media streams and can directly > > > synchronize timestamps with metadata and also generate RTCP > > > > > > o RTP translator - Media streams are simply forwarded to > > > the SRS by the SRC. SRC is only capable to indicating start/stop=20 > > > times to the SRS in metadata. > > > > > > o RTP endpoint (is that the right term?) - SRC is neither a > > > mixer nor translator, but is capable of rewriting RTP and RTCP in=20 > > > order to synchronize on the timestamps with metadata. > > > > > > > > > > > > Regards, > > > > > > Henry > > > > > > > > > > > > > > > CONFIDENTIALITY NOTICE: This e-mail and any files attached may=20 > > > contain confidential and proprietary information of Alcatel-Lucent=20 > > > and/or its affiliated entities. Access by the intended recipient=20 > > > only is authorized. Any liability arising from any party acting,=20 > > > or refraining from acting, on any information contained in this=20 > > > e-mail is hereby excluded. If you are not the intended recipient,=20 > > > please notify the sender immediately, destroy the original=20 > > > transmission and its attachments and do not disclose the contents=20 > > > to any other person, use it for any purpose, or store or copy the=20 > > > information in any medium. Copyright in this e-mail and any=20 > > > attachments belongs to Alcatel-Lucent and/or its affiliated > entities. > > > >=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 > _______________________________________________ > siprec mailing 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 May 5 02:37:29 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF17AE0845 for ; Thu, 5 May 2011 02:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.211 X-Spam-Level: X-Spam-Status: No, score=-105.211 tagged_above=-999 required=5 tests=[AWL=1.388, 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 sR5ONFCH+v+w for ; Thu, 5 May 2011 02:37:29 -0700 (PDT) Received: from mail21.messagelabs.com (mail21.messagelabs.com [85.158.143.35]) by ietfa.amsl.com (Postfix) with SMTP id C530EE084F for ; Thu, 5 May 2011 02:37:28 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1304588243!44366813!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 21219 invoked from network); 5 May 2011 09:37:23 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-14.tower-21.messagelabs.com with SMTP; 5 May 2011 09:37:23 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 99CDE1EB83ED for ; Thu, 5 May 2011 11:37:27 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 5 May 2011 11:37:27 +0200 From: "Elwell, John" To: "siprec@ietf.org" Date: Thu, 5 May 2011 11:37:26 +0200 Thread-Topic: I-D Action: draft-portman-siprec-protocol-04.txt Thread-Index: AcwKb3en29WlsLJjSQWCyOX159h+/AAl5jQA Message-ID: References: <20110504152410.25362.51406.idtracker@ietfa.amsl.com> In-Reply-To: <20110504152410.25362.51406.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] I-D Action: draft-portman-siprec-protocol-04.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 09:37:30 -0000 Leon, Henry and others, Thanks for doing this revision. One question: In 5.4.1 it states: "The format of the metadata snapshot request is described in [I-D.ietf-siprec-metadata]." I searched for this in the metadata draft (and also in the metadata-format = draft, which contains candidate material for merging into the metadata draf= t) and could find nothing, so I assume it is your intent that something sho= uld be added to the metadata draft. However, although the metadata model an= d its format should be specified in the metadata draft, a snapshot request = sounds to me like something more appropriate for the protocol draft. John > -----Original Message----- > From: i-d-announce-bounces@ietf.org=20 > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of=20 > internet-drafts@ietf.org > Sent: 04 May 2011 16:24 > To: i-d-announce@ietf.org > Subject: I-D Action: draft-portman-siprec-protocol-04.txt >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. >=20 > Title : Session Recording Protocol > Author(s) : Leon Portman > Henry Lum > Alan Johnston > Andrew Hutton > Filename : draft-portman-siprec-protocol-04.txt > Pages : 20 > Date : 2011-05-04 >=20 > The Session Recording Protocol is used for establishing recording > session and reporting of the metadata of the communication session. >=20 > This document specifies the Session Recording Protocol. =20 > The protocol > is used between Session Recording Client (SRC) and Session=20 > Recording > Server (SRS). >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-portman-siprec-proto > col-04.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-portman-siprec-protoc > ol-04.txt > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > = From andrew.hutton@siemens-enterprise.com Thu May 5 07:10:59 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69130E0782 for ; Thu, 5 May 2011 07:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, 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 jaxBL+gZQuln for ; Thu, 5 May 2011 07:10:58 -0700 (PDT) Received: from mail21.messagelabs.com (mail21.messagelabs.com [85.158.143.35]) by ietfa.amsl.com (Postfix) with SMTP id 557D4E076D for ; Thu, 5 May 2011 07:10:58 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: andrew.hutton@siemens-enterprise.com X-Msg-Ref: server-10.tower-21.messagelabs.com!1304604650!39256305!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 22384 invoked from network); 5 May 2011 14:10:50 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-10.tower-21.messagelabs.com with SMTP; 5 May 2011 14:10:50 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 4AB0C23F03DB; Thu, 5 May 2011 16:10:56 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 5 May 2011 16:10:56 +0200 From: "Hutton, Andrew" To: Henry Lum , "Elwell, John" , "siprec@ietf.org" Date: Thu, 5 May 2011 16:10:55 +0200 Thread-Topic: summary of changes for draft-portman-siprec-protocol-04 Thread-Index: AcwIaR0YuGqr5XvNSMqltXB+NekCpQBR+yhgAAMNUZAAUHJG0A== Message-ID: <101C6067BEC68246B0C3F6843BCCC1E30B6D880492@MCHP058A.global-ad.net> References: <059AF07365DC474393A19A3AF187DF7407028E4B@NAHALD.us.int.genesyslab.com> <059AF07365DC474393A19A3AF187DF74070292B2@NAHALD.us.int.genesyslab.com> In-Reply-To: <059AF07365DC474393A19A3AF187DF74070292B2@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] summary of changes for draft-portman-siprec-protocol-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, 05 May 2011 14:10:59 -0000 Hi All, Regarding the RTP model I have been preparing text for the architecture dra= ft which is I think the place to document this as I am not aware of any pro= tocol extensions that are needed.=20 My draft text for the architecture document will follow in my next e-mail. Regards Andy =20 > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Henry Lum > Sent: 03 May 2011 19:18 > To: Elwell, John; siprec@ietf.org > Subject: Re: [siprec] summary of changes for=20 > draft-portman-siprec-protocol-04 >=20 > Hi John, >=20 > Okay, let's discuss this topic further in the interim meeting to > determine whether there is any need to specify any protocol related > changes. >=20 > Regards, > Henry >=20 > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Tuesday, May 03, 2011 12:44 PM > > To: Henry Lum; siprec@ietf.org > > Subject: RE: summary of changes for draft-portman-siprec-protocol-04 > >=20 > > Henry, > >=20 > > Concerning the RTP model, I agree that the consensus to=20 > date seems to > > be to cover different RTP models, but I feel we should get something > > into the architecture draft to start with, and then later=20 > see whether > > there is any impact on the protocol draft. > >=20 > > John > >=20 > >=20 > > > -----Original Message----- > > > From: siprec-bounces@ietf.org > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Henry Lum > > > Sent: 02 May 2011 04:09 > > > To: siprec@ietf.org > > > Subject: [siprec] summary of changes for > > > draft-portman-siprec-protocol-04 > > > > > > Hi, > > > > > > > > > > > > I want to summarize the list of changes we are planning to > > > include in the next revision of the document: > > > > > > > > > > > > - Remove use of INFO > > > > > > - Both INVITE or UPDATE can be used for metadata > > > transport through content-disposition > > > > > > - Recording indication is placed at SDP media level > > > > > > - Recording awareness is indicated at SIP level with > > > options; feature tag was also considered > > > > > > - Recording preference is placed at SDP media level > > > > > > - RTP model discussion and time synchronization; so > > > far we seem to agree to handle different RTP models rather > > > than requiring a single model. There are 3 models we have > > > identified so far: > > > > > > o RTP mixer - SRC mixes media streams and can directly > > > synchronize timestamps with metadata and also generate RTCP > > > > > > o RTP translator - Media streams are simply forwarded to > > > the SRS by the SRC. SRC is only capable to indicating > > > start/stop times to the SRS in metadata. > > > > > > o RTP endpoint (is that the right term?) - SRC is neither a > > > mixer nor translator, but is capable of rewriting RTP and > > > RTCP in order to synchronize on the timestamps with metadata. > > > > > > > > > > > > Regards, > > > > > > Henry > > > > > > > > > > > > > > > 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 > =09 > -------------------------------------------------------------- > ----------------------------------------------------- > CONFIDENTIALITY NOTICE: This e-mail and any files attached=20 > may contain confidential and proprietary information of=20 > Alcatel-Lucent and/or its affiliated entities. Access by the=20 > intended recipient only is authorized. Any liability arising=20 > from any party acting, or refraining from acting, on any=20 > information contained in this e-mail is hereby excluded. If=20 > you are not the intended recipient, please notify the sender=20 > immediately, destroy the original transmission and its=20 > attachments and do not disclose the contents to any other=20 > person, use it for any purpose, or store or copy the=20 > information in any medium. Copyright in this e-mail and any=20 > attachments belongs to Alcatel-Lucent and/or its affiliated entities. > =09 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > = From andrew.hutton@siemens-enterprise.com Thu May 5 07:11: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 4E3EFE0782 for ; Thu, 5 May 2011 07:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.885 X-Spam-Level: X-Spam-Status: No, score=-4.885 tagged_above=-999 required=5 tests=[AWL=1.714, 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 uJy6H7JS0+OP for ; Thu, 5 May 2011 07:10:59 -0700 (PDT) Received: from mail174.messagelabs.com (mail174.messagelabs.com [85.158.138.51]) by ietfa.amsl.com (Postfix) with SMTP id 4CA09E0682 for ; Thu, 5 May 2011 07:10:59 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: andrew.hutton@siemens-enterprise.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1304604658!18882625!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 914 invoked from network); 5 May 2011 14:10:58 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-7.tower-174.messagelabs.com with SMTP; 5 May 2011 14:10:58 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 4846323F03DB for ; Thu, 5 May 2011 16:10:58 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 5 May 2011 16:10:58 +0200 From: "Hutton, Andrew" To: "siprec@ietf.org" Date: Thu, 5 May 2011 16:10:56 +0200 Thread-Topic: Draft RTP Model text for the SIPREC Architecture draft. Thread-Index: AcwLAjs8Jcw8C21STH27XyQ6WHWUww== Message-ID: <101C6067BEC68246B0C3F6843BCCC1E30B6D880493@MCHP058A.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] Draft RTP Model text for the SIPREC Architecture draft. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 14:11:00 -0000 Hi All, I propose the following text describing the different RTP models for the ne= xt update to the architecture draft please let me have any comments. 3.x RTP Model An SRC has the task of gathering RTP media from the various participants in= a CS and forwarding the information to the SRS in the context of the RS. F= or a given media stream the SRC has a number of ways of doing this and may = choose different ways for different media streams. 3.x.1 SRC acting as an RTP Translator. The SRC may act as a translator, as defined in [RFC3550]. In this case, the= SRC forwards RTP packets to the SRS with their synchronization source iden= tifier unchanged. Optionally an SRC acting as a translator can perform tra= nscoding (from one codec to another), and this can result in a different ra= te of packets. With this approach, RTP from different sources (i.e., from d= ifferent participants) cannot be mixed by the SRC and must be sent separate= ly to the SRS. In this case all RTCP reports are passed on by the SRC to th= e participants which will be able to detect any SSRC collisions. RTCP packets Sender Reports will generated by a participant sending a strea= m and will need to be forwarded to the SRS (in addition to being sent to re= ceiving participants). RTCP Receiver Reports will be generated by the SRS a= nd need to be forwarded to the relevant participant, the SRC in the case ma= y need to manipulate the RTCP Receiver Reports to take account of any trans= coding that has taken place.=20 OPEN ISSUE. With this approach, can SRTP be used? Can SRTP be used on the C= S and not on the RS and vice versa? If SRTP is used on both the CS and the = RS, can decryption and re-encryption occur and/or can decryption and re-enc= ryption be avoided (clearly not when transcoding is involved or if differen= t keys are to be used?=20 3.x.2 SRC acting as an RTP Mixer. In the case of the SRC acting as a RTP mixer. as defined in [RFC3550], the = SRC combines RTP streams from different participants and sends them towards= the SRS using its own synchronization source identifier. It will make timi= ng adjustments among the received streams and generate its own timing on th= e stream sent to the SRS. Optionally an SRC acting as a mixer can perform t= ranscoding, and can even cope with different codings received from differen= t participants. RTCP Sender Reports and Receiver Reports are not forwarded = by an SRC acting as mixer, but there are requirements for forwarding RTCP S= ource Description (SDES) packets. The use of SRTP between the SRC and the S= RS is independent of the use of SRTP on the CS. 3.x.3 SRC acting as an RTP Endpoint. The case of the SRC acting as an RTP endpoint, as defined in [RFC3550], is = similar to the mixer case, except that the RTP session between the SRC and = the SRS is considered completely independent from the RTP session that is p= art of the CS. The SRC can, but need not, mix RTP streams from different pa= rticipants prior to sending to the SRS. RTCP between the SRC and the SRS is= completely independent of RTCP on the CS. The use of SRTP between the SRC = and the SRS is independent of the use of SRTP on the CS. Regards Andy= From andrew.hutton@siemens-enterprise.com Thu May 5 07:11:01 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7567E0854 for ; Thu, 5 May 2011 07:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=1.500, 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 St6Qdiy0mcny for ; Thu, 5 May 2011 07:11:00 -0700 (PDT) Received: from mail182.messagelabs.com (mail182.messagelabs.com [85.158.139.83]) by ietfa.amsl.com (Postfix) with SMTP id B4E24E076D for ; Thu, 5 May 2011 07:10:59 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: andrew.hutton@siemens-enterprise.com X-Msg-Ref: server-10.tower-182.messagelabs.com!1304604658!6154584!1 X-StarScan-Version: 6.2.16; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 11873 invoked from network); 5 May 2011 14:10:58 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-10.tower-182.messagelabs.com with SMTP; 5 May 2011 14:10:58 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 5237A23F03E8; Thu, 5 May 2011 16:10:58 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 5 May 2011 16:10:58 +0200 From: "Hutton, Andrew" To: "Parthasarathi R (partr)" , "siprec@ietf.org" Date: Thu, 5 May 2011 16:10:57 +0200 Thread-Topic: [siprec] I-D Action:draft-ietf-siprec-architecture-02.txt Thread-Index: Acv54yOePwZLBlTgQPChIkDA4jWhawPDzBjgAIcZ5bA= Message-ID: <101C6067BEC68246B0C3F6843BCCC1E30B6D880494@MCHP058A.global-ad.net> References: <20110413140001.12509.2089.idtracker@ietfc.amsl.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] 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: Thu, 05 May 2011 14:11:02 -0000 Hi Partha, I don't understand the need for showing the decomposition of the SRC in thi= s way. The current figures in the architecture document are there to help e= xplain the relationship to Mediactrl but I don't see the value in this chan= ge. It also appears to incorrectly show the SIP based Communication Session ter= minating at the MediaCtrl application server. Maybe we could discuss why you think we need this in the interim next week. Regards Andy =20 =20 > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi R (partr) > Sent: 02 May 2011 19:22 > To: siprec@ietf.org > Subject: Re: [siprec] I-D Action:draft-ietf-siprec-architecture-02.txt >=20 > As part of the discussion about Metadata and RTP model with lot of > folks, I realized that it is better to show "UA instance" which is > associated with SRC to create RS as a separate instance. Fig 4 in the > draft shall be updated as=20 >=20 > Session Recording Server (SRS) > +----------+ > (Recording Session) | | > +-----------SIP------------------------->| UA-A | > | | (SRS) | > | +----------+ > | Session Recording Client (SRC) | > +----------------------------------------+ | > | +-----------+ | | > | | Session | +------------+ | | > | | Recording | | | | | =20 > +---------+ > | | UA | | Media | | <--RTP--+ |=20 > | > | +-----------+ | | | |=20 > | > | ^ | | | |=20 > | > | | | | | |=20 > | >=20 > | V | | | |=20 > | > | +-----------+ | Server | | |=20 > UA-B | > | | MediaCtrl |MEDIACTRL | |<-----RTP------>|=20 > | > | |Application|<-------->| | | =20 > +---------+ > | | Server | +------------+ | ^ > | +-----------+ | | > +--------^-------------------------------+ | > | | > +-----------------------SIP-------------------------+ > (Communication Session) >=20 > Figure 4: Example of Session Recording Client=20 > using MEDIACTRL >=20 > Here in the above figure, session recording UA is a separate=20 > UA instance > apart from CS creating UA (Mediactrl application server) instance. > Cooridination between Session Recording UA and Mediactrl application > server is outside the scope of SIPREC. The same logical=20 > figure shall be > extended to other SRC architecture figure by which the=20 > importance of SIP > based RS UA with non-sip CS is clear. Please let me know=20 > opinion on the > same. >=20 > Thanks > Partha =20 >=20 > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf > Of Internet-Drafts@ietf.org > Sent: Wednesday, April 13, 2011 7:30 PM > To: i-d-announce@ietf.org > Cc: siprec@ietf.org > Subject: [siprec] I-D Action:draft-ietf-siprec-architecture-02.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the SIP Recording Working Group of the > IETF. >=20 >=20 > 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 >=20 > Session recording is a critical requirement in many communications > environments such as call centers and financial trading. In some of > these environments, all calls must be recorded for regulatory, > compliance, and consumer protection reasons. Recording of a=20 > session is > typically performed by sending a copy of a media stream to a recording > device. This document describes architectures for deploying session > recording solutions in an environment which is based on the Session > Initiation Protocol (SIP). >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-siprec-architec ture-02.tx > t >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > = From partr@cisco.com Thu May 5 10:05:48 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 0D05EE08B1 for ; Thu, 5 May 2011 10:05:48 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gn0neAiFx8SR for ; Thu, 5 May 2011 10:05: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 0D5F6E07A0 for ; Thu, 5 May 2011 10:05:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=5994; q=dns/txt; s=iport; t=1304615147; x=1305824747; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=tgFgCSAOseYmmBUiXpJuLZWN77AtBGHdjsb5sHcMsYw=; b=B+iW4xcc4eAEZ+l6ajpvEgc0JLw6TVpeBmX/iBjJv9+f6jRmEsIHyAvQ Nv5kAMUC9dH21YzbSgRm/A+tUNsxe6CYJh/Egf3VQZ5yB+xEQaQmbLTyA +WD1Pfz9+xBvS9Cl37A+tMAEONdQ2VoQcBkkglRC+amiis7+kOzlVXtQE Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj8BACXYwk2rRDoH/2dsb2JhbACYFo4nd4hynhyeOoYHBIY2jUCKKw X-IronPort-AV: E=Sophos;i="4.64,321,1301875200"; d="scan'208";a="351149320" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-2.cisco.com with ESMTP; 05 May 2011 17:05:46 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p45H5iX8018092; Thu, 5 May 2011 17:05: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); Thu, 5 May 2011 22:35:43 +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, 5 May 2011 22:35:42 +0530 Message-ID: In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E30B6D880494@MCHP058A.global-ad.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] I-D Action:draft-ietf-siprec-architecture-02.txt Thread-Index: Acv54yOePwZLBlTgQPChIkDA4jWhawPDzBjgAIcZ5bAADbLfIA== References: <20110413140001.12509.2089.idtracker@ietfc.amsl.com> <101C6067BEC68246B0C3F6843BCCC1E30B6D880494@MCHP058A.global-ad.net> From: "Parthasarathi R (partr)" To: "Hutton, Andrew" , X-OriginalArrivalTime: 05 May 2011 17:05:43.0868 (UTC) FILETIME=[AB6EBFC0:01CC0B46] Subject: Re: [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: Thu, 05 May 2011 17:05:48 -0000 Hi Andy, Let me explain with simple SRC examples for the need of this decomposition.=20 SRC is non-SIP entity namely H.323 gateway which has SIP UA for recording purpose only. CS of SRC is H.323 session whereas RS is SIP session. In these scenario, the architecture has to mention both H.323 gateway, SIP UA combination as SRC instead of mere H.323 gateway as SRC. In case you foresee more discussion required, let us discuss on interim meeting. Thanks Partha=20 -----Original Message----- From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com]=20 Sent: Thursday, May 05, 2011 7:41 PM To: Parthasarathi R (partr); siprec@ietf.org Subject: RE: [siprec] I-D Action:draft-ietf-siprec-architecture-02.txt Hi Partha, I don't understand the need for showing the decomposition of the SRC in this way. The current figures in the architecture document are there to help explain the relationship to Mediactrl but I don't see the value in this change. It also appears to incorrectly show the SIP based Communication Session terminating at the MediaCtrl application server. Maybe we could discuss why you think we need this in the interim next week. Regards Andy =20 =20 > -----Original Message----- > From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi R (partr) > Sent: 02 May 2011 19:22 > To: siprec@ietf.org > Subject: Re: [siprec] I-D Action:draft-ietf-siprec-architecture-02.txt >=20 > As part of the discussion about Metadata and RTP model with lot of=20 > folks, I realized that it is better to show "UA instance" which is=20 > associated with SRC to create RS as a separate instance. Fig 4 in the=20 > draft shall be updated as >=20 > Session Recording Server (SRS) > +----------+ > (Recording Session) | | > +-----------SIP------------------------->| UA-A | > | | (SRS) | > | +----------+ > | Session Recording Client (SRC) | > +----------------------------------------+ | > | +-----------+ | | > | | Session | +------------+ | | > | | Recording | | | | | =20 > +---------+ > | | UA | | Media | | <--RTP--+ |=20 > | > | +-----------+ | | | |=20 > | > | ^ | | | |=20 > | > | | | | | |=20 > | >=20 > | V | | | |=20 > | > | +-----------+ | Server | | |=20 > UA-B | > | | MediaCtrl |MEDIACTRL | |<-----RTP------>|=20 > | > | |Application|<-------->| | | =20 > +---------+ > | | Server | +------------+ | ^ > | +-----------+ | | > +--------^-------------------------------+ | > | | > +-----------------------SIP-------------------------+ > (Communication Session) >=20 > Figure 4: Example of Session Recording Client using=20 > MEDIACTRL >=20 > Here in the above figure, session recording UA is a separate UA=20 > instance apart from CS creating UA (Mediactrl application server)=20 > instance. > Cooridination between Session Recording UA and Mediactrl application=20 > server is outside the scope of SIPREC. The same logical figure shall=20 > be extended to other SRC architecture figure by which the importance=20 > of SIP based RS UA with non-sip CS is clear. Please let me know=20 > opinion on the same. >=20 > Thanks > Partha >=20 > -----Original Message----- > From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org > Sent: Wednesday, April 13, 2011 7:30 PM > To: i-d-announce@ietf.org > Cc: siprec@ietf.org > Subject: [siprec] I-D Action:draft-ietf-siprec-architecture-02.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. > This draft is a work item of the SIP Recording Working Group of the=20 > IETF. >=20 >=20 > 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 >=20 > Session recording is a critical requirement in many communications=20 > environments such as call centers and financial trading. In some of=20 > these environments, all calls must be recorded for regulatory,=20 > compliance, and consumer protection reasons. Recording of a session=20 > is typically performed by sending a copy of a media stream to a=20 > recording device. This document describes architectures for deploying > session recording solutions in an environment which is based on the=20 > Session Initiation Protocol (SIP). >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-siprec-architec ture-02.tx > t >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader=20 > implementation to automatically retrieve the ASCII version of the=20 > Internet-Draft. > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec >=20 From eckelcu@cisco.com Thu May 5 10:10:47 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73FC9E06C9 for ; Thu, 5 May 2011 10:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.579 X-Spam-Level: X-Spam-Status: No, score=-9.579 tagged_above=-999 required=5 tests=[AWL=-0.780, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwnNBa16L0Ie for ; Thu, 5 May 2011 10:10:37 -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 14487E06B3 for ; Thu, 5 May 2011 10:10:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=23733; q=dns/txt; s=iport; t=1304615436; x=1305825036; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=qIRh4K+EKiUUjbBCWsTwr+XEvtTqCUnPc14tOP0nIRM=; b=lTWuSkXSClNC/ba7rfg0ZITs/eeA3qVJC2EPAbhlKQZykhtO/yE1FAJu rpcEY5/kJo8NTeOYk0xwdl6TM4O1p8zAZJHmcY19LjXuRGNQFTz8zffWq QKjwwSgG2DtcCt38wE3qzg05pLNz58f0H/MA6iRMr2qDV+yrovlXiSadj 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj8BANjYwk2rRDoG/2dsb2JhbACYFo4nd4hynhueOoMLgnwEhjiNPopD X-IronPort-AV: E=Sophos;i="4.64,321,1301875200"; d="scan'208";a="442446958" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-1.cisco.com with ESMTP; 05 May 2011 17:10:36 +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 p45HAa0r022446; Thu, 5 May 2011 17:10:36 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); Thu, 5 May 2011 10:10:26 -0700 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-puzzleid: {DF8E044E-3249-4B9C-AF33-C0F33A23599E} x-cr-hashedpuzzle: BWzn Ctee EsBa HFA0 H1ot JQlo Lr2G NP2o TYWB UvWI ZPFf bPQt cPqK c06a ej7f e3Wg; 3; aABrAGEAcABsAGEAbgBAAGEAYwBtAGUAcABhAGMAawBlAHQALgBjAG8AbQA7AGoAbwBoAG4ALgBlAGwAdwBlAGwAbABAAHMAaQBlAG0AZQBuAHMALQBlAG4AdABlAHIAcAByAGkAcwBlAC4AYwBvAG0AOwBzAGkAcAByAGUAYwBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {DF8E044E-3249-4B9C-AF33-C0F33A23599E}; ZQBjAGsAZQBsAGMAdQBAAGMAaQBzAGMAbwAuAGMAbwBtAA==; Thu, 05 May 2011 17:10:20 GMT; UgBFADoAIABbAHMAaQBwAHIAZQBjAF0AIABQAGEAcgB0AGkAYQBsACAAdQBwAGQAYQB0AGUAcwAgAGEAbgBkACAAaQBkAGUAbgB0AGkAZgBpAGUAcgBzAA== Content-class: urn:content-classes:message Date: Thu, 5 May 2011 10:10:20 -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+AAEAO1UAANZylQAXAZhbAAHzy2EALO3FmAAEv0MqA= References: <4D9CB8E1.7030402@cisco.com> From: "Charles Eckel (eckelcu)" To: "Parthasarathi R (partr)" , "Elwell, John" , "Paul Kyzivat (pkyzivat)" , X-OriginalArrivalTime: 05 May 2011 17:10:26.0792 (UTC) FILETIME=[54118680:01CC0B47] 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: Thu, 05 May 2011 17:10:47 -0000 I follow the logic, but let me run through a simple use case.=20 0) I am on a call that is part of a recording. Initially, this is through CS1 which results in RS1, which is part of recording X. My unique participant ID is p0. I drop off and call back in. I need to be brought back into the same recording X. Possible scenarios are: 1) I call back into CS1, and am added into recording X through RS1. My unique participant ID is p1? 2) I call into CS2, and am added to recording X through RS1. My unique participant ID is p2? 3) I call into CS2, and am added to recording X through RS2. My unique participant ID is p3? If the SRS is able to make use of some other metadata to realize that p0=3Dp1=3Dp2=3Dp3, great, if not, they look like different participants. Cheers, Charles > -----Original Message----- > From: Parthasarathi R (partr) > Sent: Tuesday, May 03, 2011 9:46 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 Charles, >=20 > In case participants id has to be unique for single RS with multiple CS as you mentioned below mail > and also, participant id has to be unique within single CS which span across multiple RS (start & stop > of recording within CS scenario), then participant unique id needs to be global (URN UUID) rather than > local id like xml:id. Please let me know in case you have any other opinion on the same. >=20 > Thanks > Partha >=20 > -----Original Message----- > From: Charles Eckel (eckelcu) > Sent: Wednesday, April 20, 2011 2:54 AM > 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 >=20 > Hi Partha, >=20 > 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. >=20 > Cheers, > Charles >=20 > > -----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 > > > > 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? > > > > 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 andrew.hutton@siemens-enterprise.com Thu May 5 11:08: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 E42C5E08DC for ; Thu, 5 May 2011 11:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.266 X-Spam-Level: X-Spam-Status: No, score=-5.266 tagged_above=-999 required=5 tests=[AWL=1.333, 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 GCkPb1y0zLnp for ; Thu, 5 May 2011 11:08:35 -0700 (PDT) Received: from mail182.messagelabs.com (mail182.messagelabs.com [85.158.139.83]) by ietfa.amsl.com (Postfix) with SMTP id 62F6AE08D8 for ; Thu, 5 May 2011 11:08:34 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: andrew.hutton@siemens-enterprise.com X-Msg-Ref: server-13.tower-182.messagelabs.com!1304618913!6010015!1 X-StarScan-Version: 6.2.16; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 4888 invoked from network); 5 May 2011 18:08:33 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-13.tower-182.messagelabs.com with SMTP; 5 May 2011 18:08:33 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id F1F9523F03DB; Thu, 5 May 2011 20:08: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, 5 May 2011 20:08:33 +0200 From: "Hutton, Andrew" To: "Parthasarathi R (partr)" , "siprec@ietf.org" Date: Thu, 5 May 2011 20:08:31 +0200 Thread-Topic: [siprec] I-D Action:draft-ietf-siprec-architecture-02.txt Thread-Index: Acv54yOePwZLBlTgQPChIkDA4jWhawPDzBjgAIcZ5bAADbLfIAACOYzA Message-ID: <101C6067BEC68246B0C3F6843BCCC1E30B6D880650@MCHP058A.global-ad.net> References: <20110413140001.12509.2089.idtracker@ietfc.amsl.com> <101C6067BEC68246B0C3F6843BCCC1E30B6D880494@MCHP058A.global-ad.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] 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: Thu, 05 May 2011 18:08:36 -0000 Hi Partha, Of course it could be that the SRC is recording something other than a SIP = session and using SIPREC with the SRS. However for the purposes of SIPREC t= he definiton of the CS is as follows: "Communication Session (CS): A SIP session created between two or more UA'= s for the purpose of communication which may be recorded." Therefore I believe your scenario is out of scope and should not be covered= in the architecture draft. I noticed a slight difference between the architecture and requirements dra= ft on the definition but it is only in the wording and both state that it i= s a SIP session. Regards Andy =20 > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com]=20 > Sent: 05 May 2011 18:06 > To: Hutton, Andrew; siprec@ietf.org > Subject: RE: [siprec] I-D Action:draft-ietf-siprec-architecture-02.txt >=20 > Hi Andy, >=20 > Let me explain with simple SRC examples for the need of this > decomposition.=20 >=20 > SRC is non-SIP entity namely H.323 gateway which has SIP UA for > recording purpose only. CS of SRC is H.323 session whereas RS is SIP > session. In these scenario, the architecture has to mention both H.323 > gateway, SIP UA combination as SRC instead of mere H.323=20 > gateway as SRC. >=20 >=20 > In case you foresee more discussion required, let us discuss=20 > on interim > meeting. >=20 > Thanks > Partha=20 >=20 > -----Original Message----- > From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com]=20 > Sent: Thursday, May 05, 2011 7:41 PM > To: Parthasarathi R (partr); siprec@ietf.org > Subject: RE: [siprec] I-D Action:draft-ietf-siprec-architecture-02.txt >=20 > Hi Partha, >=20 > I don't understand the need for showing the decomposition of=20 > the SRC in > this way. The current figures in the architecture document=20 > are there to > help explain the relationship to Mediactrl but I don't see=20 > the value in > this change. >=20 > It also appears to incorrectly show the SIP based=20 > Communication Session > terminating at the MediaCtrl application server. >=20 > Maybe we could discuss why you think we need this in the interim next > week. >=20 > Regards > Andy =20 > =20 >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi=20 > R (partr) > > Sent: 02 May 2011 19:22 > > To: siprec@ietf.org > > Subject: Re: [siprec] I-D=20 > Action:draft-ietf-siprec-architecture-02.txt > >=20 > > As part of the discussion about Metadata and RTP model with lot of=20 > > folks, I realized that it is better to show "UA instance" which is=20 > > associated with SRC to create RS as a separate instance.=20 > Fig 4 in the=20 > > draft shall be updated as > >=20 > > Session Recording=20 > Server (SRS) > > +----------+ > > (Recording Session) | | > > +-----------SIP------------------------->| UA-A | > > | | (SRS) | > > | +----------+ > > | Session Recording Client (SRC) | > > +----------------------------------------+ | > > | +-----------+ | | > > | | Session | +------------+ | | > > | | Recording | | | | | =20 > > +---------+ > > | | UA | | Media | | <--RTP--+ |=20 > > | > > | +-----------+ | | | |=20 > > | > > | ^ | | | |=20 > > | > > | | | | | |=20 > > | > >=20 > > | V | | | |=20 > > | > > | +-----------+ | Server | | |=20 > > UA-B | > > | | MediaCtrl |MEDIACTRL | |<-----RTP------>|=20 > > | > > | |Application|<-------->| | | =20 > > +---------+ > > | | Server | +------------+ | ^ > > | +-----------+ | | > > +--------^-------------------------------+ | > > | | > > +-----------------------SIP-------------------------+ > > (Communication Session) > >=20 > > Figure 4: Example of Session Recording Client using=20 > > MEDIACTRL > >=20 > > Here in the above figure, session recording UA is a separate UA=20 > > instance apart from CS creating UA (Mediactrl application server)=20 > > instance. > > Cooridination between Session Recording UA and Mediactrl=20 > application=20 > > server is outside the scope of SIPREC. The same logical=20 > figure shall=20 > > be extended to other SRC architecture figure by which the=20 > importance=20 > > of SIP based RS UA with non-sip CS is clear. Please let me know=20 > > opinion on the same. > >=20 > > Thanks > > Partha > >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf Of=20 > Internet-Drafts@ietf.org > > Sent: Wednesday, April 13, 2011 7:30 PM > > To: i-d-announce@ietf.org > > Cc: siprec@ietf.org > > Subject: [siprec] I-D Action:draft-ietf-siprec-architecture-02.txt > >=20 > > A New Internet-Draft is available from the on-line Internet-Drafts=20 > > directories. > > This draft is a work item of the SIP Recording Working Group of the=20 > > IETF. > >=20 > >=20 > > 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 > >=20 > > Session recording is a critical requirement in many communications=20 > > environments such as call centers and financial trading. =20 > In some of=20 > > these environments, all calls must be recorded for regulatory,=20 > > compliance, and consumer protection reasons. Recording of=20 > a session=20 > > is typically performed by sending a copy of a media stream to a=20 > > recording device. This document describes architectures=20 > for deploying >=20 > > session recording solutions in an environment which is based on the=20 > > Session Initiation Protocol (SIP). > >=20 > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-siprec-architec > ture-02.tx > > t > >=20 > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > >=20 > > Below is the data which will enable a MIME compliant mail reader=20 > > implementation to automatically retrieve the ASCII version of the=20 > > Internet-Draft. > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > >=20 > = From pkyzivat@cisco.com Thu May 5 14:46:48 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 402A4E07FE for ; Thu, 5 May 2011 14:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.616 X-Spam-Level: X-Spam-Status: No, score=-109.616 tagged_above=-999 required=5 tests=[AWL=-0.817, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bxT6U34Q81Nu for ; Thu, 5 May 2011 14:46:46 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by ietfa.amsl.com (Postfix) with ESMTP id 608F6E0788 for ; Thu, 5 May 2011 14:46:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=23443; q=dns/txt; s=iport; t=1304632005; x=1305841605; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=uEJEaSTFVaz1OC93tXOoC1GKlMuekNeahBTAkTQvVik=; b=MYPPNAC+Xob1As/j2jq0UTO8eu96DhV3etKATY9bqHbAM79w9FBjPp7w Y64hf5jAGg8bH6x6jDKRPqBvI/tpYIGJwaPUh8qPQQhfJj44egc4ei7zE /hCRidtT6CtO6FFGThPjW6+wJ776Eod/mIVm6EPRFI4Hf4Eddlzvg6/kd k=; X-IronPort-AV: E=Sophos;i="4.64,322,1301875200"; d="scan'208";a="284459360" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by sj-iport-4.cisco.com with ESMTP; 05 May 2011 21:46:44 +0000 Received: from [161.44.174.124] (dhcp-161-44-174-124.cisco.com [161.44.174.124]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p45LkhPJ024751; Thu, 5 May 2011 21:46:43 GMT Message-ID: <4DC31AC4.9030309@cisco.com> Date: Thu, 05 May 2011 17:46:44 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Charles Eckel (eckelcu)" 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: Thu, 05 May 2011 21:46:48 -0000 On 5/5/2011 1:10 PM, Charles Eckel (eckelcu) wrote: > I follow the logic, but let me run through a simple use case. > > 0) I am on a call that is part of a recording. Initially, this is > through CS1 which results in RS1, which is part of recording X. My > unique participant ID is p0. > > I drop off and call back in. I need to be brought back into the same > recording X. Possible scenarios are: > > 1) I call back into CS1, and am added into recording X through RS1. My > unique participant ID is p1? Maybe. It depends on whether the SRC recognizes you as the same participant and remembers that it had assigned p1 to you. If not, then you will presumably appear as a new participant. > 2) I call into CS2, and am added to recording X through RS1. My unique > participant ID is p2? Pretty much the same answer as above. Its also up to the SRC to decide if this is part of CS1 or CS2. > 3) I call into CS2, and am added to recording X through RS2. My unique > participant ID is p3? Pretty much the same again. If it is the same SRC, and has some history to figure out what is going on, it can continue to use p1. If it is a different SRC, then its more of a challenge. There would have to be some sharing of info between the two for the new SRC to recover the old p1. More likely you will get a new p3. > If the SRS is able to make use of some other metadata to realize that > p0=p1=p2=p3, great, if not, they look like different participants. Yes, if the p(i) are different the SRS could still attempt correlation, but its outside our current scope. Thanks, Paul > Cheers, > Charles > >> -----Original Message----- >> From: Parthasarathi R (partr) >> Sent: Tuesday, May 03, 2011 9:46 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 >> >> Hi Charles, >> >> In case participants id has to be unique for single RS with multiple > CS as you mentioned below mail >> and also, participant id has to be unique within single CS which span > across multiple RS (start& stop >> of recording within CS scenario), then participant unique id needs to > be global (URN UUID) rather than >> local id like xml:id. Please let me know in case you have any other > opinion on the same. >> >> Thanks >> Partha >> >> -----Original Message----- >> From: Charles Eckel (eckelcu) >> Sent: Wednesday, April 20, 2011 2:54 AM >> 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 >> >> 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 >>> >>> 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? >>> >>> 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 eckelcu@cisco.com Thu May 5 15:58:22 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CA6FE069D for ; Thu, 5 May 2011 15:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.442 X-Spam-Level: X-Spam-Status: No, score=-10.442 tagged_above=-999 required=5 tests=[AWL=0.157, 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 zcEEo6rI6Ei9 for ; Thu, 5 May 2011 15:58:21 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id F0BC3E067C for ; Thu, 5 May 2011 15:58:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=21036; q=dns/txt; s=iport; t=1304636300; x=1305845900; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=bm64htHprY9OTIwnX5yYkG4AqGBz3SruhfrQK2Zi2VY=; b=jDFlKqL5saPTCjxeRjxiNJ9mCskq5scG13ReMvSMMEgdz3nBIL8N3oe4 FsrwnV9czCBRNxCCO4/IvMRkhuvV2sBnM/OC1hdKeYc4K14VqlBX+/jrS 5p7MXHz9sGAhBSAp7eBmOXSwAGK0MAzJeg2eLblUajIiYCNnBXuPb1JqZ 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmsBANoqw02rRDoI/2dsb2JhbACYGI4md4hynl2eKIMKAYJ8BIY4jT6KQxw X-IronPort-AV: E=Sophos;i="4.64,323,1301875200"; d="scan'208";a="309472896" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-3.cisco.com with ESMTP; 05 May 2011 22:58:20 +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 p45MwKuO031799; Thu, 5 May 2011 22:58:20 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); Thu, 5 May 2011 15:57: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, 5 May 2011 15:57:39 -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: AcwJ+biFoOO41i/hQIKAJCEft7se1gAVN5rwAARo/LAARdMwIA== References: <4DB58BC7.5090603@cisco.com><4DB820DA.1080200@cisco.com><4DBB59E2.9040200@cisco.com><4DC0AA33.80205@cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD0635764C@XMB-BGL-417.cisco.com> From: "Charles Eckel (eckelcu)" To: "Elwell, John" , "Ram Mohan R (rmohanr)" , "Paul Kyzivat (pkyzivat)" X-OriginalArrivalTime: 05 May 2011 22:57:40.0383 (UTC) FILETIME=[D5DB3AF0:01CC0B77] 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: Thu, 05 May 2011 22:58:22 -0000 The other use case is different RS for the same recording. That is where I think recording object comes in handy. Cheers, Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > Sent: Wednesday, May 04, 2011 6:40 AM > To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > Cc: siprec@ietf.org > Subject: Re: [siprec] RS to CS relationship as an attribute inRecording block >=20 > Ram, >=20 > If we don't think a Recording object is needed for the case that Charles describes, fine. But I would > also argue that we don't need a Recording Session object. >=20 > John (as individual) >=20 > > -----Original Message----- > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > Sent: 04 May 2011 12:51 > > To: Paul Kyzivat (pkyzivat); Elwell, John > > Cc: siprec@ietf.org > > Subject: RE: [siprec] RS to CS relationship as an attribute > > inRecording block > > > > I agree with Paul here. > > The below use-case that Charles mentions is a good example of two SRCs > > recording the same CS simultaneously via different RS. > > In these cases these are two Recording Sessions each > > recording the same > > CS and the current model is sufficient for the same. > > > > John, > > > > so I don't see a need to change "Recording Session" to "Recording" > > object in the model. Or are you talking here about grouping of > > recordings ? > > > > As Paul mentioned it will only be recognized as the same CS > > only if the > > two SRCs coordinate among themselves to use the same UUID for it. > > Otherwise we will get two recordings. > > > > Ram > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > > Behalf Of Paul Kyzivat (pkyzivat) > > > Sent: Wednesday, May 04, 2011 6:52 AM > > > To: Elwell, John > > > Cc: siprec@ietf.org > > > Subject: Re: [siprec] RS to CS relationship as an attribute > > inRecording > > > block > > > > > > Of course this could be accomplished simply by dumb luck: > > > > > > If you and I have separate SRCs and are asking for separate > > recordings > > > of the "same" CS, it will only be recognized as the same CS > > if the two > > > SRCs coordinate among themselves to use the same UUID for > > it. If they > > > don't (likely in this case) the SRS with thing it is two CSs and so > > you > > > get two recodings. > > > > > > Thanks, > > > Paul > > > > > > On 5/3/2011 4:33 PM, Elwell, John wrote: > > > > In that case, I would assert that we need a "Recording" object in > > the > > > metadata model, not a "Recording Session" object. > > > > > > > > John > > > > > > > >> -----Original Message----- > > > >> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > >> Sent: 03 May 2011 21:25 > > > >> To: Elwell, John; Paul Kyzivat (pkyzivat) > > > >> Cc: Parthasarathi R (partr); siprec@ietf.org > > > >> Subject: RE: [siprec] RS to CS relationship as an attribute > > > >> inRecording block > > > >> > > > >> Because one is mine and the other is yours and you want to > > > >> record yours > > > >> in one format and in combination with other CSs, and I > > want mine in > > > >> another format and with other CSs. > > > >> For example you want yours recorded a single mixed audio and > > > >> composited > > > >> video stream, and I want all separate streams. > > > >> > > > >> Cheers, > > > >> Charles > > > >> > > > >>> -----Original Message----- > > > >>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > >>> Sent: Tuesday, May 03, 2011 12:55 PM > > > >>> To: Charles Eckel (eckelcu); Paul Kyzivat (pkyzivat) > > > >>> Cc: Parthasarathi R (partr); siprec@ietf.org > > > >>> Subject: RE: [siprec] RS to CS relationship as an attribute > > > >> inRecording block > > > >>> > > > >>> Why would I want two recordings of the same CS at the same SRS? > > > >>> > > > >>> John > > > >>> > > > >>>> -----Original Message----- > > > >>>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > >>>> Sent: 03 May 2011 17:56 > > > >>>> To: Elwell, John; Paul Kyzivat (pkyzivat) > > > >>>> Cc: Parthasarathi R (partr); siprec@ietf.org > > > >>>> Subject: RE: [siprec] RS to CS relationship as an attribute > > > >>>> inRecording block > > > >>>> > > > >>>> I do not think the CS is sufficient. For example, how do > > > >> you know if > > > >> I > > > >>>> want another recording of the same CS, or a single recording? > > > >>>> > > > >>>> Cheers, > > > >>>> Charles > > > >>>> > > > >>>>> -----Original Message----- > > > >>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > >>>>> Sent: Tuesday, May 03, 2011 9:39 AM > > > >>>>> To: Charles Eckel (eckelcu); Paul Kyzivat (pkyzivat) > > > >>>>> Cc: Parthasarathi R (partr); siprec@ietf.org > > > >>>>> Subject: RE: [siprec] RS to CS relationship as an attribute > > > >>>> inRecording block > > > >>>>> > > > >>>>> I saw a "recording" as being as being a recording of a > > > >> CS. So yes, > > > >> a > > > >>>> recording can exist outside of an > > > >>>>> RS, and might even span multiple RSs, but doesn't the CS > > > >>>> object cover > > > >>>> this? > > > >>>>> > > > >>>>> John > > > >>>>> > > > >>>>>> -----Original Message----- > > > >>>>>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > >>>>>> Sent: 02 May 2011 14:34 > > > >>>>>> To: Elwell, John; Paul Kyzivat (pkyzivat) > > > >>>>>> Cc: Parthasarathi R (partr); siprec@ietf.org > > > >>>>>> Subject: RE: [siprec] RS to CS relationship as an attribute > > > >>>>>> inRecording block > > > >>>>>> > > > >>>>>> Hi John, > > > >>>>>> > > > >>>>>> Having a recording exist outside of the RS provides, among > > > >>>>>> other things, > > > >>>>>> a way for a SRC to establish a new RS to continue a > > > >>>> recording in the > > > >>>>>> event something goes wrong with initial RS. It also > > > >> facilitates > > > >>>> having > > > >>>>>> multiple SRCs participate in the same recording, which we > > > >>>>>> agreed was out > > > >>>>>> of scope, but is at least possible if a recording exists > > > >>>> outside of > > > >>>> an > > > >>>>>> RS. > > > >>>>>> I suppose the argument could be made this is not really > > > >> necessary. > > > >>>>>> Rather, one could, outside of the scope of SIPREC, decide to > > > >>>> associate > > > >>>>>> multiple RSs in various ways, including stitching them > > > >>>>>> together for the > > > >>>>>> purpose of failover or distributed recordings. Is that what > > > >>>>>> you have in > > > >>>>>> mind? > > > >>>>>> > > > >>>>>> Cheers, > > > >>>>>> Charles > > > >>>>>> > > > >>>>>>> -----Original Message----- > > > >>>>>>> From: Elwell, John > > > >> [mailto:john.elwell@siemens-enterprise.com] > > > >>>>>>> Sent: Saturday, April 30, 2011 3:12 AM > > > >>>>>>> To: Paul Kyzivat (pkyzivat); Charles Eckel (eckelcu) > > > >>>>>>> Cc: Parthasarathi R (partr); siprec@ietf.org > > > >>>>>>> Subject: RE: [siprec] RS to CS relationship as an attribute > > > >>>>>> inRecording block > > > >>>>>>> > > > >>>>>>> I am confused, because this thread has suddenly started to > > > >>>>>> talk about > > > >>>>>> a "recording", whereas metadata- > > > >>>>>>> 00 has an object called "Recording Session", which > > > >>>> 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 > > > >>>>>>> relationship with an RS, and therefore a single SIP > > > >> dialog, I > > > >>>> would > > > >>>>>> suggest they articulate why this > > > >>>>>>> would be needed, with a view to getting it into the metadata > > > >>>> model. > > > >>>>>>> > > > >>>>>>> John > > > >>>>>>> > > > >>>>>>> > > > >>>>>>>> -----Original Message----- > > > >>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > >>>>>>>> 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 > > > >>>>>>>> inRecording block > > > >>>>>>>> > > > >>>>>>>> > > > >>>>>>>> > > > >>>>>>>> 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 > > > >>>>>>>>> > > > >>>>>>>> > > > >>>>>> > > > >>>> > > > >> > > > > > > > _______________________________________________ > > > siprec mailing 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 May 5 18:50:14 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A34A3E06A5 for ; Thu, 5 May 2011 18:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.116 X-Spam-Level: X-Spam-Status: No, score=-10.116 tagged_above=-999 required=5 tests=[AWL=0.483, 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 NmBrau1dU+PI for ; Thu, 5 May 2011 18:50:12 -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 C9AACE0675 for ; Thu, 5 May 2011 18:50:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=22842; q=dns/txt; s=iport; t=1304646612; x=1305856212; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=5tEsqaKR9rYe2/v9blzbmMFJlgmvcCmnqSpn2wb735o=; b=lCpNVZoz2JUlHmyqIulf28u1rZpACyhWz+INnNOMBIMu8zTH65TYKxZt hrPs2GejuAhHb5mNde1pMKPgaGzh6aqz4Kpi1vfnPsFS4JSKJnxtSEd5+ WZodxzhUZd/Z+F+ybfexASVW6S6+h0L2cdDUCz9su4F1eRY7af6e4JCY1 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4BAGxTw02Q/khNgWdsb2JhbACYGY4mFAEBFiYliHKeV54cgwoBgnwEhjaNQIorNA X-IronPort-AV: E=Sophos;i="4.64,323,1301875200"; d="scan'208";a="87043707" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 06 May 2011 01:50:10 +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 p461o9cc017200; Fri, 6 May 2011 01:50:10 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, 6 May 2011 07:20: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: Fri, 6 May 2011 07:20:12 +0530 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: AcwJ+biFoOO41i/hQIKAJCEft7se1gAVN5rwAARo/LAARdMwIAAFIb9g References: <4DB58BC7.5090603@cisco.com><4DB820DA.1080200@cisco.com><4DBB59E2.9040200@cisco.com><4DC0AA33.80205@cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD0635764C@XMB-BGL-417.cisco.com> From: "Parthasarathi R (partr)" To: "Charles Eckel (eckelcu)" , "Elwell, John" , "Ram Mohan R (rmohanr)" , "Paul Kyzivat (pkyzivat)" X-OriginalArrivalTime: 06 May 2011 01:50:09.0065 (UTC) FILETIME=[EE26C990:01CC0B8F] 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, 06 May 2011 01:50:14 -0000 Charles, Different RS for same recording looks like "recording group" requirement. There was "recording group" metadata block in the initial metadata draft and it was removed as there was no known usecase. I'm reading your usecase which may call for optional "recording group" block in metadata model. =20 I'll provide some hypothetical scenario: SRC has RS1 with mixed stream, RS2 with unmixed stream for CS1. SRS has to aware that RS1 and RS2 belongs to same recording. This shall be achieved by "recording group" metadata block which will extend for your scenario which is outside the scope of SIPREC. Let us discuss in the meeting whether "recording group" is required. John, Recording Session object has two attributes namely 1) Recording Requestor (SRC/SRS) - This may be required in SRS in terms of metadata model but which shall be derived from the information whether RS INVITE is received in SRS or INVITE sent out by SRS. 2) Recording type (Persistent/selective) - This attribute will become irrelevant in case SRS is designed with the principle of "Many RS to Many CS" as mentioned below in this mail thread. Based on the current attributes, metadata format will have no standard XML element. Please let me know whether your argue is same or not. Thanks Partha -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Charles Eckel (eckelcu) Sent: Friday, May 06, 2011 4:28 AM To: Elwell, John; Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) Cc: siprec@ietf.org Subject: Re: [siprec] RS to CS relationship as an attribute inRecording block The other use case is different RS for the same recording. That is where I think recording object comes in handy. Cheers, Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > Sent: Wednesday, May 04, 2011 6:40 AM > To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > Cc: siprec@ietf.org > Subject: Re: [siprec] RS to CS relationship as an attribute inRecording block >=20 > Ram, >=20 > If we don't think a Recording object is needed for the case that Charles describes, fine. But I would > also argue that we don't need a Recording Session object. >=20 > John (as individual) >=20 > > -----Original Message----- > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > Sent: 04 May 2011 12:51 > > To: Paul Kyzivat (pkyzivat); Elwell, John > > Cc: siprec@ietf.org > > Subject: RE: [siprec] RS to CS relationship as an attribute=20 > > inRecording block > > > > I agree with Paul here. > > The below use-case that Charles mentions is a good example of two SRCs > > recording the same CS simultaneously via different RS. > > In these cases these are two Recording Sessions each recording the=20 > > same CS and the current model is sufficient for the same. > > > > John, > > > > so I don't see a need to change "Recording Session" to "Recording" > > object in the model. Or are you talking here about grouping of=20 > > recordings ? > > > > As Paul mentioned it will only be recognized as the same CS only if=20 > > the two SRCs coordinate among themselves to use the same UUID for=20 > > it. > > Otherwise we will get two recordings. > > > > Ram > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > > > Behalf Of Paul Kyzivat (pkyzivat) > > > Sent: Wednesday, May 04, 2011 6:52 AM > > > To: Elwell, John > > > Cc: siprec@ietf.org > > > Subject: Re: [siprec] RS to CS relationship as an attribute > > inRecording > > > block > > > > > > Of course this could be accomplished simply by dumb luck: > > > > > > If you and I have separate SRCs and are asking for separate > > recordings > > > of the "same" CS, it will only be recognized as the same CS > > if the two > > > SRCs coordinate among themselves to use the same UUID for > > it. If they > > > don't (likely in this case) the SRS with thing it is two CSs and so > > you > > > get two recodings. > > > > > > Thanks, > > > Paul > > > > > > On 5/3/2011 4:33 PM, Elwell, John wrote: > > > > In that case, I would assert that we need a "Recording" object in > > the > > > metadata model, not a "Recording Session" object. > > > > > > > > John > > > > > > > >> -----Original Message----- > > > >> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > >> Sent: 03 May 2011 21:25 > > > >> To: Elwell, John; Paul Kyzivat (pkyzivat) > > > >> Cc: Parthasarathi R (partr); siprec@ietf.org > > > >> Subject: RE: [siprec] RS to CS relationship as an attribute=20 > > > >> inRecording block > > > >> > > > >> Because one is mine and the other is yours and you want to=20 > > > >> record yours in one format and in combination with other CSs,=20 > > > >> and I > > want mine in > > > >> another format and with other CSs. > > > >> For example you want yours recorded a single mixed audio and=20 > > > >> composited video stream, and I want all separate streams. > > > >> > > > >> Cheers, > > > >> Charles > > > >> > > > >>> -----Original Message----- > > > >>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > >>> Sent: Tuesday, May 03, 2011 12:55 PM > > > >>> To: Charles Eckel (eckelcu); Paul Kyzivat (pkyzivat) > > > >>> Cc: Parthasarathi R (partr); siprec@ietf.org > > > >>> Subject: RE: [siprec] RS to CS relationship as an attribute > > > >> inRecording block > > > >>> > > > >>> Why would I want two recordings of the same CS at the same SRS? > > > >>> > > > >>> John > > > >>> > > > >>>> -----Original Message----- > > > >>>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > >>>> Sent: 03 May 2011 17:56 > > > >>>> To: Elwell, John; Paul Kyzivat (pkyzivat) > > > >>>> Cc: Parthasarathi R (partr); siprec@ietf.org > > > >>>> Subject: RE: [siprec] RS to CS relationship as an attribute=20 > > > >>>> inRecording block > > > >>>> > > > >>>> I do not think the CS is sufficient. For example, how do > > > >> you know if > > > >> I > > > >>>> want another recording of the same CS, or a single recording? > > > >>>> > > > >>>> Cheers, > > > >>>> Charles > > > >>>> > > > >>>>> -----Original Message----- > > > >>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > >>>>> Sent: Tuesday, May 03, 2011 9:39 AM > > > >>>>> To: Charles Eckel (eckelcu); Paul Kyzivat (pkyzivat) > > > >>>>> Cc: Parthasarathi R (partr); siprec@ietf.org > > > >>>>> Subject: RE: [siprec] RS to CS relationship as an attribute > > > >>>> inRecording block > > > >>>>> > > > >>>>> I saw a "recording" as being as being a recording of a > > > >> CS. So yes, > > > >> a > > > >>>> recording can exist outside of an > > > >>>>> RS, and might even span multiple RSs, but doesn't the CS > > > >>>> object cover > > > >>>> this? > > > >>>>> > > > >>>>> John > > > >>>>> > > > >>>>>> -----Original Message----- > > > >>>>>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > >>>>>> Sent: 02 May 2011 14:34 > > > >>>>>> To: Elwell, John; Paul Kyzivat (pkyzivat) > > > >>>>>> Cc: Parthasarathi R (partr); siprec@ietf.org > > > >>>>>> Subject: RE: [siprec] RS to CS relationship as an attribute > > > >>>>>> inRecording block > > > >>>>>> > > > >>>>>> Hi John, > > > >>>>>> > > > >>>>>> Having a recording exist outside of the RS provides, among=20 > > > >>>>>> other things, a way for a SRC to establish a new RS to=20 > > > >>>>>> continue a > > > >>>> recording in the > > > >>>>>> event something goes wrong with initial RS. It also > > > >> facilitates > > > >>>> having > > > >>>>>> multiple SRCs participate in the same recording, which we=20 > > > >>>>>> agreed was out of scope, but is at least possible if a=20 > > > >>>>>> recording exists > > > >>>> outside of > > > >>>> an > > > >>>>>> RS. > > > >>>>>> I suppose the argument could be made this is not really > > > >> necessary. > > > >>>>>> Rather, one could, outside of the scope of SIPREC, decide to > > > >>>> associate > > > >>>>>> multiple RSs in various ways, including stitching them=20 > > > >>>>>> together for the purpose of failover or distributed=20 > > > >>>>>> recordings. Is that what you have in mind? > > > >>>>>> > > > >>>>>> Cheers, > > > >>>>>> Charles > > > >>>>>> > > > >>>>>>> -----Original Message----- > > > >>>>>>> From: Elwell, John > > > >> [mailto:john.elwell@siemens-enterprise.com] > > > >>>>>>> Sent: Saturday, April 30, 2011 3:12 AM > > > >>>>>>> To: Paul Kyzivat (pkyzivat); Charles Eckel (eckelcu) > > > >>>>>>> Cc: Parthasarathi R (partr); siprec@ietf.org > > > >>>>>>> Subject: RE: [siprec] RS to CS relationship as an attribute > > > >>>>>> inRecording block > > > >>>>>>> > > > >>>>>>> I am confused, because this thread has suddenly started to > > > >>>>>> talk about > > > >>>>>> a "recording", whereas metadata- > > > >>>>>>> 00 has an object called "Recording Session", which > > > >>>> 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 > > > >>>>>>> relationship with an RS, and therefore a single SIP > > > >> dialog, I > > > >>>> would > > > >>>>>> suggest they articulate why this > > > >>>>>>> would be needed, with a view to getting it into the metadata > > > >>>> model. > > > >>>>>>> > > > >>>>>>> John > > > >>>>>>> > > > >>>>>>> > > > >>>>>>>> -----Original Message----- > > > >>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > >>>>>>>> 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 > > > >>>>>>>> inRecording block > > > >>>>>>>> > > > >>>>>>>> > > > >>>>>>>> > > > >>>>>>>> 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=20 > > > >>>>>>>> accumulated about a CS or CSG. That data has been=20 > > > >>>>>>>> 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=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 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=20 > > > >>>>>>>>>>>>> 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 > > > >>>>>>>>> > > > >>>>>>>> > > > >>>>>> > > > >>>> > > > >> > > > > > > > _______________________________________________ > > > siprec mailing list > > > siprec@ietf.org > > > https://www.ietf.org/mailman/listinfo/siprec > > > _______________________________________________ > siprec mailing 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 May 5 23:41:07 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 8FEF9E06B4 for ; Thu, 5 May 2011 23:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.251 X-Spam-Level: X-Spam-Status: No, score=-105.251 tagged_above=-999 required=5 tests=[AWL=1.348, 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 PzpJVw-cYePU for ; Thu, 5 May 2011 23:41:06 -0700 (PDT) Received: from mail182.messagelabs.com (mail182.messagelabs.com [85.158.139.83]) by ietfa.amsl.com (Postfix) with SMTP id 5B744E0659 for ; Thu, 5 May 2011 23:41:04 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1304664063!6218338!1 X-StarScan-Version: 6.2.16; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 24638 invoked from network); 6 May 2011 06:41:03 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-9.tower-182.messagelabs.com with SMTP; 6 May 2011 06:41:03 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 7DE7E23F03DB; Fri, 6 May 2011 08:41:03 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 6 May 2011 08:41:03 +0200 From: "Elwell, John" To: "Charles Eckel (eckelcu)" , Henry Lum , "siprec@ietf.org" Date: Fri, 6 May 2011 08:41:02 +0200 Thread-Topic: RTP Recommendations (was RE: [siprec] summary of changes for draft-portman-siprec-protocol-04) Thread-Index: AcwIaR0YuGqr5XvNSMqltXB+NekCpQBR+yhgAAMNUZAAPOGiUABA+nAA Message-ID: References: <059AF07365DC474393A19A3AF187DF7407028E4B@NAHALD.us.int.genesyslab.com> <059AF07365DC474393A19A3AF187DF74070292B2@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] RTP Recommendations (was RE: summary of changes for draft-portman-siprec-protocol-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: Fri, 06 May 2011 06:41:07 -0000 Charles, Thanks for producing this. I see that Andy has also proposed some text on R= TP, although there is very little overlap between the two. Perhaps the two = of you can work on a merged proposal. As has been stated before, I think we want to see some or all of this mater= ial in the architecture document, although if we need any normative materia= l (e.g., on recommending profiles), that would probably need to go into the= protocol document (the architecture document is only Informational). But I think the first thing to do is get some sort of consensus on what we = want to say. If producing an additional individual draft as an interim plac= eholder is the pragmatic way to do it, fine. In any case, we should certain= ly try to have some discussions on these points on Monday's call - if you w= ish I could let you lead that discussion (say 15 minutes, stealing from eac= h of the other slots). Let me know. John (as chair) > -----Original Message----- > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > Sent: 05 May 2011 00:17 > To: Henry Lum; Elwell, John; siprec@ietf.org > Subject: RE: [siprec] summary of changes for > draft-portman-siprec-protocol-04 > > I intended to put together a draft covering RTP recommendations and > models. Unfortunately, I did not have enough bandwidth to get > this done > in time for the interim meeting. Instead, I have attached my > thoughts to > get some feedback. I would be happy to continue work in this area if > people think it is useful. > > ------------------- > Version 0.2 > April 26, 2011 > > (1) Introduction > > This document provides recommendations and guidelines for RTP and RTCP > in the context of SIPREC. In order to communicate most > effectively, the > Session Recording Client (SRC) and the Session Recording (SRS) should > utilize the mechanisms provided by RTP in a well defined and > predicable > manner. It is the goal of this document to make the reader aware of > these mechanisms and provide recommendations and guidelines. This > document is completely informational. It includes no > requirements and no > normative language. > > (2) Definitions > > This document uses the definitions provided in > draft-ietf-siprec-architecture for all SIPREC modules. A Session > Recording Client (SRC), as defined within SIPREC, is expected to > implement one or more of a variety of RTP roles within the context of > various SIPREC use cases. These roles include, but are not limited to, > acting as an end system, a mixer, or a translator. This document uses > the definitions provided in "RTP: A Transport Protocol for Real-Time > Application" [RFC 3550] for these roles. > > > (3) RTCP > > The RTP data transport is augmented by a control protocol (RTCP) to > allow monitoring of the data delivery. RTCP, as defined in > [RFC3550], is > based on the periodic transmission of control packets to all > participants in the RTP session, using the same distribution mechanism > as the data packets. > Support for RTCP is recommended as it provides, among other > things, the > following important functionality in relation to SIPREC: > > 1) Feedback on the quality of the data distribution. This feedback is > important for flow and congestion control functions, and to > get feedback > from the receivers to diagnose faults in the distribution. As > such, RTCP > is a well defined and efficient mechanism for the SRS to > inform the SRC > or any issues that arise in the reception of media that is to be > recorded. > > 2) Carries a persistent transport-level identifier for an RTP source > called the canonical name or CNAME. The SSRC identifier may > change if a > conflict is discovered or a program is restarted; in which case > receivers can use the CNAME to keep track of each participant. > Receivers may also use the CNAME to associate multiple data > streams from > a given participant in a set of related RTP sessions, for example to > synchronize audio and video. Synchronization of media streams is also > facilitated by the NTP and RTP timestamps included in RTCP packets by > data senders. > > > (4) RTP Profile > > The recommended RTP profiles for both the SRC and SRS are "Extended > Secure RTP Profile for Real-time Transport Control Protocol > (RTCP)-Based > Feedback (RTP/SAVPF)", [RFC5124] when using encrypted RTP streams, and > "Extended RTP Profile for Real-time Transport Control Protocol > (RTCP)-Based Feedback (RTP/AVPF)", [RFC4585] when using non encrypted > media streams. However, as this is not a requirement, some > implementations may use "The Secure Real-time Transport Protocol > (SRTP)", [RFC 3711] and "RTP Profile for Audio and Video Conferences > with Minimal Control", AVP [RFC 3551]. Therefore, it is > recommended that > the SRC and SRS not rely entirely on SAVPF or AVPF for core > functionality that may be at least partially achievable using SAVP and > AVP. > > AVPF and SAVPF provide an improved RTCP timer model that allows more > flexible transmission of RTCP packets as response to events, > rather than > strictly according to bandwidth. > SAVP and SAVPF provide media encryption, integrity protection, replay > protection, and a limited form of source authentication. They do not > contain or require a specific keying mechanism. > > > (5) SRSC > > The synchronization source (SSRC), as defined in [RFC3550], is carried > in the RTP header and in various fields of RTCP packets. It > is a random > 32-bit number that is required to be globally unique within an RTP > session. It is crucial that the number be chosen with care in order > that participants on the same network or starting at the same time are > not likely to choose the same number. Guidelines regarding SSRC value > selection and conflict resolution are provided in [RFC3550]. > > The SSRC may also be used to separate different sources of > media within > a single RTP session. For this reason as well as for conflict > resolution, it is important that the SRC and SRC handle > changes in SSRC > values and properly identify the reason of the change. The > CNAME values > carried in RTCP facilitate this identification. > > > (6) CSRC > > The contributing source (CSRC), as defined in [RFC3550], > identifies the > source of a stream of RTP packets that has contributed to the combined > stream produced by an RTP mixer. The mixer inserts a list of the SSRC > identifiers of the sources that contributed to the generation of a > particular packet into the RTP header of that packet. This list is > called the CSRC list. It is recommended that a SRC, when > acting a mixer, > sets the CSRC list accordingly, and that the SRS interprets the CSRC > list appropriately when received. > > > (7) SDES > > The Source Description (SDES), as defined in [RFC3550], contains an > SSRC/CSRC identifier followed by a list of zero or more items, which > carry information about the SSRC/CSRC. End systems send one > SDES packet > containing their own source identifier (the same as the SSRC in the > fixed RTP header). A mixer sends one SDES packet containing > a chunk for > each contributing source from which it is receiving SDES > information, or > multiple complete SDES packets. > > (8) CNAME > > The Canonical End-Point Identifier (CNAME), as defined in [RFC3550], > provide the binding from the SSRC identifier to an identifier for the > source (sender or receiver) that remains constant. It is > important the > an SRC and SRS generate CNAMEs appropriately and use them for this > purpose. Guidelines for generating CNAME values are provided in > "Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names > (CNAMEs)" [RFC6222]. > > > (9) Keepalive > > It is anticipated that media streams in SIPREC may exist in inactive > states for extended periods of times for an of a number of valid > reasons. In order to the bindings and any pinholes in > NATs/firewalls to > remain active during such intervals, it is recommended to follow the > keep-alive procedures in "Application Mechanism for keeping alive the > Network Address Translator > (NAT) mappings associated to RTP/RTCP flows", > [draft-ietf-avt-app-rtp-keepalive] for all RTP media streams. > > > (10) RTCP Feedback Messages > > "Codec Control Messages in the RTP Audio-Visual Profile with Feedback > (AVPF)" [RFC 5104] specifies extensions to the messages > defined in AVPF > [RFC4585]. Support for and proper usage of these messages is important > to SRC and SRS implementations. > > (10.1) Full Intra Request > > A Full Intra Request (FIR) Command, when received by the > designate media > sender, requires that the media sender sends a Decoder > Refresh Point at > the earliest opportunity. Using a decoder refresh point implies > refraining from using any picture sent prior to that point as a > reference for the encoding process of any subsequent picture > sent in the > stream. > > Decoder refresh points, especially Intra or IDR pictures for > H.264 video > codecs, are in general several times larger in size than predicted > pictures. Thus, in scenarios in which the available bit rate is small, > the use of a decoder refresh point implies a delay that is > significantly > longer than the typical picture duration. > > (10.1.1) SIP INFO for FIR > > "XML Schema for Media Control" [RFC5168] defines an Extensible Markup > Language (XML) Schema for video fast update. Implementations are > discouraged from using the method described except for backward > compatibility purposes. Implementations should use FIR messages, as > described in (10.1) instead. > > > (10.2) Picture Loss Indicator > Using the FIR command to recover from errors is explicitly disallowed, > and instead the PLI message defined in AVPF [RFC4585] should be used. > The PLI message reports lost pictures and has been included > in AVPF for > precisely that purpose. > > > (10.3) Temporary Maximum Media Stream Bit Rate Request > > A receiver, translator, or mixer uses the Temporary Maximum > Media Stream > Bit Rate Request (TMMBR) to request a sender to limit the maximum bit > rate for a media stream to the provided value. Appropriate > use of TMMBR > facilitates rapid adaptation to changes in available bandwidth. > > (10.3.1) Renegotiation of SDP bandwidth attribute > > If it is likely that the new value indicated by TMMBR will be > valid for > the remainder of the session, the TMMBR sender is expected to > perform a > renegotiation of the session upper limit using the session signaling > protocol. Therefore for SIPREC, implementations are recommended to use > TMMBR for temporary changes, and renegotiation of bandwidth via SDP > offer/answer of more permanent changes. > > > (11) Symmetric RTP/RTCP > > Within the SDP offer/answer, RTP entities choose the RTP and RTCP > transport addresses (i.e., IP addresses and port numbers) on which to > receive packets. When sending RTP packets; however, they may use a > different IP address or port number for RTP, RTCP, or both. Symmetric > RTP/RTCP requires that the IP address and port number for sending and > receiving RTP/RTCP packets are identical. Using Symmetric RTP and RTCP > [RFC4961] is recommended. > > --------------------- > > Cheers, > Charles > > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Henry Lum > > Sent: Tuesday, May 03, 2011 11:18 AM > > To: Elwell, John; siprec@ietf.org > > Subject: Re: [siprec] summary of changes for > draft-portman-siprec-protocol-04 > > > > Hi John, > > > > Okay, let's discuss this topic further in the interim meeting to > > determine whether there is any need to specify any protocol related > > changes. > > > > Regards, > > Henry > > > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > Sent: Tuesday, May 03, 2011 12:44 PM > > > To: Henry Lum; siprec@ietf.org > > > Subject: RE: summary of changes for > draft-portman-siprec-protocol-04 > > > > > > Henry, > > > > > > Concerning the RTP model, I agree that the consensus to date seems > to > > > be to cover different RTP models, but I feel we should > get something > > > into the architecture draft to start with, and then later see > whether > > > there is any impact on the protocol draft. > > > > > > John > > > > > > > > > > -----Original Message----- > > > > From: siprec-bounces@ietf.org > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Henry Lum > > > > Sent: 02 May 2011 04:09 > > > > To: siprec@ietf.org > > > > Subject: [siprec] summary of changes for > > > > draft-portman-siprec-protocol-04 > > > > > > > > Hi, > > > > > > > > > > > > > > > > I want to summarize the list of changes we are planning to > > > > include in the next revision of the document: > > > > > > > > > > > > > > > > - Remove use of INFO > > > > > > > > - Both INVITE or UPDATE can be used for metadata > > > > transport through content-disposition > > > > > > > > - Recording indication is placed at SDP media level > > > > > > > > - Recording awareness is indicated at SIP level with > > > > options; feature tag was also considered > > > > > > > > - Recording preference is placed at SDP media level > > > > > > > > - RTP model discussion and time synchronization; so > > > > far we seem to agree to handle different RTP models rather > > > > than requiring a single model. There are 3 models we have > > > > identified so far: > > > > > > > > o RTP mixer - SRC mixes media streams and can directly > > > > synchronize timestamps with metadata and also generate RTCP > > > > > > > > o RTP translator - Media streams are simply forwarded to > > > > the SRS by the SRC. SRC is only capable to indicating > > > > start/stop times to the SRS in metadata. > > > > > > > > o RTP endpoint (is that the right term?) - SRC is neither a > > > > mixer nor translator, but is capable of rewriting RTP and > > > > RTCP in order to synchronize on the timestamps with metadata. > > > > > > > > > > > > > > > > Regards, > > > > > > > > Henry > > > > > > > > > > > > > > > > > > > > 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. > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > From john.elwell@siemens-enterprise.com Thu May 5 23:43:11 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE4C3E0663 for ; Thu, 5 May 2011 23:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.27 X-Spam-Level: X-Spam-Status: No, score=-105.27 tagged_above=-999 required=5 tests=[AWL=1.329, 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 ODNyhzglJExW for ; Thu, 5 May 2011 23:43:10 -0700 (PDT) Received: from mail216.messagelabs.com (mail216.messagelabs.com [85.158.143.99]) by ietfa.amsl.com (Postfix) with SMTP id 5AEE1E0659 for ; Thu, 5 May 2011 23:43:09 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-6.tower-216.messagelabs.com!1304664187!3972797!1 X-StarScan-Version: 6.2.16; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 7491 invoked from network); 6 May 2011 06:43:07 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-6.tower-216.messagelabs.com with SMTP; 6 May 2011 06:43:07 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 874181EB83ED; Fri, 6 May 2011 08:43:07 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 6 May 2011 08:43:07 +0200 From: "Elwell, John" To: "Charles Eckel (eckelcu)" , Henry Lum , "siprec@ietf.org" Date: Fri, 6 May 2011 08:43:06 +0200 Thread-Topic: RTP Recommendations (was RE: [siprec] summary of changes for draft-portman-siprec-protocol-04) Thread-Index: AcwIaR0YuGqr5XvNSMqltXB+NekCpQBR+yhgAAMNUZAAPOGiUABA+nAAAAD6LRA= Message-ID: References: <059AF07365DC474393A19A3AF187DF7407028E4B@NAHALD.us.int.genesyslab.com> <059AF07365DC474393A19A3AF187DF74070292B2@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] RTP Recommendations (was RE: summary of changes for draft-portman-siprec-protocol-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: Fri, 06 May 2011 06:43:11 -0000 Charles I won't comment in detail on your text, but a couple of small points: 1. What is meant by "Support for RTCP is recommended"? RTCP is already mand= ated in RFC 3550, so we can't soften that. I know in practice some implemen= tations don't support it, but I don't think we can go against RFC 3550. 2. AVPF and SAVPF are recommended, with the ability to fall back to AVP or = SAVP. It would be good to have some rationale as to why SIPREC merits recom= mending AVPF and SAVPF. Currently the text states their advantages, but doe= sn't explain why these advantages are particularly important for SIPREC. 3. "Using the FIR command to recover from errors is explicitly disallowed, and instead the PLI message defined in AVPF [RFC4585] should be used. The PLI message reports lost pictures and has been included in AVPF for precisely that purpose." This presumably applies only if AVPF/SAVPF is used. 4. The text on symmetric RTP/RTCP seems to mix up the symmetric RTP/RTCP pr= inciple (use of same port/address for transmitting and receiving) and the R= TP/RTCP multiplexing concept (RTP and RTCP on the same port). Perhaps the t= wo should be separated. John (as individual) > -----Original Message----- > From: Elwell, John > Sent: 06 May 2011 07:41 > To: 'Charles Eckel (eckelcu)'; Henry Lum; siprec@ietf.org > Subject: RTP Recommendations (was RE: [siprec] summary of > changes for draft-portman-siprec-protocol-04) > > Charles, > > Thanks for producing this. I see that Andy has also proposed > some text on RTP, although there is very little overlap > between the two. Perhaps the two of you can work on a merged proposal. > > As has been stated before, I think we want to see some or all > of this material in the architecture document, although if we > need any normative material (e.g., on recommending profiles), > that would probably need to go into the protocol document > (the architecture document is only Informational). > > But I think the first thing to do is get some sort of > consensus on what we want to say. If producing an additional > individual draft as an interim placeholder is the pragmatic > way to do it, fine. In any case, we should certainly try to > have some discussions on these points on Monday's call - if > you wish I could let you lead that discussion (say 15 > minutes, stealing from each of the other slots). Let me know. > > John (as chair) > > > -----Original Message----- > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > Sent: 05 May 2011 00:17 > > To: Henry Lum; Elwell, John; siprec@ietf.org > > Subject: RE: [siprec] summary of changes for > > draft-portman-siprec-protocol-04 > > > > I intended to put together a draft covering RTP recommendations and > > models. Unfortunately, I did not have enough bandwidth to get > > this done > > in time for the interim meeting. Instead, I have attached my > > thoughts to > > get some feedback. I would be happy to continue work in this area if > > people think it is useful. > > > > ------------------- > > Version 0.2 > > April 26, 2011 > > > > (1) Introduction > > > > This document provides recommendations and guidelines for > RTP and RTCP > > in the context of SIPREC. In order to communicate most > > effectively, the > > Session Recording Client (SRC) and the Session Recording > (SRS) should > > utilize the mechanisms provided by RTP in a well defined and > > predicable > > manner. It is the goal of this document to make the reader aware of > > these mechanisms and provide recommendations and guidelines. This > > document is completely informational. It includes no > > requirements and no > > normative language. > > > > (2) Definitions > > > > This document uses the definitions provided in > > draft-ietf-siprec-architecture for all SIPREC modules. A Session > > Recording Client (SRC), as defined within SIPREC, is expected to > > implement one or more of a variety of RTP roles within the > context of > > various SIPREC use cases. These roles include, but are not > limited to, > > acting as an end system, a mixer, or a translator. This > document uses > > the definitions provided in "RTP: A Transport Protocol for Real-Time > > Application" [RFC 3550] for these roles. > > > > > > (3) RTCP > > > > The RTP data transport is augmented by a control protocol (RTCP) to > > allow monitoring of the data delivery. RTCP, as defined in > > [RFC3550], is > > based on the periodic transmission of control packets to all > > participants in the RTP session, using the same > distribution mechanism > > as the data packets. > > Support for RTCP is recommended as it provides, among other > > things, the > > following important functionality in relation to SIPREC: > > > > 1) Feedback on the quality of the data distribution. This > feedback is > > important for flow and congestion control functions, and to > > get feedback > > from the receivers to diagnose faults in the distribution. As > > such, RTCP > > is a well defined and efficient mechanism for the SRS to > > inform the SRC > > or any issues that arise in the reception of media that is to be > > recorded. > > > > 2) Carries a persistent transport-level identifier for an RTP source > > called the canonical name or CNAME. The SSRC identifier may > > change if a > > conflict is discovered or a program is restarted; in which case > > receivers can use the CNAME to keep track of each participant. > > Receivers may also use the CNAME to associate multiple data > > streams from > > a given participant in a set of related RTP sessions, for example to > > synchronize audio and video. Synchronization of media > streams is also > > facilitated by the NTP and RTP timestamps included in RTCP > packets by > > data senders. > > > > > > (4) RTP Profile > > > > The recommended RTP profiles for both the SRC and SRS are "Extended > > Secure RTP Profile for Real-time Transport Control Protocol > > (RTCP)-Based > > Feedback (RTP/SAVPF)", [RFC5124] when using encrypted RTP > streams, and > > "Extended RTP Profile for Real-time Transport Control Protocol > > (RTCP)-Based Feedback (RTP/AVPF)", [RFC4585] when using non > encrypted > > media streams. However, as this is not a requirement, some > > implementations may use "The Secure Real-time Transport Protocol > > (SRTP)", [RFC 3711] and "RTP Profile for Audio and Video Conferences > > with Minimal Control", AVP [RFC 3551]. Therefore, it is > > recommended that > > the SRC and SRS not rely entirely on SAVPF or AVPF for core > > functionality that may be at least partially achievable > using SAVP and > > AVP. > > > > AVPF and SAVPF provide an improved RTCP timer model that allows more > > flexible transmission of RTCP packets as response to events, > > rather than > > strictly according to bandwidth. > > SAVP and SAVPF provide media encryption, integrity > protection, replay > > protection, and a limited form of source authentication. They do not > > contain or require a specific keying mechanism. > > > > > > (5) SRSC > > > > The synchronization source (SSRC), as defined in [RFC3550], > is carried > > in the RTP header and in various fields of RTCP packets. It > > is a random > > 32-bit number that is required to be globally unique within an RTP > > session. It is crucial that the number be chosen with care in order > > that participants on the same network or starting at the > same time are > > not likely to choose the same number. Guidelines regarding > SSRC value > > selection and conflict resolution are provided in [RFC3550]. > > > > The SSRC may also be used to separate different sources of > > media within > > a single RTP session. For this reason as well as for conflict > > resolution, it is important that the SRC and SRC handle > > changes in SSRC > > values and properly identify the reason of the change. The > > CNAME values > > carried in RTCP facilitate this identification. > > > > > > (6) CSRC > > > > The contributing source (CSRC), as defined in [RFC3550], > > identifies the > > source of a stream of RTP packets that has contributed to > the combined > > stream produced by an RTP mixer. The mixer inserts a list > of the SSRC > > identifiers of the sources that contributed to the generation of a > > particular packet into the RTP header of that packet. This list is > > called the CSRC list. It is recommended that a SRC, when > > acting a mixer, > > sets the CSRC list accordingly, and that the SRS interprets the CSRC > > list appropriately when received. > > > > > > (7) SDES > > > > The Source Description (SDES), as defined in [RFC3550], contains an > > SSRC/CSRC identifier followed by a list of zero or more items, which > > carry information about the SSRC/CSRC. End systems send one > > SDES packet > > containing their own source identifier (the same as the SSRC in the > > fixed RTP header). A mixer sends one SDES packet containing > > a chunk for > > each contributing source from which it is receiving SDES > > information, or > > multiple complete SDES packets. > > > > (8) CNAME > > > > The Canonical End-Point Identifier (CNAME), as defined in [RFC3550], > > provide the binding from the SSRC identifier to an > identifier for the > > source (sender or receiver) that remains constant. It is > > important the > > an SRC and SRS generate CNAMEs appropriately and use them for this > > purpose. Guidelines for generating CNAME values are provided in > > "Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names > > (CNAMEs)" [RFC6222]. > > > > > > (9) Keepalive > > > > It is anticipated that media streams in SIPREC may exist in inactive > > states for extended periods of times for an of a number of valid > > reasons. In order to the bindings and any pinholes in > > NATs/firewalls to > > remain active during such intervals, it is recommended to follow the > > keep-alive procedures in "Application Mechanism for keeping > alive the > > Network Address Translator > > (NAT) mappings associated to RTP/RTCP flows", > > [draft-ietf-avt-app-rtp-keepalive] for all RTP media streams. > > > > > > (10) RTCP Feedback Messages > > > > "Codec Control Messages in the RTP Audio-Visual Profile > with Feedback > > (AVPF)" [RFC 5104] specifies extensions to the messages > > defined in AVPF > > [RFC4585]. Support for and proper usage of these messages > is important > > to SRC and SRS implementations. > > > > (10.1) Full Intra Request > > > > A Full Intra Request (FIR) Command, when received by the > > designate media > > sender, requires that the media sender sends a Decoder > > Refresh Point at > > the earliest opportunity. Using a decoder refresh point implies > > refraining from using any picture sent prior to that point as a > > reference for the encoding process of any subsequent picture > > sent in the > > stream. > > > > Decoder refresh points, especially Intra or IDR pictures for > > H.264 video > > codecs, are in general several times larger in size than predicted > > pictures. Thus, in scenarios in which the available bit > rate is small, > > the use of a decoder refresh point implies a delay that is > > significantly > > longer than the typical picture duration. > > > > (10.1.1) SIP INFO for FIR > > > > "XML Schema for Media Control" [RFC5168] defines an > Extensible Markup > > Language (XML) Schema for video fast update. Implementations are > > discouraged from using the method described except for backward > > compatibility purposes. Implementations should use FIR messages, as > > described in (10.1) instead. > > > > > > (10.2) Picture Loss Indicator > > Using the FIR command to recover from errors is explicitly > disallowed, > > and instead the PLI message defined in AVPF [RFC4585] > should be used. > > The PLI message reports lost pictures and has been included > > in AVPF for > > precisely that purpose. > > > > > > (10.3) Temporary Maximum Media Stream Bit Rate Request > > > > A receiver, translator, or mixer uses the Temporary Maximum > > Media Stream > > Bit Rate Request (TMMBR) to request a sender to limit the > maximum bit > > rate for a media stream to the provided value. Appropriate > > use of TMMBR > > facilitates rapid adaptation to changes in available bandwidth. > > > > (10.3.1) Renegotiation of SDP bandwidth attribute > > > > If it is likely that the new value indicated by TMMBR will be > > valid for > > the remainder of the session, the TMMBR sender is expected to > > perform a > > renegotiation of the session upper limit using the session signaling > > protocol. Therefore for SIPREC, implementations are > recommended to use > > TMMBR for temporary changes, and renegotiation of bandwidth via SDP > > offer/answer of more permanent changes. > > > > > > (11) Symmetric RTP/RTCP > > > > Within the SDP offer/answer, RTP entities choose the RTP and RTCP > > transport addresses (i.e., IP addresses and port numbers) > on which to > > receive packets. When sending RTP packets; however, they may use a > > different IP address or port number for RTP, RTCP, or both. > Symmetric > > RTP/RTCP requires that the IP address and port number for > sending and > > receiving RTP/RTCP packets are identical. Using Symmetric > RTP and RTCP > > [RFC4961] is recommended. > > > > --------------------- > > > > Cheers, > > Charles > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Henry Lum > > > Sent: Tuesday, May 03, 2011 11:18 AM > > > To: Elwell, John; siprec@ietf.org > > > Subject: Re: [siprec] summary of changes for > > draft-portman-siprec-protocol-04 > > > > > > Hi John, > > > > > > Okay, let's discuss this topic further in the interim meeting to > > > determine whether there is any need to specify any > protocol related > > > changes. > > > > > > Regards, > > > Henry > > > > > > > -----Original Message----- > > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > Sent: Tuesday, May 03, 2011 12:44 PM > > > > To: Henry Lum; siprec@ietf.org > > > > Subject: RE: summary of changes for > > draft-portman-siprec-protocol-04 > > > > > > > > Henry, > > > > > > > > Concerning the RTP model, I agree that the consensus to > date seems > > to > > > > be to cover different RTP models, but I feel we should > > get something > > > > into the architecture draft to start with, and then later see > > whether > > > > there is any impact on the protocol draft. > > > > > > > > John > > > > > > > > > > > > > -----Original Message----- > > > > > From: siprec-bounces@ietf.org > > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Henry Lum > > > > > Sent: 02 May 2011 04:09 > > > > > To: siprec@ietf.org > > > > > Subject: [siprec] summary of changes for > > > > > draft-portman-siprec-protocol-04 > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > I want to summarize the list of changes we are planning to > > > > > include in the next revision of the document: > > > > > > > > > > > > > > > > > > > > - Remove use of INFO > > > > > > > > > > - Both INVITE or UPDATE can be used for metadata > > > > > transport through content-disposition > > > > > > > > > > - Recording indication is placed at SDP media level > > > > > > > > > > - Recording awareness is indicated at SIP level with > > > > > options; feature tag was also considered > > > > > > > > > > - Recording preference is placed at SDP media level > > > > > > > > > > - RTP model discussion and time synchronization; so > > > > > far we seem to agree to handle different RTP models rather > > > > > than requiring a single model. There are 3 models we have > > > > > identified so far: > > > > > > > > > > o RTP mixer - SRC mixes media streams and can directly > > > > > synchronize timestamps with metadata and also generate RTCP > > > > > > > > > > o RTP translator - Media streams are simply forwarded to > > > > > the SRS by the SRC. SRC is only capable to indicating > > > > > start/stop times to the SRS in metadata. > > > > > > > > > > o RTP endpoint (is that the right term?) - SRC is neither a > > > > > mixer nor translator, but is capable of rewriting RTP and > > > > > RTCP in order to synchronize on the timestamps with metadata. > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > Henry > > > > > > > > > > > > > > > > > > > > > > > > > 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. > > > > > > _______________________________________________ > > > siprec mailing list > > > siprec@ietf.org > > > https://www.ietf.org/mailman/listinfo/siprec > > From john.elwell@siemens-enterprise.com Fri May 6 00:14:51 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08095E06CD for ; Fri, 6 May 2011 00:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.388 X-Spam-Level: X-Spam-Status: No, score=-104.388 tagged_above=-999 required=5 tests=[AWL=0.411, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3MSsV4Xegkt for ; Fri, 6 May 2011 00:14:44 -0700 (PDT) Received: from mail216.messagelabs.com (mail216.messagelabs.com [85.158.143.99]) by ietfa.amsl.com (Postfix) with SMTP id DE9ACE065A for ; Fri, 6 May 2011 00:14:43 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-5.tower-216.messagelabs.com!1304666079!4131892!1 X-StarScan-Version: 6.2.16; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 27717 invoked from network); 6 May 2011 07:14:39 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-5.tower-216.messagelabs.com with SMTP; 6 May 2011 07:14:39 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 38B481EB83D3; Fri, 6 May 2011 09:14: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, 6 May 2011 09:14:39 +0200 From: "Elwell, John" To: Paul Kyzivat , "Charles Eckel (eckelcu)" Date: Fri, 6 May 2011 09:14:37 +0200 Thread-Topic: [siprec] Partial updates and identifiers Thread-Index: AcwLbe/6O5xTUHnvTXWhZtIPICkohgATm8nA Message-ID: References: <4D9CB8E1.7030402@cisco.com> <4DC31AC4.9030309@cisco.com> In-Reply-To: <4DC31AC4.9030309@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" , "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: Fri, 06 May 2011 07:14:51 -0000 When is a participant the same participant and when is it different? I call= into a conference from my desk phone. I later drop out and then call in ag= ain to the same conference from my cell phone. The conference is being reco= rded. In this case it is unlikely that the SRC will have any information to= correlate the new caller with the caller who dropped out, unless they happ= en to share the same SIP AOR. I think it is fine for participants to be assigned new IDs each time they j= oin a call or participate in different calls / different recordings. If oth= er attributes of the Participant object can be used to correlate two differ= ent Participant IDs (e.g., the same SIP AoR), this can be made use of. Othe= rwise they are treated as different participants, even though it might be t= he same person. John (as individual) > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 05 May 2011 22:47 > To: Charles Eckel (eckelcu) > Cc: Parthasarathi R (partr); Elwell, John; siprec@ietf.org; > Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr); > Hadriel Kaplan > Subject: Re: [siprec] Partial updates and identifiers > > > > On 5/5/2011 1:10 PM, Charles Eckel (eckelcu) wrote: > > I follow the logic, but let me run through a simple use case. > > > > 0) I am on a call that is part of a recording. Initially, this is > > through CS1 which results in RS1, which is part of recording X. My > > unique participant ID is p0. > > > > I drop off and call back in. I need to be brought back into the same > > recording X. Possible scenarios are: > > > > 1) I call back into CS1, and am added into recording X > through RS1. My > > unique participant ID is p1? > > Maybe. It depends on whether the SRC recognizes you as the same > participant and remembers that it had assigned p1 to you. > If not, then you will presumably appear as a new participant. > > > 2) I call into CS2, and am added to recording X through > RS1. My unique > > participant ID is p2? > > Pretty much the same answer as above. > > Its also up to the SRC to decide if this is part of CS1 or CS2. > > > 3) I call into CS2, and am added to recording X through > RS2. My unique > > participant ID is p3? > > Pretty much the same again. If it is the same SRC, and has > some history > to figure out what is going on, it can continue to use p1. > > If it is a different SRC, then its more of a challenge. There > would have > to be some sharing of info between the two for the new SRC to recover > the old p1. More likely you will get a new p3. > > > If the SRS is able to make use of some other metadata to > realize that > > p0=3Dp1=3Dp2=3Dp3, great, if not, they look like different participants= . > > Yes, if the p(i) are different the SRS could still attempt > correlation, > but its outside our current scope. > > Thanks, > Paul > > > Cheers, > > Charles > > > >> -----Original Message----- > >> From: Parthasarathi R (partr) > >> Sent: Tuesday, May 03, 2011 9:46 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 > >> > >> Hi Charles, > >> > >> In case participants id has to be unique for single RS > with multiple > > CS as you mentioned below mail > >> and also, participant id has to be unique within single CS > which span > > across multiple RS (start& stop > >> of recording within CS scenario), then participant unique > id needs to > > be global (URN UUID) rather than > >> local id like xml:id. Please let me know in case you have any other > > opinion on the same. > >> > >> Thanks > >> Partha > >> > >> -----Original Message----- > >> From: Charles Eckel (eckelcu) > >> Sent: Wednesday, April 20, 2011 2:54 AM > >> 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 > >> > >> 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 > >>> > >>> 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? > >>> > >>> 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 john.elwell@siemens-enterprise.com Fri May 6 00:34:24 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 88D2FE06F3 for ; Fri, 6 May 2011 00:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.294 X-Spam-Level: X-Spam-Status: No, score=-105.294 tagged_above=-999 required=5 tests=[AWL=1.305, 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 qVv0-fbNw2Zg for ; Fri, 6 May 2011 00:34:22 -0700 (PDT) Received: from mail182.messagelabs.com (mail182.messagelabs.com [85.158.139.83]) by ietfa.amsl.com (Postfix) with SMTP id BAA83E06EC for ; Fri, 6 May 2011 00:34:21 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-8.tower-182.messagelabs.com!1304667260!6221459!1 X-StarScan-Version: 6.2.16; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 28067 invoked from network); 6 May 2011 07:34:20 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-8.tower-182.messagelabs.com with SMTP; 6 May 2011 07:34:20 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 54DF223F03DB; Fri, 6 May 2011 09:34:20 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 6 May 2011 09:34:20 +0200 From: "Elwell, John" To: "Parthasarathi R (partr)" , "Charles Eckel (eckelcu)" , "Ram Mohan R (rmohanr)" , "Paul Kyzivat (pkyzivat)" Date: Fri, 6 May 2011 09:34:19 +0200 Thread-Topic: [siprec] RS to CS relationship as an attribute inRecording block Thread-Index: AcwJ+biFoOO41i/hQIKAJCEft7se1gAVN5rwAARo/LAARdMwIAAFIb9gAAx1KmA= Message-ID: References: <4DB58BC7.5090603@cisco.com><4DB820DA.1080200@cisco.com><4DBB59E2.9040200@cisco.com><4DC0AA33.80205@cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD0635764C@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] 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, 06 May 2011 07:34:24 -0000 (answering only the part addressed to me - see below) > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > Sent: 06 May 2011 02:50 > To: Charles Eckel (eckelcu); Elwell, John; Ram Mohan R > (rmohanr); Paul Kyzivat (pkyzivat) > Cc: siprec@ietf.org > Subject: RE: [siprec] RS to CS relationship as an attribute > inRecording block > > Charles, > > Different RS for same recording looks like "recording group" > requirement. There was "recording group" metadata block in the initial > metadata draft and it was removed as there was no known usecase. I'm > reading your usecase which may call for optional "recording > group" block > in metadata model. > > I'll provide some hypothetical scenario: SRC has RS1 with > mixed stream, > RS2 with unmixed stream for CS1. SRS has to aware that RS1 and RS2 > belongs to same recording. This shall be achieved by "recording group" > metadata block which will extend for your scenario which is > outside the > scope of SIPREC. Let us discuss in the meeting whether > "recording group" > is required. > > John, > > Recording Session object has two attributes namely > > 1) Recording Requestor (SRC/SRS) - This may be required in > SRS in terms > of metadata model but which shall be derived from the information > whether RS INVITE is received in SRS or INVITE sent out by SRS. > > 2) Recording type (Persistent/selective) - This attribute will become > irrelevant in case SRS is designed with the principle of "Many RS to > Many CS" as mentioned below in this mail thread. > > Based on the current attributes, metadata format will have no standard > XML element. Please let me know whether your argue is same or not. [JRE] My reasoning for suggesting the RS object class is not needed is beca= use an RS is only a means to an end. It is only a vehicle for delivering me= tadata and media to the SRS for recording. How that data got delivered to t= he SRS is irrelevant for the purposes of storing the data, searching the da= ta and retrieving the data. So I don't think we need to model an RS object = class in our metadata model and we don't need to define a format for such a= n object in our metadata format. Concerning the attributes that currently are part of an RS object: - Recording Requester (SRC/SRS). The SRS already knows this, so does not ne= ed to be receive this information again as part of transmitted metadata. - Recording Type (Persistent/Selective). First, we are defining a generic m= echanism, whereby an RS can support 1 or more CSs and a CS can be recorded = by one or more RSs. Based on this generic mechanism, an SRC can alter the r= elationship between CS and RS at will, and there are probably far more than= two ways it can do that - trying to pigeon hole things into persistent and= selective is too inflexible. Secondly, the SRS can see what is happening from other information in the m= etadata. For the particular case where an RS is retained over a number of C= Ss in sequence, perhaps with gaps between them, it can deduce (if it really= wants to) from metadata updates that this is a persistent case. We don't n= eed to repeat that information (and introduce the possibility of conflictin= g information). John (as individual) > > Thanks > Partha > > -----Original Message----- > From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On Behalf > Of Charles Eckel (eckelcu) > Sent: Friday, May 06, 2011 4:28 AM > To: Elwell, John; Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > Cc: siprec@ietf.org > Subject: Re: [siprec] RS to CS relationship as an attribute > inRecording > block > > The other use case is different RS for the same recording. > That is where > I think recording object comes in handy. > > Cheers, > Charles > > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Elwell, John > > Sent: Wednesday, May 04, 2011 6:40 AM > > To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > Cc: siprec@ietf.org > > Subject: Re: [siprec] RS to CS relationship as an attribute > inRecording block > > > > Ram, > > > > If we don't think a Recording object is needed for the case that > Charles describes, fine. But I would > > also argue that we don't need a Recording Session object. > > > > John (as individual) > > > > > -----Original Message----- > > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > > Sent: 04 May 2011 12:51 > > > To: Paul Kyzivat (pkyzivat); Elwell, John > > > Cc: siprec@ietf.org > > > Subject: RE: [siprec] RS to CS relationship as an attribute > > > inRecording block > > > > > > I agree with Paul here. > > > The below use-case that Charles mentions is a good example of two > SRCs > > > recording the same CS simultaneously via different RS. > > > In these cases these are two Recording Sessions each > recording the > > > same CS and the current model is sufficient for the same. > > > > > > John, > > > > > > so I don't see a need to change "Recording Session" to "Recording" > > > object in the model. Or are you talking here about grouping of > > > recordings ? > > > > > > As Paul mentioned it will only be recognized as the same > CS only if > > > the two SRCs coordinate among themselves to use the same UUID for > > > it. > > > Otherwise we will get two recordings. > > > > > > Ram > > > > > > > -----Original Message----- > > > > From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On > > > > Behalf Of Paul Kyzivat (pkyzivat) > > > > Sent: Wednesday, May 04, 2011 6:52 AM > > > > To: Elwell, John > > > > Cc: siprec@ietf.org > > > > Subject: Re: [siprec] RS to CS relationship as an attribute > > > inRecording > > > > block > > > > > > > > Of course this could be accomplished simply by dumb luck: > > > > > > > > If you and I have separate SRCs and are asking for separate > > > recordings > > > > of the "same" CS, it will only be recognized as the same CS > > > if the two > > > > SRCs coordinate among themselves to use the same UUID for > > > it. If they > > > > don't (likely in this case) the SRS with thing it is two CSs and > so > > > you > > > > get two recodings. > > > > > > > > Thanks, > > > > Paul > > > > > > > > On 5/3/2011 4:33 PM, Elwell, John wrote: > > > > > In that case, I would assert that we need a "Recording" object > in > > > the > > > > metadata model, not a "Recording Session" object. > > > > > > > > > > John > > > > > > > > > >> -----Original Message----- > > > > >> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > > >> Sent: 03 May 2011 21:25 > > > > >> To: Elwell, John; Paul Kyzivat (pkyzivat) > > > > >> Cc: Parthasarathi R (partr); siprec@ietf.org > > > > >> Subject: RE: [siprec] RS to CS relationship as an attribute > > > > >> inRecording block > > > > >> > > > > >> Because one is mine and the other is yours and you want to > > > > >> record yours in one format and in combination with > other CSs, > > > > >> and I > > > want mine in > > > > >> another format and with other CSs. > > > > >> For example you want yours recorded a single mixed audio and > > > > >> composited video stream, and I want all separate streams. > > > > >> > > > > >> Cheers, > > > > >> Charles > > > > >> > > > > >>> -----Original Message----- > > > > >>> From: Elwell, John > [mailto:john.elwell@siemens-enterprise.com] > > > > >>> Sent: Tuesday, May 03, 2011 12:55 PM > > > > >>> To: Charles Eckel (eckelcu); Paul Kyzivat (pkyzivat) > > > > >>> Cc: Parthasarathi R (partr); siprec@ietf.org > > > > >>> Subject: RE: [siprec] RS to CS relationship as an attribute > > > > >> inRecording block > > > > >>> > > > > >>> Why would I want two recordings of the same CS at the same > SRS? > > > > >>> > > > > >>> John > > > > >>> > > > > >>>> -----Original Message----- > > > > >>>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > > >>>> Sent: 03 May 2011 17:56 > > > > >>>> To: Elwell, John; Paul Kyzivat (pkyzivat) > > > > >>>> Cc: Parthasarathi R (partr); siprec@ietf.org > > > > >>>> Subject: RE: [siprec] RS to CS relationship as an > attribute > > > > >>>> inRecording block > > > > >>>> > > > > >>>> I do not think the CS is sufficient. For example, how do > > > > >> you know if > > > > >> I > > > > >>>> want another recording of the same CS, or a single > recording? > > > > >>>> > > > > >>>> Cheers, > > > > >>>> Charles > > > > >>>> > > > > >>>>> -----Original Message----- > > > > >>>>> From: Elwell, John > [mailto:john.elwell@siemens-enterprise.com] > > > > >>>>> Sent: Tuesday, May 03, 2011 9:39 AM > > > > >>>>> To: Charles Eckel (eckelcu); Paul Kyzivat (pkyzivat) > > > > >>>>> Cc: Parthasarathi R (partr); siprec@ietf.org > > > > >>>>> Subject: RE: [siprec] RS to CS relationship as an > attribute > > > > >>>> inRecording block > > > > >>>>> > > > > >>>>> I saw a "recording" as being as being a recording of a > > > > >> CS. So yes, > > > > >> a > > > > >>>> recording can exist outside of an > > > > >>>>> RS, and might even span multiple RSs, but doesn't the CS > > > > >>>> object cover > > > > >>>> this? > > > > >>>>> > > > > >>>>> John > > > > >>>>> > > > > >>>>>> -----Original Message----- > > > > >>>>>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > > >>>>>> Sent: 02 May 2011 14:34 > > > > >>>>>> To: Elwell, John; Paul Kyzivat (pkyzivat) > > > > >>>>>> Cc: Parthasarathi R (partr); siprec@ietf.org > > > > >>>>>> Subject: RE: [siprec] RS to CS relationship as > an attribute > > > > > >>>>>> inRecording block > > > > >>>>>> > > > > >>>>>> Hi John, > > > > >>>>>> > > > > >>>>>> Having a recording exist outside of the RS > provides, among > > > > >>>>>> other things, a way for a SRC to establish a new RS to > > > > >>>>>> continue a > > > > >>>> recording in the > > > > >>>>>> event something goes wrong with initial RS. It also > > > > >> facilitates > > > > >>>> having > > > > >>>>>> multiple SRCs participate in the same recording, > which we > > > > >>>>>> agreed was out of scope, but is at least possible if a > > > > >>>>>> recording exists > > > > >>>> outside of > > > > >>>> an > > > > >>>>>> RS. > > > > >>>>>> I suppose the argument could be made this is not really > > > > >> necessary. > > > > >>>>>> Rather, one could, outside of the scope of SIPREC, decide > to > > > > >>>> associate > > > > >>>>>> multiple RSs in various ways, including stitching them > > > > >>>>>> together for the purpose of failover or distributed > > > > >>>>>> recordings. Is that what you have in mind? > > > > >>>>>> > > > > >>>>>> Cheers, > > > > >>>>>> Charles > > > > >>>>>> > > > > >>>>>>> -----Original Message----- > > > > >>>>>>> From: Elwell, John > > > > >> [mailto:john.elwell@siemens-enterprise.com] > > > > >>>>>>> Sent: Saturday, April 30, 2011 3:12 AM > > > > >>>>>>> To: Paul Kyzivat (pkyzivat); Charles Eckel (eckelcu) > > > > >>>>>>> Cc: Parthasarathi R (partr); siprec@ietf.org > > > > >>>>>>> Subject: RE: [siprec] RS to CS relationship as an > attribute > > > > >>>>>> inRecording block > > > > >>>>>>> > > > > >>>>>>> I am confused, because this thread has suddenly > started to > > > > >>>>>> talk about > > > > >>>>>> a "recording", whereas metadata- > > > > >>>>>>> 00 has an object called "Recording Session", which > > > > >>>> 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 > > > > >>>>>>> relationship with an RS, and therefore a single SIP > > > > >> dialog, I > > > > >>>> would > > > > >>>>>> suggest they articulate why this > > > > >>>>>>> would be needed, with a view to getting it into the > metadata > > > > >>>> model. > > > > >>>>>>> > > > > >>>>>>> John > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>> -----Original Message----- > > > > >>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > > >>>>>>>> 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 > > > > >>>>>>>> inRecording block > > > > >>>>>>>> > > > > >>>>>>>> > > > > >>>>>>>> > > > > >>>>>>>> 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 > > > > >>>>>>>>> > > > > >>>>>>>> > > > > >>>>>> > > > > >>>> > > > > >> > > > > > > > > > _______________________________________________ > > > > siprec mailing list > > > > siprec@ietf.org > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > _______________________________________________ > > siprec mailing 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 May 6 03:07: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 884DBE06FD for ; Fri, 6 May 2011 03:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.146 X-Spam-Level: X-Spam-Status: No, score=-10.146 tagged_above=-999 required=5 tests=[AWL=0.453, 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 EEZszYuK1RZk for ; Fri, 6 May 2011 03:07:11 -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 83E97E06CE for ; Fri, 6 May 2011 03:07:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=27097; q=dns/txt; s=iport; t=1304676430; x=1305886030; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=853LhYgukhTnSlrsVh5A4jKtg8qqB13EA1Ooj4c/N9I=; b=lXUdMr2ASqRm6nRw1H7g6QUYvAHoDdYD8idlY9ZONIpPcykw1rONTt2T U9RVvM0+BNQf4rgmFOfMFQnqrfii87j8UG5MODVX/IVhlToCptdnC6KEa qUb/taxrNHAAa/NUmtkh0MUFzPD7VELFbeljAjtSEnzCketIkAdDIeWOS 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au0AAGPHw02Q/khNgWdsb2JhbACYG44nFAEBFiYliHGeDJ4bgwwBgnwEhjuNSoovNA X-IronPort-AV: E=Sophos;i="4.64,325,1301875200"; d="scan'208";a="87117502" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 06 May 2011 10:07:09 +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 p46A77Rr015129; Fri, 6 May 2011 10:07:08 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, 6 May 2011 15:37:06 +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, 6 May 2011 15:37:05 +0530 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: AcwJ+biFoOO41i/hQIKAJCEft7se1gAVN5rwAARo/LAARdMwIAAFIb9gAAx1KmAABG8XkA== References: <4DB58BC7.5090603@cisco.com><4DB820DA.1080200@cisco.com><4DBB59E2.9040200@cisco.com><4DC0AA33.80205@cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD0635764C@XMB-BGL-417.cisco.com> From: "Parthasarathi R (partr)" To: "Elwell, John" , "Charles Eckel (eckelcu)" , "Ram Mohan R (rmohanr)" , "Paul Kyzivat (pkyzivat)" X-OriginalArrivalTime: 06 May 2011 10:07:06.0389 (UTC) FILETIME=[5AA95C50:01CC0BD5] 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, 06 May 2011 10:07:13 -0000 John, Please read inline Thanks Partha=20 -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 Sent: Friday, May 06, 2011 1:04 PM To: Parthasarathi R (partr); Charles Eckel (eckelcu); Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) Cc: siprec@ietf.org Subject: RE: [siprec] RS to CS relationship as an attribute inRecording block (answering only the part addressed to me - see below) > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > Sent: 06 May 2011 02:50 > To: Charles Eckel (eckelcu); Elwell, John; Ram Mohan R (rmohanr); Paul > Kyzivat (pkyzivat) > Cc: siprec@ietf.org > Subject: RE: [siprec] RS to CS relationship as an attribute=20 > inRecording block > > Charles, > > Different RS for same recording looks like "recording group" > requirement. There was "recording group" metadata block in the initial > metadata draft and it was removed as there was no known usecase. I'm=20 > reading your usecase which may call for optional "recording group"=20 > block in metadata model. > > I'll provide some hypothetical scenario: SRC has RS1 with mixed=20 > stream, > RS2 with unmixed stream for CS1. SRS has to aware that RS1 and RS2=20 > belongs to same recording. This shall be achieved by "recording group" > metadata block which will extend for your scenario which is outside=20 > the scope of SIPREC. Let us discuss in the meeting whether "recording=20 > group" > is required. > > John, > > Recording Session object has two attributes namely > > 1) Recording Requestor (SRC/SRS) - This may be required in SRS in=20 > terms of metadata model but which shall be derived from the=20 > information whether RS INVITE is received in SRS or INVITE sent out by > SRS. > > 2) Recording type (Persistent/selective) - This attribute will become=20 > irrelevant in case SRS is designed with the principle of "Many RS to=20 > Many CS" as mentioned below in this mail thread. > > Based on the current attributes, metadata format will have no standard > XML element. Please let me know whether your argue is same or not. [JRE] My reasoning for suggesting the RS object class is not needed is because an RS is only a means to an end. It is only a vehicle for delivering metadata and media to the SRS for recording. How that data got delivered to the SRS is irrelevant for the purposes of storing the data, searching the data and retrieving the data.=20 It might. Keeping metadata information of whether recording initiated by SRS or SRC may be crucial information in some recording deployment. But I agree with you that there is no known agreed upon element within recording element of metadata format. Let us discuss in detail during the meeting and close this open end =20 So I don't think we need to model an RS object class in our metadata model and we don't need to define a format for such an object in our metadata format. Concerning the attributes that currently are part of an RS object: - Recording Requester (SRC/SRS). The SRS already knows this, so does not need to be receive this information again as part of transmitted metadata. As I mentioned earlier, metadata model is designed from SRS point of view wherein the initiator of RS may be required in SRS for further processing. Let us discuss and close it in the meeting - Recording Type (Persistent/Selective). First, we are defining a generic mechanism, whereby an RS can support 1 or more CSs and a CS can be recorded by one or more RSs. Based on this generic mechanism, an SRC can alter the relationship between CS and RS at will, and there are probably far more than two ways it can do that - trying to pigeon hole things into persistent and selective is too inflexible. Secondly, the SRS can see what is happening from other information in the metadata. For the particular case where an RS is retained over a number of CSs in sequence, perhaps with gaps between them, it can deduce (if it really wants to) from metadata updates that this is a persistent case. We don't need to repeat that information (and introduce the possibility of conflicting information). Agreed. Let us remove this attribute until otherwise somebody has disagreement John (as individual) > > Thanks > Partha > > -----Original Message----- > From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On Behalf Of Charles Eckel (eckelcu) > Sent: Friday, May 06, 2011 4:28 AM > To: Elwell, John; Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > Cc: siprec@ietf.org > Subject: Re: [siprec] RS to CS relationship as an attribute=20 > inRecording block > > The other use case is different RS for the same recording. > That is where > I think recording object comes in handy. > > Cheers, > Charles > > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Elwell, John > > Sent: Wednesday, May 04, 2011 6:40 AM > > To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > Cc: siprec@ietf.org > > Subject: Re: [siprec] RS to CS relationship as an attribute > inRecording block > > > > Ram, > > > > If we don't think a Recording object is needed for the case that > Charles describes, fine. But I would > > also argue that we don't need a Recording Session object. > > > > John (as individual) > > > > > -----Original Message----- > > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > > Sent: 04 May 2011 12:51 > > > To: Paul Kyzivat (pkyzivat); Elwell, John > > > Cc: siprec@ietf.org > > > Subject: RE: [siprec] RS to CS relationship as an attribute=20 > > > inRecording block > > > > > > I agree with Paul here. > > > The below use-case that Charles mentions is a good example of two > SRCs > > > recording the same CS simultaneously via different RS. > > > In these cases these are two Recording Sessions each > recording the > > > same CS and the current model is sufficient for the same. > > > > > > John, > > > > > > so I don't see a need to change "Recording Session" to "Recording" > > > object in the model. Or are you talking here about grouping of=20 > > > recordings ? > > > > > > As Paul mentioned it will only be recognized as the same > CS only if > > > the two SRCs coordinate among themselves to use the same UUID for=20 > > > it. > > > Otherwise we will get two recordings. > > > > > > Ram > > > > > > > -----Original Message----- > > > > From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On > > > > Behalf Of Paul Kyzivat (pkyzivat) > > > > Sent: Wednesday, May 04, 2011 6:52 AM > > > > To: Elwell, John > > > > Cc: siprec@ietf.org > > > > Subject: Re: [siprec] RS to CS relationship as an attribute > > > inRecording > > > > block > > > > > > > > Of course this could be accomplished simply by dumb luck: > > > > > > > > If you and I have separate SRCs and are asking for separate > > > recordings > > > > of the "same" CS, it will only be recognized as the same CS > > > if the two > > > > SRCs coordinate among themselves to use the same UUID for > > > it. If they > > > > don't (likely in this case) the SRS with thing it is two CSs and > so > > > you > > > > get two recodings. > > > > > > > > Thanks, > > > > Paul > > > > > > > > On 5/3/2011 4:33 PM, Elwell, John wrote: > > > > > In that case, I would assert that we need a "Recording" object > in > > > the > > > > metadata model, not a "Recording Session" object. > > > > > > > > > > John > > > > > > > > > >> -----Original Message----- > > > > >> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > > >> Sent: 03 May 2011 21:25 > > > > >> To: Elwell, John; Paul Kyzivat (pkyzivat) > > > > >> Cc: Parthasarathi R (partr); siprec@ietf.org > > > > >> Subject: RE: [siprec] RS to CS relationship as an attribute=20 > > > > >> inRecording block > > > > >> > > > > >> Because one is mine and the other is yours and you want to=20 > > > > >> record yours in one format and in combination with > other CSs, > > > > >> and I > > > want mine in > > > > >> another format and with other CSs. > > > > >> For example you want yours recorded a single mixed audio and=20 > > > > >> composited video stream, and I want all separate streams. > > > > >> > > > > >> Cheers, > > > > >> Charles > > > > >> > > > > >>> -----Original Message----- > > > > >>> From: Elwell, John > [mailto:john.elwell@siemens-enterprise.com] > > > > >>> Sent: Tuesday, May 03, 2011 12:55 PM > > > > >>> To: Charles Eckel (eckelcu); Paul Kyzivat (pkyzivat) > > > > >>> Cc: Parthasarathi R (partr); siprec@ietf.org > > > > >>> Subject: RE: [siprec] RS to CS relationship as an attribute > > > > >> inRecording block > > > > >>> > > > > >>> Why would I want two recordings of the same CS at the same > SRS? > > > > >>> > > > > >>> John > > > > >>> > > > > >>>> -----Original Message----- > > > > >>>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > > >>>> Sent: 03 May 2011 17:56 > > > > >>>> To: Elwell, John; Paul Kyzivat (pkyzivat) > > > > >>>> Cc: Parthasarathi R (partr); siprec@ietf.org > > > > >>>> Subject: RE: [siprec] RS to CS relationship as an > attribute > > > > >>>> inRecording block > > > > >>>> > > > > >>>> I do not think the CS is sufficient. For example, how do > > > > >> you know if > > > > >> I > > > > >>>> want another recording of the same CS, or a single > recording? > > > > >>>> > > > > >>>> Cheers, > > > > >>>> Charles > > > > >>>> > > > > >>>>> -----Original Message----- > > > > >>>>> From: Elwell, John > [mailto:john.elwell@siemens-enterprise.com] > > > > >>>>> Sent: Tuesday, May 03, 2011 9:39 AM > > > > >>>>> To: Charles Eckel (eckelcu); Paul Kyzivat (pkyzivat) > > > > >>>>> Cc: Parthasarathi R (partr); siprec@ietf.org > > > > >>>>> Subject: RE: [siprec] RS to CS relationship as an > attribute > > > > >>>> inRecording block > > > > >>>>> > > > > >>>>> I saw a "recording" as being as being a recording of a > > > > >> CS. So yes, > > > > >> a > > > > >>>> recording can exist outside of an > > > > >>>>> RS, and might even span multiple RSs, but doesn't the CS > > > > >>>> object cover > > > > >>>> this? > > > > >>>>> > > > > >>>>> John > > > > >>>>> > > > > >>>>>> -----Original Message----- > > > > >>>>>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > > >>>>>> Sent: 02 May 2011 14:34 > > > > >>>>>> To: Elwell, John; Paul Kyzivat (pkyzivat) > > > > >>>>>> Cc: Parthasarathi R (partr); siprec@ietf.org > > > > >>>>>> Subject: RE: [siprec] RS to CS relationship as > an attribute > > > > > >>>>>> inRecording block > > > > >>>>>> > > > > >>>>>> Hi John, > > > > >>>>>> > > > > >>>>>> Having a recording exist outside of the RS > provides, among > > > > >>>>>> other things, a way for a SRC to establish a new RS to=20 > > > > >>>>>> continue a > > > > >>>> recording in the > > > > >>>>>> event something goes wrong with initial RS. It also > > > > >> facilitates > > > > >>>> having > > > > >>>>>> multiple SRCs participate in the same recording, > which we > > > > >>>>>> agreed was out of scope, but is at least possible if a=20 > > > > >>>>>> recording exists > > > > >>>> outside of > > > > >>>> an > > > > >>>>>> RS. > > > > >>>>>> I suppose the argument could be made this is not really > > > > >> necessary. > > > > >>>>>> Rather, one could, outside of the scope of SIPREC, decide > to > > > > >>>> associate > > > > >>>>>> multiple RSs in various ways, including stitching them=20 > > > > >>>>>> together for the purpose of failover or distributed=20 > > > > >>>>>> recordings. Is that what you have in mind? > > > > >>>>>> > > > > >>>>>> Cheers, > > > > >>>>>> Charles > > > > >>>>>> > > > > >>>>>>> -----Original Message----- > > > > >>>>>>> From: Elwell, John > > > > >> [mailto:john.elwell@siemens-enterprise.com] > > > > >>>>>>> Sent: Saturday, April 30, 2011 3:12 AM > > > > >>>>>>> To: Paul Kyzivat (pkyzivat); Charles Eckel (eckelcu) > > > > >>>>>>> Cc: Parthasarathi R (partr); siprec@ietf.org > > > > >>>>>>> Subject: RE: [siprec] RS to CS relationship as an > attribute > > > > >>>>>> inRecording block > > > > >>>>>>> > > > > >>>>>>> I am confused, because this thread has suddenly > started to > > > > >>>>>> talk about > > > > >>>>>> a "recording", whereas metadata- > > > > >>>>>>> 00 has an object called "Recording Session", which > > > > >>>> 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 > > > > >>>>>>> relationship with an RS, and therefore a single SIP > > > > >> dialog, I > > > > >>>> would > > > > >>>>>> suggest they articulate why this > > > > >>>>>>> would be needed, with a view to getting it into the > metadata > > > > >>>> model. > > > > >>>>>>> > > > > >>>>>>> John > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>> -----Original Message----- > > > > >>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > > >>>>>>>> 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 > > > > >>>>>>>> inRecording block > > > > >>>>>>>> > > > > >>>>>>>> > > > > >>>>>>>> > > > > >>>>>>>> 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=20 > > > > >>>>>>>> accumulated about a CS or CSG. That data has been=20 > > > > >>>>>>>> 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=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 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=20 > > > > >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec > > > > >>>>>>>>>>>> _______________________________________________ > > > > >>>>>>>>>>>> siprec mailing list siprec@ietf.org=20 > > > > >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec > > > > >>>>>>>>>>>> > > > > >>>>>>>>>> _______________________________________________ > > > > >>>>>>>>>> siprec mailing list > > > > >>>>>>>>>> siprec@ietf.org > > > > >>>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec > > > > >>>>>>>>>> _______________________________________________ > > > > >>>>>>>>>> siprec mailing list > > > > >>>>>>>>>> siprec@ietf.org > > > > >>>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec > > > > >>>>>>>>> > > > > >>>>>>>> > > > > >>>>>> > > > > >>>> > > > > >> > > > > > > > > > _______________________________________________ > > > > siprec mailing list > > > > siprec@ietf.org > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > _______________________________________________ > > siprec mailing 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 May 6 05:10:40 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFB05E06EA for ; Fri, 6 May 2011 05:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.582 X-Spam-Level: X-Spam-Status: No, score=-109.582 tagged_above=-999 required=5 tests=[AWL=-0.783, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IyovdVSVApXB for ; Fri, 6 May 2011 05:10:38 -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 D2AEDE064B for ; Fri, 6 May 2011 05:10:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=26459; q=dns/txt; s=iport; t=1304683838; x=1305893438; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=KldVRq+JRdcj2Jc7nn/39aviAUOAcsTbG3bHuUOj5Vs=; b=i1IDENsV6cVio2+hL6npMeKoAotUXy4bgC+S9jFqnpHvMVI7yQbfvSD5 L5oijgy/kegLJ7UVXX/hpVC+TvS83OflqBs6BUmvWgJsJbz6UB5ZcuGgP OtDWPKYANyNrUCaR/G5LiGdW1pgkxzbLVAa6yl5oHBymsMWOVfoV23TXJ Y=; X-IronPort-AV: E=Sophos;i="4.64,326,1301875200"; d="scan'208";a="442977372" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-1.cisco.com with ESMTP; 06 May 2011 12:10:38 +0000 Received: from [161.44.174.124] (dhcp-161-44-174-124.cisco.com [161.44.174.124]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p46CAbfY000828; Fri, 6 May 2011 12:10:37 GMT Message-ID: <4DC3E53E.9050202@cisco.com> Date: Fri, 06 May 2011 08:10:38 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Elwell, John" References: <4D9CB8E1.7030402@cisco.com> <4DC31AC4.9030309@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: Fri, 06 May 2011 12:10:40 -0000 John, I think we are in agreement. My point was that some SRCs may be smarter about this than others. If they are able to figure out when to reuse the same participant id, then that is great, but not required. (Of course they must not reuse the same participant id *by accident*.) Thanks, Paul On 5/6/2011 3:14 AM, Elwell, John wrote: > When is a participant the same participant and when is it different? I call into a conference from my desk phone. I later drop out and then call in again to the same conference from my cell phone. The conference is being recorded. In this case it is unlikely that the SRC will have any information to correlate the new caller with the caller who dropped out, unless they happen to share the same SIP AOR. > > I think it is fine for participants to be assigned new IDs each time they join a call or participate in different calls / different recordings. If other attributes of the Participant object can be used to correlate two different Participant IDs (e.g., the same SIP AoR), this can be made use of. Otherwise they are treated as different participants, even though it might be the same person. > > John (as individual) > > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: 05 May 2011 22:47 >> To: Charles Eckel (eckelcu) >> Cc: Parthasarathi R (partr); Elwell, John; siprec@ietf.org; >> Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr); >> Hadriel Kaplan >> Subject: Re: [siprec] Partial updates and identifiers >> >> >> >> On 5/5/2011 1:10 PM, Charles Eckel (eckelcu) wrote: >>> I follow the logic, but let me run through a simple use case. >>> >>> 0) I am on a call that is part of a recording. Initially, this is >>> through CS1 which results in RS1, which is part of recording X. My >>> unique participant ID is p0. >>> >>> I drop off and call back in. I need to be brought back into the same >>> recording X. Possible scenarios are: >>> >>> 1) I call back into CS1, and am added into recording X >> through RS1. My >>> unique participant ID is p1? >> >> Maybe. It depends on whether the SRC recognizes you as the same >> participant and remembers that it had assigned p1 to you. >> If not, then you will presumably appear as a new participant. >> >>> 2) I call into CS2, and am added to recording X through >> RS1. My unique >>> participant ID is p2? >> >> Pretty much the same answer as above. >> >> Its also up to the SRC to decide if this is part of CS1 or CS2. >> >>> 3) I call into CS2, and am added to recording X through >> RS2. My unique >>> participant ID is p3? >> >> Pretty much the same again. If it is the same SRC, and has >> some history >> to figure out what is going on, it can continue to use p1. >> >> If it is a different SRC, then its more of a challenge. There >> would have >> to be some sharing of info between the two for the new SRC to recover >> the old p1. More likely you will get a new p3. >> >>> If the SRS is able to make use of some other metadata to >> realize that >>> p0=p1=p2=p3, great, if not, they look like different participants. >> >> Yes, if the p(i) are different the SRS could still attempt >> correlation, >> but its outside our current scope. >> >> Thanks, >> Paul >> >>> Cheers, >>> Charles >>> >>>> -----Original Message----- >>>> From: Parthasarathi R (partr) >>>> Sent: Tuesday, May 03, 2011 9:46 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 >>>> >>>> Hi Charles, >>>> >>>> In case participants id has to be unique for single RS >> with multiple >>> CS as you mentioned below mail >>>> and also, participant id has to be unique within single CS >> which span >>> across multiple RS (start& stop >>>> of recording within CS scenario), then participant unique >> id needs to >>> be global (URN UUID) rather than >>>> local id like xml:id. Please let me know in case you have any other >>> opinion on the same. >>>> >>>> Thanks >>>> Partha >>>> >>>> -----Original Message----- >>>> From: Charles Eckel (eckelcu) >>>> Sent: Wednesday, April 20, 2011 2:54 AM >>>> 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 >>>> >>>> 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 >>>>> >>>>> 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? >>>>> >>>>> 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 Henry.Lum@alcatel-lucent.com Fri May 6 09:09:36 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73597E0726 for ; Fri, 6 May 2011 09:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.061 X-Spam-Level: X-Spam-Status: No, score=-6.061 tagged_above=-999 required=5 tests=[AWL=0.538, 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 eBhaEpVwHkFG for ; Fri, 6 May 2011 09:09:35 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 9A708E0715 for ; Fri, 6 May 2011 09:09:35 -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 p46G9YYF000535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 6 May 2011 11:09:34 -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 p46G9WAB001145 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 6 May 2011 11:09:34 -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 p46G9WUu026352; Fri, 6 May 2011 09:09:32 -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, 6 May 2011 09:09:31 -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, 6 May 2011 09:09:28 -0700 Message-ID: <059AF07365DC474393A19A3AF187DF7407029A86@NAHALD.us.int.genesyslab.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] I-D Action: draft-portman-siprec-protocol-04.txt Thread-Index: AcwKb3en29WlsLJjSQWCyOX159h+/AAl5jQAAEAVZOA= References: <20110504152410.25362.51406.idtracker@ietfa.amsl.com> From: "Henry Lum" To: "Elwell, John" , X-OriginalArrivalTime: 06 May 2011 16:09:31.0951 (UTC) FILETIME=[FC06CBF0:01CC0C07] 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] I-D Action: draft-portman-siprec-protocol-04.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 16:09:36 -0000 I originally thought it would be useful consolidate all metadata-related formats in the metadata/metadata-format drafts, but the snapshot request does sound like a protocol issue rather than a metadata issue since the request itself does not need to contain any metadata. In fact, the snapshot request content does not even need to be XML at all. Henry > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Elwell, John > Sent: Thursday, May 05, 2011 5:37 AM > To: siprec@ietf.org > Subject: Re: [siprec] I-D Action: draft-portman-siprec-protocol-04.txt >=20 > Leon, Henry and others, >=20 > Thanks for doing this revision. One question: > In 5.4.1 it states: > "The format of the metadata snapshot request > is described in [I-D.ietf-siprec-metadata]." > I searched for this in the metadata draft (and also in the metadata- > format draft, which contains candidate material for merging into the > metadata draft) and could find nothing, so I assume it is your intent > that something should be added to the metadata draft. However, although > the metadata model and its format should be specified in the metadata > draft, a snapshot request sounds to me like something more appropriate > for the protocol draft. >=20 > John >=20 >=20 > > -----Original Message----- > > From: i-d-announce-bounces@ietf.org > > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > > internet-drafts@ietf.org > > Sent: 04 May 2011 16:24 > > To: i-d-announce@ietf.org > > Subject: I-D Action: draft-portman-siprec-protocol-04.txt > > > > A New Internet-Draft is available from the on-line > > Internet-Drafts directories. > > > > Title : Session Recording Protocol > > Author(s) : Leon Portman > > Henry Lum > > Alan Johnston > > Andrew Hutton > > Filename : draft-portman-siprec-protocol-04.txt > > Pages : 20 > > Date : 2011-05-04 > > > > The Session Recording Protocol is used for establishing recording > > session and reporting of the metadata of the communication > session. > > > > This document specifies the Session Recording Protocol. > > The protocol > > is used between Session Recording Client (SRC) and Session > > Recording > > Server (SRS). > > > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-portman-siprec-proto > > col-04.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > This Internet-Draft can be retrieved at: > > ftp://ftp.ietf.org/internet-drafts/draft-portman-siprec-protoc > > ol-04.txt > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > _______________________________________________ > 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 Fri May 6 10:05:18 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 674A3E073A for ; Fri, 6 May 2011 10:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.549 X-Spam-Level: X-Spam-Status: No, score=-9.549 tagged_above=-999 required=5 tests=[AWL=-0.750, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M57sM1CI9FAl for ; Fri, 6 May 2011 10:05:13 -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 82AE0E0728 for ; Fri, 6 May 2011 10:05:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=29080; q=dns/txt; s=iport; t=1304701513; x=1305911113; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=mVZHV8OcwIdScD/XNiSJXpY7SuukYqyRMowg4crIyvc=; b=UynohnMefn2SqAEkl2x7ZBbxZMkDWJRxn2yuUO0/nkbkuNhGo1wBScw7 XZZPWvd3DNT7FtikQOLY+7ZMTpQvHyA2JErcRyDXjThxyM0vnGEP/upSX h/N1/o8h6leVlfWknIF0TbdqAyQcp9Nm46ydgN5E8vhbHZ5f79lYbfPC5 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlsBAJspxE2rRDoG/2dsb2JhbACYII4sd6YNngmDDYJ8BIY9jUiKRw X-IronPort-AV: E=Sophos;i="4.64,327,1301875200"; d="scan'208";a="351935830" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-2.cisco.com with ESMTP; 06 May 2011 17:05:12 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p46H59FP001496; Fri, 6 May 2011 17:05:12 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); Fri, 6 May 2011 10:05:07 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: B9g/ JIVU KjF4 RHkD RhIi Spwi S93q UGdf UN5T akXN a1RP dUKr d02h ejww hKZa lO5U; 3; aABrAGEAcABsAGEAbgBAAGEAYwBtAGUAcABhAGMAawBlAHQALgBjAG8AbQA7AGoAbwBoAG4ALgBlAGwAdwBlAGwAbABAAHMAaQBlAG0AZQBuAHMALQBlAG4AdABlAHIAcAByAGkAcwBlAC4AYwBvAG0AOwBzAGkAcAByAGUAYwBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {EF8C18BE-EAB0-41DF-8042-011739238D45}; ZQBjAGsAZQBsAGMAdQBAAGMAaQBzAGMAbwAuAGMAbwBtAA==; Fri, 06 May 2011 17:04:57 GMT; UgBFADoAIABbAHMAaQBwAHIAZQBjAF0AIABQAGEAcgB0AGkAYQBsACAAdQBwAGQAYQB0AGUAcwAgAGEAbgBkACAAaQBkAGUAbgB0AGkAZgBpAGUAcgBzAA== MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {EF8C18BE-EAB0-41DF-8042-011739238D45} Content-class: urn:content-classes:message Date: Fri, 6 May 2011 10:04:57 -0700 Message-ID: In-Reply-To: <4DC3E53E.9050202@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Partial updates and identifiers Thread-Index: AcwL5qDDTEqeT1RYRbqQf4mUp+Mu8AAJ8b5w References: <4D9CB8E1.7030402@cisco.com> <4DC31AC4.9030309@cisco.com> <4DC3E53E.9050202@cisco.com> From: "Charles Eckel (eckelcu)" To: "Paul Kyzivat (pkyzivat)" , "Elwell, John" X-OriginalArrivalTime: 06 May 2011 17:05:07.0097 (UTC) FILETIME=[BFEDB090:01CC0C0F] Cc: siprec@ietf.org, "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: Fri, 06 May 2011 17:05:18 -0000 The reason I brought this up was in response to Partha's assertion that participant IDs need to be globally unique rather than unique within a given CS, RS, or recording. The point I was trying to make was that an SRS might actually want a way to correlate participants, either by participant ID or some other metadata or some mechanism outside the scope of SIPREC. While this is still possible with globally unique participant IDs, it is made more difficult. So in this case, mandating that participant IDs be globally unique make things more complex/difficult. Why are globally unique participant IDs across all CSs and RSs required? That is what I am trying to understand. They is some cost associated with this, and I want to make sure the cost is warranted. Cheers, Charles > -----Original Message----- > From: Paul Kyzivat (pkyzivat) > Sent: Friday, May 06, 2011 5:11 AM > To: Elwell, John > Cc: Charles Eckel (eckelcu); Parthasarathi R (partr); siprec@ietf.org; Peter Saint-Andre (psaintan); > Joe Hildebrand (jhildebr); Hadriel Kaplan > Subject: Re: [siprec] Partial updates and identifiers >=20 > John, >=20 > I think we are in agreement. My point was that some SRCs may be smarter > about this than others. If they are able to figure out when to reuse the > same participant id, then that is great, but not required. >=20 > (Of course they must not reuse the same participant id *by accident*.) >=20 > Thanks, > Paul >=20 > On 5/6/2011 3:14 AM, Elwell, John wrote: > > When is a participant the same participant and when is it different? I call into a conference from > my desk phone. I later drop out and then call in again to the same conference from my cell phone. The > conference is being recorded. In this case it is unlikely that the SRC will have any information to > correlate the new caller with the caller who dropped out, unless they happen to share the same SIP > AOR. > > > > I think it is fine for participants to be assigned new IDs each time they join a call or participate > in different calls / different recordings. If other attributes of the Participant object can be used > to correlate two different Participant IDs (e.g., the same SIP AoR), this can be made use of. > Otherwise they are treated as different participants, even though it might be the same person. > > > > John (as individual) > > > > > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: 05 May 2011 22:47 > >> To: Charles Eckel (eckelcu) > >> Cc: Parthasarathi R (partr); Elwell, John; siprec@ietf.org; > >> Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr); > >> Hadriel Kaplan > >> Subject: Re: [siprec] Partial updates and identifiers > >> > >> > >> > >> On 5/5/2011 1:10 PM, Charles Eckel (eckelcu) wrote: > >>> I follow the logic, but let me run through a simple use case. > >>> > >>> 0) I am on a call that is part of a recording. Initially, this is > >>> through CS1 which results in RS1, which is part of recording X. My > >>> unique participant ID is p0. > >>> > >>> I drop off and call back in. I need to be brought back into the same > >>> recording X. Possible scenarios are: > >>> > >>> 1) I call back into CS1, and am added into recording X > >> through RS1. My > >>> unique participant ID is p1? > >> > >> Maybe. It depends on whether the SRC recognizes you as the same > >> participant and remembers that it had assigned p1 to you. > >> If not, then you will presumably appear as a new participant. > >> > >>> 2) I call into CS2, and am added to recording X through > >> RS1. My unique > >>> participant ID is p2? > >> > >> Pretty much the same answer as above. > >> > >> Its also up to the SRC to decide if this is part of CS1 or CS2. > >> > >>> 3) I call into CS2, and am added to recording X through > >> RS2. My unique > >>> participant ID is p3? > >> > >> Pretty much the same again. If it is the same SRC, and has > >> some history > >> to figure out what is going on, it can continue to use p1. > >> > >> If it is a different SRC, then its more of a challenge. There > >> would have > >> to be some sharing of info between the two for the new SRC to recover > >> the old p1. More likely you will get a new p3. > >> > >>> If the SRS is able to make use of some other metadata to > >> realize that > >>> p0=3Dp1=3Dp2=3Dp3, great, if not, they look like different = participants. > >> > >> Yes, if the p(i) are different the SRS could still attempt > >> correlation, > >> but its outside our current scope. > >> > >> Thanks, > >> Paul > >> > >>> Cheers, > >>> Charles > >>> > >>>> -----Original Message----- > >>>> From: Parthasarathi R (partr) > >>>> Sent: Tuesday, May 03, 2011 9:46 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 > >>>> > >>>> Hi Charles, > >>>> > >>>> In case participants id has to be unique for single RS > >> with multiple > >>> CS as you mentioned below mail > >>>> and also, participant id has to be unique within single CS > >> which span > >>> across multiple RS (start& stop > >>>> of recording within CS scenario), then participant unique > >> id needs to > >>> be global (URN UUID) rather than > >>>> local id like xml:id. Please let me know in case you have any other > >>> opinion on the same. > >>>> > >>>> Thanks > >>>> Partha > >>>> > >>>> -----Original Message----- > >>>> From: Charles Eckel (eckelcu) > >>>> Sent: Wednesday, April 20, 2011 2:54 AM > >>>> 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 > >>>> > >>>> 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 > >>>>> > >>>>> 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? > >>>>> > >>>>> 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 eckelcu@cisco.com Fri May 6 10:19:36 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5175FE073D for ; Fri, 6 May 2011 10:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.416 X-Spam-Level: X-Spam-Status: No, score=-10.416 tagged_above=-999 required=5 tests=[AWL=0.183, 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 p25udiel+t1I for ; Fri, 6 May 2011 10:19:34 -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 6B3BAE072C for ; Fri, 6 May 2011 10:19:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=25172; q=dns/txt; s=iport; t=1304702374; x=1305911974; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=aylDUO2PhvXwCrEAd32zQgN744IlyYcgScsHeSeJrlk=; b=dAf4EzTUKXtkBRp3F64oye/VU5R36LyGtv35Mfst4LnMHUImTdwcxxwr vUPGR8evmsOcze/CfhX/xNm5M5ylkHPqm9/W6bmSkreBbMcWJumfpRGJm /sMqiKcMRr8kfBdfhb5wl8hz5uaOXMDiyMfjOQaKrHqVKhuDt87ts15u3 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlsBAF4txE2rRDoJ/2dsb2JhbACYII4sd6YQngmDDAGCfASGPY1Iikcc X-IronPort-AV: E=Sophos;i="4.64,327,1301875200"; d="scan'208";a="693283470" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-6.cisco.com with ESMTP; 06 May 2011 17:19:33 +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 p46HJXTG000579; Fri, 6 May 2011 17:19:33 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, 6 May 2011 10:19:33 -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, 6 May 2011 10:19:32 -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: AcwJ+biFoOO41i/hQIKAJCEft7se1gAVN5rwAARo/LAARdMwIAAFIb9gACEtEzA= References: <4DB58BC7.5090603@cisco.com><4DB820DA.1080200@cisco.com><4DBB59E2.9040200@cisco.com><4DC0AA33.80205@cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD0635764C@XMB-BGL-417.cisco.com> From: "Charles Eckel (eckelcu)" To: "Parthasarathi R (partr)" , "Elwell, John" , "Ram Mohan R (rmohanr)" , "Paul Kyzivat (pkyzivat)" X-OriginalArrivalTime: 06 May 2011 17:19:33.0911 (UTC) FILETIME=[C4970270:01CC0C11] 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, 06 May 2011 17:19:36 -0000 Hi Partha, I am responding to the first part of the e-mail as John and yourself have already continued the second part in another thread. A recording group would work for me as well. My goal is to have some way for an SRC to tell the SRS this RS for meant to be part of something that already exists, perhaps on this same SRS. We can call it a recording group, and recording object, and recording ID, or whatever we want. The idea is that when a recording starts, a recording ID is generated, either by the SRC, or by the SRS if none is provided by the SRC. This recording ID could be used to tie other RSs to the same recording. I agree this could be achieved by a mechanism outside of SIPREC, but I think it might be helpful to build it into SIPREC was it seems like a pretty useful and basic feature to me.=20 Cheers, Charles > -----Original Message----- > From: Parthasarathi R (partr) > Sent: Thursday, May 05, 2011 6:50 PM > To: Charles Eckel (eckelcu); Elwell, John; Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > Cc: siprec@ietf.org > Subject: RE: [siprec] RS to CS relationship as an attribute inRecording block >=20 > Charles, >=20 > Different RS for same recording looks like "recording group" requirement. There was "recording group" > metadata block in the initial metadata draft and it was removed as there was no known usecase. I'm > reading your usecase which may call for optional "recording group" block in metadata model. >=20 > I'll provide some hypothetical scenario: SRC has RS1 with mixed stream, RS2 with unmixed stream for > CS1. SRS has to aware that RS1 and RS2 belongs to same recording. This shall be achieved by "recording > group" metadata block which will extend for your scenario which is outside the scope of SIPREC. Let us > discuss in the meeting whether "recording group" is required. >=20 > John, >=20 > Recording Session object has two attributes namely >=20 > 1) Recording Requestor (SRC/SRS) - This may be required in SRS in terms of metadata model but which > shall be derived from the information whether RS INVITE is received in SRS or INVITE sent out by SRS. >=20 > 2) Recording type (Persistent/selective) - This attribute will become irrelevant in case SRS is > designed with the principle of "Many RS to Many CS" as mentioned below in this mail thread. >=20 > Based on the current attributes, metadata format will have no standard XML element. Please let me know > whether your argue is same or not. >=20 > Thanks > Partha >=20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Charles Eckel (eckelcu) > Sent: Friday, May 06, 2011 4:28 AM > To: Elwell, John; Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > Cc: siprec@ietf.org > Subject: Re: [siprec] RS to CS relationship as an attribute inRecording block >=20 > The other use case is different RS for the same recording. That is where I think recording object > comes in handy. >=20 > Cheers, > Charles >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Elwell, John > > Sent: Wednesday, May 04, 2011 6:40 AM > > To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > Cc: siprec@ietf.org > > Subject: Re: [siprec] RS to CS relationship as an attribute > inRecording block > > > > Ram, > > > > If we don't think a Recording object is needed for the case that > Charles describes, fine. But I would > > also argue that we don't need a Recording Session object. > > > > John (as individual) > > > > > -----Original Message----- > > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > > Sent: 04 May 2011 12:51 > > > To: Paul Kyzivat (pkyzivat); Elwell, John > > > Cc: siprec@ietf.org > > > Subject: RE: [siprec] RS to CS relationship as an attribute > > > inRecording block > > > > > > I agree with Paul here. > > > The below use-case that Charles mentions is a good example of two > SRCs > > > recording the same CS simultaneously via different RS. > > > In these cases these are two Recording Sessions each recording the > > > same CS and the current model is sufficient for the same. > > > > > > John, > > > > > > so I don't see a need to change "Recording Session" to "Recording" > > > object in the model. Or are you talking here about grouping of > > > recordings ? > > > > > > As Paul mentioned it will only be recognized as the same CS only if > > > the two SRCs coordinate among themselves to use the same UUID for > > > it. > > > Otherwise we will get two recordings. > > > > > > Ram > > > > > > > -----Original Message----- > > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > > > Behalf Of Paul Kyzivat (pkyzivat) > > > > Sent: Wednesday, May 04, 2011 6:52 AM > > > > To: Elwell, John > > > > Cc: siprec@ietf.org > > > > Subject: Re: [siprec] RS to CS relationship as an attribute > > > inRecording > > > > block > > > > > > > > Of course this could be accomplished simply by dumb luck: > > > > > > > > If you and I have separate SRCs and are asking for separate > > > recordings > > > > of the "same" CS, it will only be recognized as the same CS > > > if the two > > > > SRCs coordinate among themselves to use the same UUID for > > > it. If they > > > > don't (likely in this case) the SRS with thing it is two CSs and > so > > > you > > > > get two recodings. > > > > > > > > Thanks, > > > > Paul > > > > > > > > On 5/3/2011 4:33 PM, Elwell, John wrote: > > > > > In that case, I would assert that we need a "Recording" object > in > > > the > > > > metadata model, not a "Recording Session" object. > > > > > > > > > > John > > > > > > > > > >> -----Original Message----- > > > > >> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > > >> Sent: 03 May 2011 21:25 > > > > >> To: Elwell, John; Paul Kyzivat (pkyzivat) > > > > >> Cc: Parthasarathi R (partr); siprec@ietf.org > > > > >> Subject: RE: [siprec] RS to CS relationship as an attribute > > > > >> inRecording block > > > > >> > > > > >> Because one is mine and the other is yours and you want to > > > > >> record yours in one format and in combination with other CSs, > > > > >> and I > > > want mine in > > > > >> another format and with other CSs. > > > > >> For example you want yours recorded a single mixed audio and > > > > >> composited video stream, and I want all separate streams. > > > > >> > > > > >> Cheers, > > > > >> Charles > > > > >> > > > > >>> -----Original Message----- > > > > >>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > >>> Sent: Tuesday, May 03, 2011 12:55 PM > > > > >>> To: Charles Eckel (eckelcu); Paul Kyzivat (pkyzivat) > > > > >>> Cc: Parthasarathi R (partr); siprec@ietf.org > > > > >>> Subject: RE: [siprec] RS to CS relationship as an attribute > > > > >> inRecording block > > > > >>> > > > > >>> Why would I want two recordings of the same CS at the same > SRS? > > > > >>> > > > > >>> John > > > > >>> > > > > >>>> -----Original Message----- > > > > >>>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > > >>>> Sent: 03 May 2011 17:56 > > > > >>>> To: Elwell, John; Paul Kyzivat (pkyzivat) > > > > >>>> Cc: Parthasarathi R (partr); siprec@ietf.org > > > > >>>> Subject: RE: [siprec] RS to CS relationship as an attribute > > > > >>>> inRecording block > > > > >>>> > > > > >>>> I do not think the CS is sufficient. For example, how do > > > > >> you know if > > > > >> I > > > > >>>> want another recording of the same CS, or a single recording? > > > > >>>> > > > > >>>> Cheers, > > > > >>>> Charles > > > > >>>> > > > > >>>>> -----Original Message----- > > > > >>>>> From: Elwell, John > [mailto:john.elwell@siemens-enterprise.com] > > > > >>>>> Sent: Tuesday, May 03, 2011 9:39 AM > > > > >>>>> To: Charles Eckel (eckelcu); Paul Kyzivat (pkyzivat) > > > > >>>>> Cc: Parthasarathi R (partr); siprec@ietf.org > > > > >>>>> Subject: RE: [siprec] RS to CS relationship as an attribute > > > > >>>> inRecording block > > > > >>>>> > > > > >>>>> I saw a "recording" as being as being a recording of a > > > > >> CS. So yes, > > > > >> a > > > > >>>> recording can exist outside of an > > > > >>>>> RS, and might even span multiple RSs, but doesn't the CS > > > > >>>> object cover > > > > >>>> this? > > > > >>>>> > > > > >>>>> John > > > > >>>>> > > > > >>>>>> -----Original Message----- > > > > >>>>>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > > >>>>>> Sent: 02 May 2011 14:34 > > > > >>>>>> To: Elwell, John; Paul Kyzivat (pkyzivat) > > > > >>>>>> Cc: Parthasarathi R (partr); siprec@ietf.org > > > > >>>>>> Subject: RE: [siprec] RS to CS relationship as an attribute > > > > >>>>>> inRecording block > > > > >>>>>> > > > > >>>>>> Hi John, > > > > >>>>>> > > > > >>>>>> Having a recording exist outside of the RS provides, among > > > > >>>>>> other things, a way for a SRC to establish a new RS to > > > > >>>>>> continue a > > > > >>>> recording in the > > > > >>>>>> event something goes wrong with initial RS. It also > > > > >> facilitates > > > > >>>> having > > > > >>>>>> multiple SRCs participate in the same recording, which we > > > > >>>>>> agreed was out of scope, but is at least possible if a > > > > >>>>>> recording exists > > > > >>>> outside of > > > > >>>> an > > > > >>>>>> RS. > > > > >>>>>> I suppose the argument could be made this is not really > > > > >> necessary. > > > > >>>>>> Rather, one could, outside of the scope of SIPREC, decide > to > > > > >>>> associate > > > > >>>>>> multiple RSs in various ways, including stitching them > > > > >>>>>> together for the purpose of failover or distributed > > > > >>>>>> recordings. Is that what you have in mind? > > > > >>>>>> > > > > >>>>>> Cheers, > > > > >>>>>> Charles > > > > >>>>>> > > > > >>>>>>> -----Original Message----- > > > > >>>>>>> From: Elwell, John > > > > >> [mailto:john.elwell@siemens-enterprise.com] > > > > >>>>>>> Sent: Saturday, April 30, 2011 3:12 AM > > > > >>>>>>> To: Paul Kyzivat (pkyzivat); Charles Eckel (eckelcu) > > > > >>>>>>> Cc: Parthasarathi R (partr); siprec@ietf.org > > > > >>>>>>> Subject: RE: [siprec] RS to CS relationship as an > attribute > > > > >>>>>> inRecording block > > > > >>>>>>> > > > > >>>>>>> I am confused, because this thread has suddenly started to > > > > >>>>>> talk about > > > > >>>>>> a "recording", whereas metadata- > > > > >>>>>>> 00 has an object called "Recording Session", which > > > > >>>> 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 > > > > >>>>>>> relationship with an RS, and therefore a single SIP > > > > >> dialog, I > > > > >>>> would > > > > >>>>>> suggest they articulate why this > > > > >>>>>>> would be needed, with a view to getting it into the > metadata > > > > >>>> model. > > > > >>>>>>> > > > > >>>>>>> John > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>> -----Original Message----- > > > > >>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > > >>>>>>>> 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 > > > > >>>>>>>> inRecording block > > > > >>>>>>>> > > > > >>>>>>>> > > > > >>>>>>>> > > > > >>>>>>>> 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 > > > > >>>>>>>>> > > > > >>>>>>>> > > > > >>>>>> > > > > >>>> > > > > >> > > > > > > > > > _______________________________________________ > > > > siprec mailing list > > > > siprec@ietf.org > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > _______________________________________________ > > siprec mailing 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 May 6 10:22:38 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27349E071B for ; Fri, 6 May 2011 10:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.424 X-Spam-Level: X-Spam-Status: No, score=-10.424 tagged_above=-999 required=5 tests=[AWL=0.175, 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 mvEQD7iIFGOK for ; Fri, 6 May 2011 10:22:36 -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 77935E0709 for ; Fri, 6 May 2011 10:22:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=17697; q=dns/txt; s=iport; t=1304702556; x=1305912156; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=a1dq4hGOSvzSQVJ+TWhbpyNWiSSkSOCAIT40ZK5EDhs=; b=ch5OSqt1nSaSknb2E4DPuExwLKvYOICqUQTwtpIITfpzHB4lockrFjv5 nt5pg3XlCZz2DLQZrKmEgXzsus2/RFd7hzBq0LGDVDHz7gpmXBAC0CH30 gQsfJYvS+JjsDvF7NoV42gTEvGk25yR3Fe+VOhAQXeh0eeXWVfxNceTUK M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlsBAF4txE2rRDoI/2dsb2JhbACYII4sd6YQngmDDIJ9BIY9jUiKRw X-IronPort-AV: E=Sophos;i="4.64,327,1301875200"; d="scan'208";a="693285767" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-6.cisco.com with ESMTP; 06 May 2011 17:22:35 +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 p46HMZGt008299; Fri, 6 May 2011 17:22:35 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, 6 May 2011 10:22:35 -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, 6 May 2011 10:22:34 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RTP Recommendations (was RE: [siprec] summary of changes for draft-portman-siprec-protocol-04) Thread-Index: AcwIaR0YuGqr5XvNSMqltXB+NekCpQBR+yhgAAMNUZAAPOGiUABA+nAAABdOo4A= References: <059AF07365DC474393A19A3AF187DF7407028E4B@NAHALD.us.int.genesyslab.com> <059AF07365DC474393A19A3AF187DF74070292B2@NAHALD.us.int.genesyslab.com> From: "Charles Eckel (eckelcu)" To: "Elwell, John" , "Henry Lum" , X-OriginalArrivalTime: 06 May 2011 17:22:35.0727 (UTC) FILETIME=[30F5EDF0:01CC0C12] Subject: Re: [siprec] RTP Recommendations (was RE: summary of changes for draft-portman-siprec-protocol-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: Fri, 06 May 2011 17:22:38 -0000 Sounds good. I am not sure if I will find time to put any slides together by the end of today, but worst case we can walk through the e-mails. 15 minutes is great. Cheers, Charles > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Thursday, May 05, 2011 11:41 PM > To: Charles Eckel (eckelcu); Henry Lum; siprec@ietf.org > Subject: RTP Recommendations (was RE: [siprec] summary of changes for draft-portman-siprec-protocol- > 04) >=20 > Charles, >=20 > Thanks for producing this. I see that Andy has also proposed some text on RTP, although there is very > little overlap between the two. Perhaps the two of you can work on a merged proposal. >=20 > As has been stated before, I think we want to see some or all of this material in the architecture > document, although if we need any normative material (e.g., on recommending profiles), that would > probably need to go into the protocol document (the architecture document is only Informational). >=20 > But I think the first thing to do is get some sort of consensus on what we want to say. If producing > an additional individual draft as an interim placeholder is the pragmatic way to do it, fine. In any > case, we should certainly try to have some discussions on these points on Monday's call - if you wish > I could let you lead that discussion (say 15 minutes, stealing from each of the other slots). Let me > know. >=20 > John (as chair) >=20 > > -----Original Message----- > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > Sent: 05 May 2011 00:17 > > To: Henry Lum; Elwell, John; siprec@ietf.org > > Subject: RE: [siprec] summary of changes for > > draft-portman-siprec-protocol-04 > > > > I intended to put together a draft covering RTP recommendations and > > models. Unfortunately, I did not have enough bandwidth to get > > this done > > in time for the interim meeting. Instead, I have attached my > > thoughts to > > get some feedback. I would be happy to continue work in this area if > > people think it is useful. > > > > ------------------- > > Version 0.2 > > April 26, 2011 > > > > (1) Introduction > > > > This document provides recommendations and guidelines for RTP and RTCP > > in the context of SIPREC. In order to communicate most > > effectively, the > > Session Recording Client (SRC) and the Session Recording (SRS) should > > utilize the mechanisms provided by RTP in a well defined and > > predicable > > manner. It is the goal of this document to make the reader aware of > > these mechanisms and provide recommendations and guidelines. This > > document is completely informational. It includes no > > requirements and no > > normative language. > > > > (2) Definitions > > > > This document uses the definitions provided in > > draft-ietf-siprec-architecture for all SIPREC modules. A Session > > Recording Client (SRC), as defined within SIPREC, is expected to > > implement one or more of a variety of RTP roles within the context of > > various SIPREC use cases. These roles include, but are not limited to, > > acting as an end system, a mixer, or a translator. This document uses > > the definitions provided in "RTP: A Transport Protocol for Real-Time > > Application" [RFC 3550] for these roles. > > > > > > (3) RTCP > > > > The RTP data transport is augmented by a control protocol (RTCP) to > > allow monitoring of the data delivery. RTCP, as defined in > > [RFC3550], is > > based on the periodic transmission of control packets to all > > participants in the RTP session, using the same distribution mechanism > > as the data packets. > > Support for RTCP is recommended as it provides, among other > > things, the > > following important functionality in relation to SIPREC: > > > > 1) Feedback on the quality of the data distribution. This feedback is > > important for flow and congestion control functions, and to > > get feedback > > from the receivers to diagnose faults in the distribution. As > > such, RTCP > > is a well defined and efficient mechanism for the SRS to > > inform the SRC > > or any issues that arise in the reception of media that is to be > > recorded. > > > > 2) Carries a persistent transport-level identifier for an RTP source > > called the canonical name or CNAME. The SSRC identifier may > > change if a > > conflict is discovered or a program is restarted; in which case > > receivers can use the CNAME to keep track of each participant. > > Receivers may also use the CNAME to associate multiple data > > streams from > > a given participant in a set of related RTP sessions, for example to > > synchronize audio and video. Synchronization of media streams is also > > facilitated by the NTP and RTP timestamps included in RTCP packets by > > data senders. > > > > > > (4) RTP Profile > > > > The recommended RTP profiles for both the SRC and SRS are "Extended > > Secure RTP Profile for Real-time Transport Control Protocol > > (RTCP)-Based > > Feedback (RTP/SAVPF)", [RFC5124] when using encrypted RTP streams, and > > "Extended RTP Profile for Real-time Transport Control Protocol > > (RTCP)-Based Feedback (RTP/AVPF)", [RFC4585] when using non encrypted > > media streams. However, as this is not a requirement, some > > implementations may use "The Secure Real-time Transport Protocol > > (SRTP)", [RFC 3711] and "RTP Profile for Audio and Video Conferences > > with Minimal Control", AVP [RFC 3551]. Therefore, it is > > recommended that > > the SRC and SRS not rely entirely on SAVPF or AVPF for core > > functionality that may be at least partially achievable using SAVP and > > AVP. > > > > AVPF and SAVPF provide an improved RTCP timer model that allows more > > flexible transmission of RTCP packets as response to events, > > rather than > > strictly according to bandwidth. > > SAVP and SAVPF provide media encryption, integrity protection, replay > > protection, and a limited form of source authentication. They do not > > contain or require a specific keying mechanism. > > > > > > (5) SRSC > > > > The synchronization source (SSRC), as defined in [RFC3550], is carried > > in the RTP header and in various fields of RTCP packets. It > > is a random > > 32-bit number that is required to be globally unique within an RTP > > session. It is crucial that the number be chosen with care in order > > that participants on the same network or starting at the same time are > > not likely to choose the same number. Guidelines regarding SSRC value > > selection and conflict resolution are provided in [RFC3550]. > > > > The SSRC may also be used to separate different sources of > > media within > > a single RTP session. For this reason as well as for conflict > > resolution, it is important that the SRC and SRC handle > > changes in SSRC > > values and properly identify the reason of the change. The > > CNAME values > > carried in RTCP facilitate this identification. > > > > > > (6) CSRC > > > > The contributing source (CSRC), as defined in [RFC3550], > > identifies the > > source of a stream of RTP packets that has contributed to the combined > > stream produced by an RTP mixer. The mixer inserts a list of the SSRC > > identifiers of the sources that contributed to the generation of a > > particular packet into the RTP header of that packet. This list is > > called the CSRC list. It is recommended that a SRC, when > > acting a mixer, > > sets the CSRC list accordingly, and that the SRS interprets the CSRC > > list appropriately when received. > > > > > > (7) SDES > > > > The Source Description (SDES), as defined in [RFC3550], contains an > > SSRC/CSRC identifier followed by a list of zero or more items, which > > carry information about the SSRC/CSRC. End systems send one > > SDES packet > > containing their own source identifier (the same as the SSRC in the > > fixed RTP header). A mixer sends one SDES packet containing > > a chunk for > > each contributing source from which it is receiving SDES > > information, or > > multiple complete SDES packets. > > > > (8) CNAME > > > > The Canonical End-Point Identifier (CNAME), as defined in [RFC3550], > > provide the binding from the SSRC identifier to an identifier for the > > source (sender or receiver) that remains constant. It is > > important the > > an SRC and SRS generate CNAMEs appropriately and use them for this > > purpose. Guidelines for generating CNAME values are provided in > > "Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names > > (CNAMEs)" [RFC6222]. > > > > > > (9) Keepalive > > > > It is anticipated that media streams in SIPREC may exist in inactive > > states for extended periods of times for an of a number of valid > > reasons. In order to the bindings and any pinholes in > > NATs/firewalls to > > remain active during such intervals, it is recommended to follow the > > keep-alive procedures in "Application Mechanism for keeping alive the > > Network Address Translator > > (NAT) mappings associated to RTP/RTCP flows", > > [draft-ietf-avt-app-rtp-keepalive] for all RTP media streams. > > > > > > (10) RTCP Feedback Messages > > > > "Codec Control Messages in the RTP Audio-Visual Profile with Feedback > > (AVPF)" [RFC 5104] specifies extensions to the messages > > defined in AVPF > > [RFC4585]. Support for and proper usage of these messages is important > > to SRC and SRS implementations. > > > > (10.1) Full Intra Request > > > > A Full Intra Request (FIR) Command, when received by the > > designate media > > sender, requires that the media sender sends a Decoder > > Refresh Point at > > the earliest opportunity. Using a decoder refresh point implies > > refraining from using any picture sent prior to that point as a > > reference for the encoding process of any subsequent picture > > sent in the > > stream. > > > > Decoder refresh points, especially Intra or IDR pictures for > > H.264 video > > codecs, are in general several times larger in size than predicted > > pictures. Thus, in scenarios in which the available bit rate is small, > > the use of a decoder refresh point implies a delay that is > > significantly > > longer than the typical picture duration. > > > > (10.1.1) SIP INFO for FIR > > > > "XML Schema for Media Control" [RFC5168] defines an Extensible Markup > > Language (XML) Schema for video fast update. Implementations are > > discouraged from using the method described except for backward > > compatibility purposes. Implementations should use FIR messages, as > > described in (10.1) instead. > > > > > > (10.2) Picture Loss Indicator > > Using the FIR command to recover from errors is explicitly disallowed, > > and instead the PLI message defined in AVPF [RFC4585] should be used. > > The PLI message reports lost pictures and has been included > > in AVPF for > > precisely that purpose. > > > > > > (10.3) Temporary Maximum Media Stream Bit Rate Request > > > > A receiver, translator, or mixer uses the Temporary Maximum > > Media Stream > > Bit Rate Request (TMMBR) to request a sender to limit the maximum bit > > rate for a media stream to the provided value. Appropriate > > use of TMMBR > > facilitates rapid adaptation to changes in available bandwidth. > > > > (10.3.1) Renegotiation of SDP bandwidth attribute > > > > If it is likely that the new value indicated by TMMBR will be > > valid for > > the remainder of the session, the TMMBR sender is expected to > > perform a > > renegotiation of the session upper limit using the session signaling > > protocol. Therefore for SIPREC, implementations are recommended to use > > TMMBR for temporary changes, and renegotiation of bandwidth via SDP > > offer/answer of more permanent changes. > > > > > > (11) Symmetric RTP/RTCP > > > > Within the SDP offer/answer, RTP entities choose the RTP and RTCP > > transport addresses (i.e., IP addresses and port numbers) on which to > > receive packets. When sending RTP packets; however, they may use a > > different IP address or port number for RTP, RTCP, or both. Symmetric > > RTP/RTCP requires that the IP address and port number for sending and > > receiving RTP/RTCP packets are identical. Using Symmetric RTP and RTCP > > [RFC4961] is recommended. > > > > --------------------- > > > > Cheers, > > Charles > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Henry Lum > > > Sent: Tuesday, May 03, 2011 11:18 AM > > > To: Elwell, John; siprec@ietf.org > > > Subject: Re: [siprec] summary of changes for > > draft-portman-siprec-protocol-04 > > > > > > Hi John, > > > > > > Okay, let's discuss this topic further in the interim meeting to > > > determine whether there is any need to specify any protocol related > > > changes. > > > > > > Regards, > > > Henry > > > > > > > -----Original Message----- > > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > Sent: Tuesday, May 03, 2011 12:44 PM > > > > To: Henry Lum; siprec@ietf.org > > > > Subject: RE: summary of changes for > > draft-portman-siprec-protocol-04 > > > > > > > > Henry, > > > > > > > > Concerning the RTP model, I agree that the consensus to date seems > > to > > > > be to cover different RTP models, but I feel we should > > get something > > > > into the architecture draft to start with, and then later see > > whether > > > > there is any impact on the protocol draft. > > > > > > > > John > > > > > > > > > > > > > -----Original Message----- > > > > > From: siprec-bounces@ietf.org > > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Henry Lum > > > > > Sent: 02 May 2011 04:09 > > > > > To: siprec@ietf.org > > > > > Subject: [siprec] summary of changes for > > > > > draft-portman-siprec-protocol-04 > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > I want to summarize the list of changes we are planning to > > > > > include in the next revision of the document: > > > > > > > > > > > > > > > > > > > > - Remove use of INFO > > > > > > > > > > - Both INVITE or UPDATE can be used for metadata > > > > > transport through content-disposition > > > > > > > > > > - Recording indication is placed at SDP media level > > > > > > > > > > - Recording awareness is indicated at SIP level with > > > > > options; feature tag was also considered > > > > > > > > > > - Recording preference is placed at SDP media level > > > > > > > > > > - RTP model discussion and time synchronization; so > > > > > far we seem to agree to handle different RTP models rather > > > > > than requiring a single model. There are 3 models we have > > > > > identified so far: > > > > > > > > > > o RTP mixer - SRC mixes media streams and can directly > > > > > synchronize timestamps with metadata and also generate RTCP > > > > > > > > > > o RTP translator - Media streams are simply forwarded to > > > > > the SRS by the SRC. SRC is only capable to indicating > > > > > start/stop times to the SRS in metadata. > > > > > > > > > > o RTP endpoint (is that the right term?) - SRC is neither a > > > > > mixer nor translator, but is capable of rewriting RTP and > > > > > RTCP in order to synchronize on the timestamps with metadata. > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > Henry > > > > > > > > > > > > > > > > > > > > > > > > > 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. > > > > > > _______________________________________________ > > > siprec mailing list > > > siprec@ietf.org > > > https://www.ietf.org/mailman/listinfo/siprec > > From partr@cisco.com Fri May 6 11:29:04 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B880CE07A6 for ; Fri, 6 May 2011 11:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.172 X-Spam-Level: X-Spam-Status: No, score=-10.172 tagged_above=-999 required=5 tests=[AWL=0.427, 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 p9KEjN2yev8T for ; Fri, 6 May 2011 11:29:02 -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 9C9CBE076F for ; Fri, 6 May 2011 11:29:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=26358; q=dns/txt; s=iport; t=1304706541; x=1305916141; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=1t6bzWDePQouUAKT//UZ3gGkjVCpOSNOVy4DteLkxyk=; b=elx4eSpNzCjRzYaWJnYNWtk8AD5dno0pNxdA5myeCP/k5wSRBlaKvB/L NL3IklHN9DW6zLcy2o9bgh7s+ezlu8t/UGjQ0jj8nzMudT7Fw2ZNgdEBk aOoFuZ82HVFu7us0HB+DuP/hHhNjfdXdZGvoZTj4j9b0urE3JnUbfrL5u E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiwBAIo9xE2Q/khMgWdsb2JhbACXcY4sFAEBCwsmJYhxnWKeAYMMAYJ8BIY7jUqKLzQ X-IronPort-AV: E=Sophos;i="4.64,327,1301875200"; d="scan'208";a="29033099" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 06 May 2011 18:29:00 +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 p46ISxfx006497; Fri, 6 May 2011 18:28:59 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, 6 May 2011 23:58: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: Fri, 6 May 2011 23:58:59 +0530 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: AcwJ+biFoOO41i/hQIKAJCEft7se1gAVN5rwAARo/LAARdMwIAAFIb9gACEtEzAAAkvJwA== References: <4DB58BC7.5090603@cisco.com><4DB820DA.1080200@cisco.com><4DBB59E2.9040200@cisco.com><4DC0AA33.80205@cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD0635764C@XMB-BGL-417.cisco.com> From: "Parthasarathi R (partr)" To: "Charles Eckel (eckelcu)" , "Elwell, John" , "Ram Mohan R (rmohanr)" , "Paul Kyzivat (pkyzivat)" X-OriginalArrivalTime: 06 May 2011 18:28:58.0293 (UTC) FILETIME=[76C14650:01CC0C1B] 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, 06 May 2011 18:29:04 -0000 Hi Charles, I agree with you for having "optional" recording group metadata block which relates to "recording session". Let us have closure in meeting for the addition of this new "optional" block. As recording group is decided by SRC, I prefer the unique id generation by SRC which is inline with the current metadata format. Please note that multiple SRC creating recording group is outside the scope of SIRPEC. Thanks Partha -----Original Message----- From: Charles Eckel (eckelcu)=20 Sent: Friday, May 06, 2011 10:50 PM To: Parthasarathi R (partr); 'Elwell, John'; Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) Cc: 'siprec@ietf.org' Subject: RE: [siprec] RS to CS relationship as an attribute inRecording block Hi Partha, I am responding to the first part of the e-mail as John and yourself have already continued the second part in another thread. A recording group would work for me as well. My goal is to have some way for an SRC to tell the SRS this RS for meant to be part of something that already exists, perhaps on this same SRS. We can call it a recording group, and recording object, and recording ID, or whatever we want. The idea is that when a recording starts, a recording ID is generated, either by the SRC, or by the SRS if none is provided by the SRC. This recording ID could be used to tie other RSs to the same recording. I agree this could be achieved by a mechanism outside of SIPREC, but I think it might be helpful to build it into SIPREC was it seems like a pretty useful and basic feature to me.=20 Cheers, Charles > -----Original Message----- > From: Parthasarathi R (partr) > Sent: Thursday, May 05, 2011 6:50 PM > To: Charles Eckel (eckelcu); Elwell, John; Ram Mohan R (rmohanr); Paul > Kyzivat (pkyzivat) > Cc: siprec@ietf.org > Subject: RE: [siprec] RS to CS relationship as an attribute=20 > inRecording block >=20 > Charles, >=20 > Different RS for same recording looks like "recording group" requirement. There was "recording group" > metadata block in the initial metadata draft and it was removed as=20 > there was no known usecase. I'm reading your usecase which may call for optional "recording group" block in metadata model. >=20 > I'll provide some hypothetical scenario: SRC has RS1 with mixed=20 > stream, RS2 with unmixed stream for CS1. SRS has to aware that RS1 and > RS2 belongs to same recording. This shall be achieved by "recording=20 > group" metadata block which will extend for your scenario which is outside the scope of SIPREC. Let us discuss in the meeting whether "recording group" is required. >=20 > John, >=20 > Recording Session object has two attributes namely >=20 > 1) Recording Requestor (SRC/SRS) - This may be required in SRS in=20 > terms of metadata model but which shall be derived from the information whether RS INVITE is received in SRS or INVITE sent out by SRS. >=20 > 2) Recording type (Persistent/selective) - This attribute will become=20 > irrelevant in case SRS is designed with the principle of "Many RS to Many CS" as mentioned below in this mail thread. >=20 > Based on the current attributes, metadata format will have no standard > XML element. Please let me know whether your argue is same or not. >=20 > Thanks > Partha >=20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > Behalf Of Charles Eckel (eckelcu) > Sent: Friday, May 06, 2011 4:28 AM > To: Elwell, John; Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > Cc: siprec@ietf.org > Subject: Re: [siprec] RS to CS relationship as an attribute=20 > inRecording block >=20 > The other use case is different RS for the same recording. That is=20 > where I think recording object comes in handy. >=20 > Cheers, > Charles >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Elwell, John > > Sent: Wednesday, May 04, 2011 6:40 AM > > To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > Cc: siprec@ietf.org > > Subject: Re: [siprec] RS to CS relationship as an attribute > inRecording block > > > > Ram, > > > > If we don't think a Recording object is needed for the case that > Charles describes, fine. But I would > > also argue that we don't need a Recording Session object. > > > > John (as individual) > > > > > -----Original Message----- > > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > > Sent: 04 May 2011 12:51 > > > To: Paul Kyzivat (pkyzivat); Elwell, John > > > Cc: siprec@ietf.org > > > Subject: RE: [siprec] RS to CS relationship as an attribute=20 > > > inRecording block > > > > > > I agree with Paul here. > > > The below use-case that Charles mentions is a good example of two > SRCs > > > recording the same CS simultaneously via different RS. > > > In these cases these are two Recording Sessions each recording the > > > same CS and the current model is sufficient for the same. > > > > > > John, > > > > > > so I don't see a need to change "Recording Session" to "Recording" > > > object in the model. Or are you talking here about grouping of=20 > > > recordings ? > > > > > > As Paul mentioned it will only be recognized as the same CS only=20 > > > if the two SRCs coordinate among themselves to use the same UUID=20 > > > for it. > > > Otherwise we will get two recordings. > > > > > > Ram > > > > > > > -----Original Message----- > > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org]=20 > > > > On Behalf Of Paul Kyzivat (pkyzivat) > > > > Sent: Wednesday, May 04, 2011 6:52 AM > > > > To: Elwell, John > > > > Cc: siprec@ietf.org > > > > Subject: Re: [siprec] RS to CS relationship as an attribute > > > inRecording > > > > block > > > > > > > > Of course this could be accomplished simply by dumb luck: > > > > > > > > If you and I have separate SRCs and are asking for separate > > > recordings > > > > of the "same" CS, it will only be recognized as the same CS > > > if the two > > > > SRCs coordinate among themselves to use the same UUID for > > > it. If they > > > > don't (likely in this case) the SRS with thing it is two CSs and > so > > > you > > > > get two recodings. > > > > > > > > Thanks, > > > > Paul > > > > > > > > On 5/3/2011 4:33 PM, Elwell, John wrote: > > > > > In that case, I would assert that we need a "Recording" object > in > > > the > > > > metadata model, not a "Recording Session" object. > > > > > > > > > > John > > > > > > > > > >> -----Original Message----- > > > > >> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > > >> Sent: 03 May 2011 21:25 > > > > >> To: Elwell, John; Paul Kyzivat (pkyzivat) > > > > >> Cc: Parthasarathi R (partr); siprec@ietf.org > > > > >> Subject: RE: [siprec] RS to CS relationship as an attribute=20 > > > > >> inRecording block > > > > >> > > > > >> Because one is mine and the other is yours and you want to=20 > > > > >> record yours in one format and in combination with other CSs, > > > > >> and I > > > want mine in > > > > >> another format and with other CSs. > > > > >> For example you want yours recorded a single mixed audio and=20 > > > > >> composited video stream, and I want all separate streams. > > > > >> > > > > >> Cheers, > > > > >> Charles > > > > >> > > > > >>> -----Original Message----- > > > > >>> From: Elwell, John=20 > > > > >>> [mailto:john.elwell@siemens-enterprise.com] > > > > >>> Sent: Tuesday, May 03, 2011 12:55 PM > > > > >>> To: Charles Eckel (eckelcu); Paul Kyzivat (pkyzivat) > > > > >>> Cc: Parthasarathi R (partr); siprec@ietf.org > > > > >>> Subject: RE: [siprec] RS to CS relationship as an attribute > > > > >> inRecording block > > > > >>> > > > > >>> Why would I want two recordings of the same CS at the same > SRS? > > > > >>> > > > > >>> John > > > > >>> > > > > >>>> -----Original Message----- > > > > >>>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > > >>>> Sent: 03 May 2011 17:56 > > > > >>>> To: Elwell, John; Paul Kyzivat (pkyzivat) > > > > >>>> Cc: Parthasarathi R (partr); siprec@ietf.org > > > > >>>> Subject: RE: [siprec] RS to CS relationship as an attribute > > > > >>>> inRecording block > > > > >>>> > > > > >>>> I do not think the CS is sufficient. For example, how do > > > > >> you know if > > > > >> I > > > > >>>> want another recording of the same CS, or a single recording? > > > > >>>> > > > > >>>> Cheers, > > > > >>>> Charles > > > > >>>> > > > > >>>>> -----Original Message----- > > > > >>>>> From: Elwell, John > [mailto:john.elwell@siemens-enterprise.com] > > > > >>>>> Sent: Tuesday, May 03, 2011 9:39 AM > > > > >>>>> To: Charles Eckel (eckelcu); Paul Kyzivat (pkyzivat) > > > > >>>>> Cc: Parthasarathi R (partr); siprec@ietf.org > > > > >>>>> Subject: RE: [siprec] RS to CS relationship as an=20 > > > > >>>>> attribute > > > > >>>> inRecording block > > > > >>>>> > > > > >>>>> I saw a "recording" as being as being a recording of a > > > > >> CS. So yes, > > > > >> a > > > > >>>> recording can exist outside of an > > > > >>>>> RS, and might even span multiple RSs, but doesn't the CS > > > > >>>> object cover > > > > >>>> this? > > > > >>>>> > > > > >>>>> John > > > > >>>>> > > > > >>>>>> -----Original Message----- > > > > >>>>>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > > >>>>>> Sent: 02 May 2011 14:34 > > > > >>>>>> To: Elwell, John; Paul Kyzivat (pkyzivat) > > > > >>>>>> Cc: Parthasarathi R (partr); siprec@ietf.org > > > > >>>>>> Subject: RE: [siprec] RS to CS relationship as an=20 > > > > >>>>>> attribute inRecording block > > > > >>>>>> > > > > >>>>>> Hi John, > > > > >>>>>> > > > > >>>>>> Having a recording exist outside of the RS provides,=20 > > > > >>>>>> among other things, a way for a SRC to establish a new RS > > > > >>>>>> to continue a > > > > >>>> recording in the > > > > >>>>>> event something goes wrong with initial RS. It also > > > > >> facilitates > > > > >>>> having > > > > >>>>>> multiple SRCs participate in the same recording, which we > > > > >>>>>> agreed was out of scope, but is at least possible if a=20 > > > > >>>>>> recording exists > > > > >>>> outside of > > > > >>>> an > > > > >>>>>> RS. > > > > >>>>>> I suppose the argument could be made this is not really > > > > >> necessary. > > > > >>>>>> Rather, one could, outside of the scope of SIPREC, decide > to > > > > >>>> associate > > > > >>>>>> multiple RSs in various ways, including stitching them=20 > > > > >>>>>> together for the purpose of failover or distributed=20 > > > > >>>>>> recordings. Is that what you have in mind? > > > > >>>>>> > > > > >>>>>> Cheers, > > > > >>>>>> Charles > > > > >>>>>> > > > > >>>>>>> -----Original Message----- > > > > >>>>>>> From: Elwell, John > > > > >> [mailto:john.elwell@siemens-enterprise.com] > > > > >>>>>>> Sent: Saturday, April 30, 2011 3:12 AM > > > > >>>>>>> To: Paul Kyzivat (pkyzivat); Charles Eckel (eckelcu) > > > > >>>>>>> Cc: Parthasarathi R (partr); siprec@ietf.org > > > > >>>>>>> Subject: RE: [siprec] RS to CS relationship as an > attribute > > > > >>>>>> inRecording block > > > > >>>>>>> > > > > >>>>>>> I am confused, because this thread has suddenly started=20 > > > > >>>>>>> to > > > > >>>>>> talk about > > > > >>>>>> a "recording", whereas metadata- > > > > >>>>>>> 00 has an object called "Recording Session", which > > > > >>>> 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 > > > > >>>>>>> relationship with an RS, and therefore a single SIP > > > > >> dialog, I > > > > >>>> would > > > > >>>>>> suggest they articulate why this > > > > >>>>>>> would be needed, with a view to getting it into the > metadata > > > > >>>> model. > > > > >>>>>>> > > > > >>>>>>> John > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>> -----Original Message----- > > > > >>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > > >>>>>>>> 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 > > > > >>>>>>>> inRecording block > > > > >>>>>>>> > > > > >>>>>>>> > > > > >>>>>>>> > > > > >>>>>>>> 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=20 > > > > >>>>>>>>> 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=20 > > > > >>>>>>>>> for > > > > >>>>>>>> the purpose of > > > > >>>>>>>>> continuing a recording. > > > > >>>>>>>> > > > > >>>>>>>> Yes, I agree. > > > > >>>>>>>> > > > > >>>>>>>> A "recording" is really just all the data and metadata=20 > > > > >>>>>>>> accumulated about a CS or CSG. That data has been=20 > > > > >>>>>>>> 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=20 > > > > >>>>>>>> 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=20 > > > > >>>>>>>>>> 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=20 > > > > >>>>>>>>>> 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=20 > > > > >>>>>>>>>> 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=20 > > > > >>>>>>>>>> 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=20 > > > > >>>>>>>>>> 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=20 > > > > >>>>>>>>>> it > > > > >> got > > > > >>>> the > > > > >>>>>>>>> various > > > > >>>>>>>>>> pieces of data and metadata it receives and records.=20 > > > > >>>>>>>>>> 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=20 > > > > >>>>>>>>>>> loop > > > > >>>> before, > > > > >>>>>> so > > > > >>>>>>>>>> apologies if we came to a resolution. > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> John (as individual) > > > > >>>>>>>>>>> > > > > >>>>>>>>>>>> -----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 in > > > > >>>>>>>>>>>> Recording block > > > > >>>>>>>>>>>> > > > > >>>>>>>>>>>> Given all the combinations you cite, I'm inclined=20 > > > > >>>>>>>>>>>> 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=20 > > > > >>>>>>>>>>>>> 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=20 > > > > >>>>>>>>>>>>> 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=20 > > > > >>>>>>>>>>>>> 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=20 > > > > >>>>>>>>>>>>> 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=20 > > > > >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec > > > > >>>>>>>>>>>> _______________________________________________ > > > > >>>>>>>>>>>> siprec mailing list siprec@ietf.org=20 > > > > >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec > > > > >>>>>>>>>>>> > > > > >>>>>>>>>> _______________________________________________ > > > > >>>>>>>>>> siprec mailing list > > > > >>>>>>>>>> siprec@ietf.org > > > > >>>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec > > > > >>>>>>>>>> _______________________________________________ > > > > >>>>>>>>>> siprec mailing list > > > > >>>>>>>>>> siprec@ietf.org > > > > >>>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec > > > > >>>>>>>>> > > > > >>>>>>>> > > > > >>>>>> > > > > >>>> > > > > >> > > > > > > > > > _______________________________________________ > > > > siprec mailing list > > > > siprec@ietf.org > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > _______________________________________________ > > siprec mailing 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 May 6 14:36: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 031D8E0839 for ; Fri, 6 May 2011 14:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.551 X-Spam-Level: X-Spam-Status: No, score=-109.551 tagged_above=-999 required=5 tests=[AWL=-0.752, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-BFeKqlCNY2 for ; Fri, 6 May 2011 14:36:49 -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 DE39AE0789 for ; Fri, 6 May 2011 14:36:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=30797; q=dns/txt; s=iport; t=1304717809; x=1305927409; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=S3qrjX4P450H70bnp3KMX4RgyMOVJVpABMVFi8gMDX0=; b=kzMRl1ukS9c5GHtitIaSTG86mi/b637qTewekZnlJn8XxAtrEfzwDA5A zKztSlhk7EeE4Tzu7JACvhzINDPLHttpU7NftSEySZgvzVWWnP91yuVaf 0nlu2BrifwPThs/1/X78gXvMMBCm9BqCGFrQgAs3BFMSw9qEHSTXvK7eD E=; X-IronPort-AV: E=Sophos;i="4.64,328,1301875200"; d="scan'208";a="443315124" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by sj-iport-1.cisco.com with ESMTP; 06 May 2011 21:36:48 +0000 Received: from [161.44.174.124] (dhcp-161-44-174-124.cisco.com [161.44.174.124]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p46LaldY011448; Fri, 6 May 2011 21:36:47 GMT Message-ID: <4DC469EF.6040705@cisco.com> Date: Fri, 06 May 2011 17:36:47 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Charles Eckel (eckelcu)" References: <4DC31AC4.9030309@cisco.com> <4DC3E53E.9050202@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: Fri, 06 May 2011 21:36:52 -0000 Charles, On 5/6/2011 1:04 PM, Charles Eckel (eckelcu) wrote: > The reason I brought this up was in response to Partha's assertion that > participant IDs need to be globally unique rather than unique within a > given CS, RS, or recording. The point I was trying to make was that an > SRS might actually want a way to correlate participants, either by > participant ID or some other metadata or some mechanism outside the > scope of SIPREC. While this is still possible with globally unique > participant IDs, it is made more difficult. ??? How? Having globally unique ones makes it *possible* for more than one src to reference the same one. If the SRS wants to correlate ones that are different, how does this make it more difficult? > So in this case, mandating > that participant IDs be globally unique make things more > complex/difficult. Why are globally unique participant IDs across all > CSs and RSs required? That is what I am trying to understand. > They is some cost associated with this, and I want to make sure the cost > is warranted. As noted above, being globally unique means that two different SRCs that find a way of discovering each others ids MAY then reference/reuse them. If the ids are instead *locally* unique to an SRC, then the SRS still has to make them globally unique if it stores in common the data from multiple SRCs. (It can do that by prefixing the src-local id with a uid for the SRC.) But that has its own problems. In that environment if src1 knows and wants to reference an id generated by src2, it can't do so unless there is a way for src1 to include an id like src2:id. And if we allow that we are back to globally unique ids - just of a different format. Or else you just can't cross reference at all. Another issue with this is that if the ids are not globally unique, then *exactly* what is the scope in which they *are* unique. For the SRS to understand them properly that must be nailed down. Once you get beyond a single RS session, there starts to be uncertainty whether two RSs involved the same SRC or different ones. Of course we could solve that by requiring the SRC to provide a globally unique id for itself, and other ids that are unique within the scope of that one. But that is again just a different way of encoding globally unique ids. Thanks, Paul > Cheers, > Charles > >> -----Original Message----- >> From: Paul Kyzivat (pkyzivat) >> Sent: Friday, May 06, 2011 5:11 AM >> To: Elwell, John >> Cc: Charles Eckel (eckelcu); Parthasarathi R (partr); siprec@ietf.org; > Peter Saint-Andre (psaintan); >> Joe Hildebrand (jhildebr); Hadriel Kaplan >> Subject: Re: [siprec] Partial updates and identifiers >> >> John, >> >> I think we are in agreement. My point was that some SRCs may be > smarter >> about this than others. If they are able to figure out when to reuse > the >> same participant id, then that is great, but not required. >> >> (Of course they must not reuse the same participant id *by accident*.) >> >> Thanks, >> Paul >> >> On 5/6/2011 3:14 AM, Elwell, John wrote: >>> When is a participant the same participant and when is it different? > I call into a conference from >> my desk phone. I later drop out and then call in again to the same > conference from my cell phone. The >> conference is being recorded. In this case it is unlikely that the SRC > will have any information to >> correlate the new caller with the caller who dropped out, unless they > happen to share the same SIP >> AOR. >>> >>> I think it is fine for participants to be assigned new IDs each time > they join a call or participate >> in different calls / different recordings. If other attributes of the > Participant object can be used >> to correlate two different Participant IDs (e.g., the same SIP AoR), > this can be made use of. >> Otherwise they are treated as different participants, even though it > might be the same person. >>> >>> John (as individual) >>> >>> >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>> Sent: 05 May 2011 22:47 >>>> To: Charles Eckel (eckelcu) >>>> Cc: Parthasarathi R (partr); Elwell, John; siprec@ietf.org; >>>> Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr); >>>> Hadriel Kaplan >>>> Subject: Re: [siprec] Partial updates and identifiers >>>> >>>> >>>> >>>> On 5/5/2011 1:10 PM, Charles Eckel (eckelcu) wrote: >>>>> I follow the logic, but let me run through a simple use case. >>>>> >>>>> 0) I am on a call that is part of a recording. Initially, this is >>>>> through CS1 which results in RS1, which is part of recording X. My >>>>> unique participant ID is p0. >>>>> >>>>> I drop off and call back in. I need to be brought back into the > same >>>>> recording X. Possible scenarios are: >>>>> >>>>> 1) I call back into CS1, and am added into recording X >>>> through RS1. My >>>>> unique participant ID is p1? >>>> >>>> Maybe. It depends on whether the SRC recognizes you as the same >>>> participant and remembers that it had assigned p1 to you. >>>> If not, then you will presumably appear as a new participant. >>>> >>>>> 2) I call into CS2, and am added to recording X through >>>> RS1. My unique >>>>> participant ID is p2? >>>> >>>> Pretty much the same answer as above. >>>> >>>> Its also up to the SRC to decide if this is part of CS1 or CS2. >>>> >>>>> 3) I call into CS2, and am added to recording X through >>>> RS2. My unique >>>>> participant ID is p3? >>>> >>>> Pretty much the same again. If it is the same SRC, and has >>>> some history >>>> to figure out what is going on, it can continue to use p1. >>>> >>>> If it is a different SRC, then its more of a challenge. There >>>> would have >>>> to be some sharing of info between the two for the new SRC to > recover >>>> the old p1. More likely you will get a new p3. >>>> >>>>> If the SRS is able to make use of some other metadata to >>>> realize that >>>>> p0=p1=p2=p3, great, if not, they look like different participants. >>>> >>>> Yes, if the p(i) are different the SRS could still attempt >>>> correlation, >>>> but its outside our current scope. >>>> >>>> Thanks, >>>> Paul >>>> >>>>> Cheers, >>>>> Charles >>>>> >>>>>> -----Original Message----- >>>>>> From: Parthasarathi R (partr) >>>>>> Sent: Tuesday, May 03, 2011 9:46 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 >>>>>> >>>>>> Hi Charles, >>>>>> >>>>>> In case participants id has to be unique for single RS >>>> with multiple >>>>> CS as you mentioned below mail >>>>>> and also, participant id has to be unique within single CS >>>> which span >>>>> across multiple RS (start& stop >>>>>> of recording within CS scenario), then participant unique >>>> id needs to >>>>> be global (URN UUID) rather than >>>>>> local id like xml:id. Please let me know in case you have any > other >>>>> opinion on the same. >>>>>> >>>>>> Thanks >>>>>> Partha >>>>>> >>>>>> -----Original Message----- >>>>>> From: Charles Eckel (eckelcu) >>>>>> Sent: Wednesday, April 20, 2011 2:54 AM >>>>>> 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 >>>>>> >>>>>> 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 >>>>>>> >>>>>>> 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? >>>>>>> >>>>>>> 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 eckelcu@cisco.com Fri May 6 15:24:28 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3150BE0745 for ; Fri, 6 May 2011 15:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.379 X-Spam-Level: X-Spam-Status: No, score=-9.379 tagged_above=-999 required=5 tests=[AWL=-0.884, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, 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 AqD4tsE1Vzrj for ; Fri, 6 May 2011 15:24:26 -0700 (PDT) Received: from sj-iport-1.cisco.com (unknown [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 5E730E071D for ; Fri, 6 May 2011 15:24:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=20710; q=dns/txt; s=iport; t=1304720666; x=1305930266; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=tLoPcwRPK//3/9TCXGJPUSdPfb5GyExh/N60OldE+Oo=; b=M8EpMiy8xk7TnM6xhoCcehLkI2cWxQr0nAHjjjDjwLqbLmWFsbXdwa2c uxF8OcE6hXTpYaOOZc8cNej6WQEr6v9M2Wc1s2H4oS9fVjjF1u+nTcPnw Rr4kwFyS59HZlRwXsMpe+mBik27m/Cw7qCs1kS6jgh7BIMj83R9gqjLem o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlsBADh0xE2rRDoG/2dsb2JhbACXc44rd4hxnyGdc4MMgn0Ehj2NSIpH X-IronPort-AV: E=Sophos;i="4.64,328,1301875200"; d="scan'208";a="443335457" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-1.cisco.com with ESMTP; 06 May 2011 22:24:25 +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 p46MOP6c002103; Fri, 6 May 2011 22:24:25 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, 6 May 2011 15:24:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 6 May 2011 15:24:24 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RTP Recommendations (was RE: [siprec] summary of changes for draft-portman-siprec-protocol-04) Thread-Index: AcwIaR0YuGqr5XvNSMqltXB+NekCpQBR+yhgAAMNUZAAPOGiUABA+nAAAAD6LRAAHrP38A== References: <059AF07365DC474393A19A3AF187DF7407028E4B@NAHALD.us.int.genesyslab.com> <059AF07365DC474393A19A3AF187DF74070292B2@NAHALD.us.int.genesyslab.com> From: "Charles Eckel (eckelcu)" To: "Elwell, John" , "Henry Lum" , X-OriginalArrivalTime: 06 May 2011 22:24:25.0273 (UTC) FILETIME=[5B175A90:01CC0C3C] Subject: Re: [siprec] RTP Recommendations (was RE: summary of changes for draft-portman-siprec-protocol-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: Fri, 06 May 2011 22:24:28 -0000 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Thursday, May 05, 2011 11:43 PM > To: Charles Eckel (eckelcu); Henry Lum; siprec@ietf.org > Subject: RE: RTP Recommendations (was RE: [siprec] summary of changes for draft-portman-siprec- > protocol-04) >=20 > Charles >=20 > I won't comment in detail on your text, but a couple of small points: >=20 > 1. What is meant by "Support for RTCP is recommended"? RTCP is already mandated in RFC 3550, so we > can't soften that. I know in practice some implementations don't support it, but I don't think we can > go against RFC 3550. I always felt RTCP was required as well, but when challenged on that, I was not able to see where in RFC 3550 it is stated as mandatory. Looking more closely at RFC 3550, I think the following text in section 6 does mandate RTCP, "The first two functions require that all participants send RTCP packets, therefore the rate must be controlled in order for RTP to scale up to a large number of participants." Armed with this, I agree completely with your comment. For now, I will update that, and we can decide later if it simply want to remove that section as unnecessary. =20 > 2. AVPF and SAVPF are recommended, with the ability to fall back to AVP or SAVP. It would be good to > have some rationale as to why SIPREC merits recommending AVPF and SAVPF. Currently the text states > their advantages, but doesn't explain why these advantages are particularly important for SIPREC. Will add this. > 3. "Using the FIR command to recover from errors is explicitly disallowed, > and instead the PLI message defined in AVPF [RFC4585] should be used. > The PLI message reports lost pictures and has been included in AVPF for > precisely that purpose." > This presumably applies only if AVPF/SAVPF is used. Correct. Will clarify this. > 4. The text on symmetric RTP/RTCP seems to mix up the symmetric RTP/RTCP principle (use of same > port/address for transmitting and receiving) and the RTP/RTCP multiplexing concept (RTP and RTCP on > the same port). Perhaps the two should be separated. > Will do. Thanks, Charles > John (as individual) >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Elwell, John > > Sent: 06 May 2011 07:41 > > To: 'Charles Eckel (eckelcu)'; Henry Lum; siprec@ietf.org > > Subject: RTP Recommendations (was RE: [siprec] summary of > > changes for draft-portman-siprec-protocol-04) > > > > Charles, > > > > Thanks for producing this. I see that Andy has also proposed > > some text on RTP, although there is very little overlap > > between the two. Perhaps the two of you can work on a merged proposal. > > > > As has been stated before, I think we want to see some or all > > of this material in the architecture document, although if we > > need any normative material (e.g., on recommending profiles), > > that would probably need to go into the protocol document > > (the architecture document is only Informational). > > > > But I think the first thing to do is get some sort of > > consensus on what we want to say. If producing an additional > > individual draft as an interim placeholder is the pragmatic > > way to do it, fine. In any case, we should certainly try to > > have some discussions on these points on Monday's call - if > > you wish I could let you lead that discussion (say 15 > > minutes, stealing from each of the other slots). Let me know. > > > > John (as chair) > > > > > -----Original Message----- > > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > Sent: 05 May 2011 00:17 > > > To: Henry Lum; Elwell, John; siprec@ietf.org > > > Subject: RE: [siprec] summary of changes for > > > draft-portman-siprec-protocol-04 > > > > > > I intended to put together a draft covering RTP recommendations and > > > models. Unfortunately, I did not have enough bandwidth to get > > > this done > > > in time for the interim meeting. Instead, I have attached my > > > thoughts to > > > get some feedback. I would be happy to continue work in this area if > > > people think it is useful. > > > > > > ------------------- > > > Version 0.2 > > > April 26, 2011 > > > > > > (1) Introduction > > > > > > This document provides recommendations and guidelines for > > RTP and RTCP > > > in the context of SIPREC. In order to communicate most > > > effectively, the > > > Session Recording Client (SRC) and the Session Recording > > (SRS) should > > > utilize the mechanisms provided by RTP in a well defined and > > > predicable > > > manner. It is the goal of this document to make the reader aware of > > > these mechanisms and provide recommendations and guidelines. This > > > document is completely informational. It includes no > > > requirements and no > > > normative language. > > > > > > (2) Definitions > > > > > > This document uses the definitions provided in > > > draft-ietf-siprec-architecture for all SIPREC modules. A Session > > > Recording Client (SRC), as defined within SIPREC, is expected to > > > implement one or more of a variety of RTP roles within the > > context of > > > various SIPREC use cases. These roles include, but are not > > limited to, > > > acting as an end system, a mixer, or a translator. This > > document uses > > > the definitions provided in "RTP: A Transport Protocol for Real-Time > > > Application" [RFC 3550] for these roles. > > > > > > > > > (3) RTCP > > > > > > The RTP data transport is augmented by a control protocol (RTCP) to > > > allow monitoring of the data delivery. RTCP, as defined in > > > [RFC3550], is > > > based on the periodic transmission of control packets to all > > > participants in the RTP session, using the same > > distribution mechanism > > > as the data packets. > > > Support for RTCP is recommended as it provides, among other > > > things, the > > > following important functionality in relation to SIPREC: > > > > > > 1) Feedback on the quality of the data distribution. This > > feedback is > > > important for flow and congestion control functions, and to > > > get feedback > > > from the receivers to diagnose faults in the distribution. As > > > such, RTCP > > > is a well defined and efficient mechanism for the SRS to > > > inform the SRC > > > or any issues that arise in the reception of media that is to be > > > recorded. > > > > > > 2) Carries a persistent transport-level identifier for an RTP source > > > called the canonical name or CNAME. The SSRC identifier may > > > change if a > > > conflict is discovered or a program is restarted; in which case > > > receivers can use the CNAME to keep track of each participant. > > > Receivers may also use the CNAME to associate multiple data > > > streams from > > > a given participant in a set of related RTP sessions, for example to > > > synchronize audio and video. Synchronization of media > > streams is also > > > facilitated by the NTP and RTP timestamps included in RTCP > > packets by > > > data senders. > > > > > > > > > (4) RTP Profile > > > > > > The recommended RTP profiles for both the SRC and SRS are "Extended > > > Secure RTP Profile for Real-time Transport Control Protocol > > > (RTCP)-Based > > > Feedback (RTP/SAVPF)", [RFC5124] when using encrypted RTP > > streams, and > > > "Extended RTP Profile for Real-time Transport Control Protocol > > > (RTCP)-Based Feedback (RTP/AVPF)", [RFC4585] when using non > > encrypted > > > media streams. However, as this is not a requirement, some > > > implementations may use "The Secure Real-time Transport Protocol > > > (SRTP)", [RFC 3711] and "RTP Profile for Audio and Video Conferences > > > with Minimal Control", AVP [RFC 3551]. Therefore, it is > > > recommended that > > > the SRC and SRS not rely entirely on SAVPF or AVPF for core > > > functionality that may be at least partially achievable > > using SAVP and > > > AVP. > > > > > > AVPF and SAVPF provide an improved RTCP timer model that allows more > > > flexible transmission of RTCP packets as response to events, > > > rather than > > > strictly according to bandwidth. > > > SAVP and SAVPF provide media encryption, integrity > > protection, replay > > > protection, and a limited form of source authentication. They do not > > > contain or require a specific keying mechanism. > > > > > > > > > (5) SRSC > > > > > > The synchronization source (SSRC), as defined in [RFC3550], > > is carried > > > in the RTP header and in various fields of RTCP packets. It > > > is a random > > > 32-bit number that is required to be globally unique within an RTP > > > session. It is crucial that the number be chosen with care in order > > > that participants on the same network or starting at the > > same time are > > > not likely to choose the same number. Guidelines regarding > > SSRC value > > > selection and conflict resolution are provided in [RFC3550]. > > > > > > The SSRC may also be used to separate different sources of > > > media within > > > a single RTP session. For this reason as well as for conflict > > > resolution, it is important that the SRC and SRC handle > > > changes in SSRC > > > values and properly identify the reason of the change. The > > > CNAME values > > > carried in RTCP facilitate this identification. > > > > > > > > > (6) CSRC > > > > > > The contributing source (CSRC), as defined in [RFC3550], > > > identifies the > > > source of a stream of RTP packets that has contributed to > > the combined > > > stream produced by an RTP mixer. The mixer inserts a list > > of the SSRC > > > identifiers of the sources that contributed to the generation of a > > > particular packet into the RTP header of that packet. This list is > > > called the CSRC list. It is recommended that a SRC, when > > > acting a mixer, > > > sets the CSRC list accordingly, and that the SRS interprets the CSRC > > > list appropriately when received. > > > > > > > > > (7) SDES > > > > > > The Source Description (SDES), as defined in [RFC3550], contains an > > > SSRC/CSRC identifier followed by a list of zero or more items, which > > > carry information about the SSRC/CSRC. End systems send one > > > SDES packet > > > containing their own source identifier (the same as the SSRC in the > > > fixed RTP header). A mixer sends one SDES packet containing > > > a chunk for > > > each contributing source from which it is receiving SDES > > > information, or > > > multiple complete SDES packets. > > > > > > (8) CNAME > > > > > > The Canonical End-Point Identifier (CNAME), as defined in [RFC3550], > > > provide the binding from the SSRC identifier to an > > identifier for the > > > source (sender or receiver) that remains constant. It is > > > important the > > > an SRC and SRS generate CNAMEs appropriately and use them for this > > > purpose. Guidelines for generating CNAME values are provided in > > > "Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names > > > (CNAMEs)" [RFC6222]. > > > > > > > > > (9) Keepalive > > > > > > It is anticipated that media streams in SIPREC may exist in inactive > > > states for extended periods of times for an of a number of valid > > > reasons. In order to the bindings and any pinholes in > > > NATs/firewalls to > > > remain active during such intervals, it is recommended to follow the > > > keep-alive procedures in "Application Mechanism for keeping > > alive the > > > Network Address Translator > > > (NAT) mappings associated to RTP/RTCP flows", > > > [draft-ietf-avt-app-rtp-keepalive] for all RTP media streams. > > > > > > > > > (10) RTCP Feedback Messages > > > > > > "Codec Control Messages in the RTP Audio-Visual Profile > > with Feedback > > > (AVPF)" [RFC 5104] specifies extensions to the messages > > > defined in AVPF > > > [RFC4585]. Support for and proper usage of these messages > > is important > > > to SRC and SRS implementations. > > > > > > (10.1) Full Intra Request > > > > > > A Full Intra Request (FIR) Command, when received by the > > > designate media > > > sender, requires that the media sender sends a Decoder > > > Refresh Point at > > > the earliest opportunity. Using a decoder refresh point implies > > > refraining from using any picture sent prior to that point as a > > > reference for the encoding process of any subsequent picture > > > sent in the > > > stream. > > > > > > Decoder refresh points, especially Intra or IDR pictures for > > > H.264 video > > > codecs, are in general several times larger in size than predicted > > > pictures. Thus, in scenarios in which the available bit > > rate is small, > > > the use of a decoder refresh point implies a delay that is > > > significantly > > > longer than the typical picture duration. > > > > > > (10.1.1) SIP INFO for FIR > > > > > > "XML Schema for Media Control" [RFC5168] defines an > > Extensible Markup > > > Language (XML) Schema for video fast update. Implementations are > > > discouraged from using the method described except for backward > > > compatibility purposes. Implementations should use FIR messages, as > > > described in (10.1) instead. > > > > > > > > > (10.2) Picture Loss Indicator > > > Using the FIR command to recover from errors is explicitly > > disallowed, > > > and instead the PLI message defined in AVPF [RFC4585] > > should be used. > > > The PLI message reports lost pictures and has been included > > > in AVPF for > > > precisely that purpose. > > > > > > > > > (10.3) Temporary Maximum Media Stream Bit Rate Request > > > > > > A receiver, translator, or mixer uses the Temporary Maximum > > > Media Stream > > > Bit Rate Request (TMMBR) to request a sender to limit the > > maximum bit > > > rate for a media stream to the provided value. Appropriate > > > use of TMMBR > > > facilitates rapid adaptation to changes in available bandwidth. > > > > > > (10.3.1) Renegotiation of SDP bandwidth attribute > > > > > > If it is likely that the new value indicated by TMMBR will be > > > valid for > > > the remainder of the session, the TMMBR sender is expected to > > > perform a > > > renegotiation of the session upper limit using the session signaling > > > protocol. Therefore for SIPREC, implementations are > > recommended to use > > > TMMBR for temporary changes, and renegotiation of bandwidth via SDP > > > offer/answer of more permanent changes. > > > > > > > > > (11) Symmetric RTP/RTCP > > > > > > Within the SDP offer/answer, RTP entities choose the RTP and RTCP > > > transport addresses (i.e., IP addresses and port numbers) > > on which to > > > receive packets. When sending RTP packets; however, they may use a > > > different IP address or port number for RTP, RTCP, or both. > > Symmetric > > > RTP/RTCP requires that the IP address and port number for > > sending and > > > receiving RTP/RTCP packets are identical. Using Symmetric > > RTP and RTCP > > > [RFC4961] is recommended. > > > > > > --------------------- > > > > > > Cheers, > > > Charles > > > > > > > -----Original Message----- > > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > > Behalf Of Henry Lum > > > > Sent: Tuesday, May 03, 2011 11:18 AM > > > > To: Elwell, John; siprec@ietf.org > > > > Subject: Re: [siprec] summary of changes for > > > draft-portman-siprec-protocol-04 > > > > > > > > Hi John, > > > > > > > > Okay, let's discuss this topic further in the interim meeting to > > > > determine whether there is any need to specify any > > protocol related > > > > changes. > > > > > > > > Regards, > > > > Henry > > > > > > > > > -----Original Message----- > > > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > > Sent: Tuesday, May 03, 2011 12:44 PM > > > > > To: Henry Lum; siprec@ietf.org > > > > > Subject: RE: summary of changes for > > > draft-portman-siprec-protocol-04 > > > > > > > > > > Henry, > > > > > > > > > > Concerning the RTP model, I agree that the consensus to > > date seems > > > to > > > > > be to cover different RTP models, but I feel we should > > > get something > > > > > into the architecture draft to start with, and then later see > > > whether > > > > > there is any impact on the protocol draft. > > > > > > > > > > John > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: siprec-bounces@ietf.org > > > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Henry Lum > > > > > > Sent: 02 May 2011 04:09 > > > > > > To: siprec@ietf.org > > > > > > Subject: [siprec] summary of changes for > > > > > > draft-portman-siprec-protocol-04 > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > I want to summarize the list of changes we are planning to > > > > > > include in the next revision of the document: > > > > > > > > > > > > > > > > > > > > > > > > - Remove use of INFO > > > > > > > > > > > > - Both INVITE or UPDATE can be used for metadata > > > > > > transport through content-disposition > > > > > > > > > > > > - Recording indication is placed at SDP media level > > > > > > > > > > > > - Recording awareness is indicated at SIP level with > > > > > > options; feature tag was also considered > > > > > > > > > > > > - Recording preference is placed at SDP media level > > > > > > > > > > > > - RTP model discussion and time synchronization; so > > > > > > far we seem to agree to handle different RTP models rather > > > > > > than requiring a single model. There are 3 models we have > > > > > > identified so far: > > > > > > > > > > > > o RTP mixer - SRC mixes media streams and can directly > > > > > > synchronize timestamps with metadata and also generate RTCP > > > > > > > > > > > > o RTP translator - Media streams are simply forwarded to > > > > > > the SRS by the SRC. SRC is only capable to indicating > > > > > > start/stop times to the SRS in metadata. > > > > > > > > > > > > o RTP endpoint (is that the right term?) - SRC is neither a > > > > > > mixer nor translator, but is capable of rewriting RTP and > > > > > > RTCP in order to synchronize on the timestamps with metadata. > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > Henry > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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. > > > > > > > > _______________________________________________ > > > > siprec mailing list > > > > siprec@ietf.org > > > > https://www.ietf.org/mailman/listinfo/siprec > > > From eckelcu@cisco.com Fri May 6 15:56:54 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 1DC18E06A0 for ; Fri, 6 May 2011 15:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.497 X-Spam-Level: X-Spam-Status: No, score=-9.497 tagged_above=-999 required=5 tests=[AWL=-0.698, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yz6J8iA0sY7w for ; Fri, 6 May 2011 15:56: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 E1113E069B for ; Fri, 6 May 2011 15:56:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=33416; q=dns/txt; s=iport; t=1304722611; x=1305932211; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=O20Sx9TcZVuypsOrv7ykQUwHn+5M7NT/Fd1cWQINNNI=; b=DpTF9LJtJ8mDUEmKLf58my6DsOvX2e3BtdBEPloWjjAAC83bMfA3BZoC FG5xH7kOz8vB6sgnKbhMtQUmUEVRMzQZpDJuIaoNG26E6VIAh7LlrJPC7 PKmG3g67PeuVZTlATXL4Bd0CTN0sp4GOBnJxch1REKH3Nn/wPESdHk/oH Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlsBAKd7xE2rRDoJ/2dsb2JhbACXc44rd6gHnXeDDYJ8BIY9jUiKRw X-IronPort-AV: E=Sophos;i="4.64,329,1301875200"; d="scan'208";a="693448004" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-6.cisco.com with ESMTP; 06 May 2011 22:56: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 p46MuoU7004863; Fri, 6 May 2011 22:56: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); Fri, 6 May 2011 15:56:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: AQ5m A5P0 BtO0 G0Ft Ii8r IkCi JCjK JJSb QrGo Sjs/ V6Ge WZ1Q W9Tw ZauI cD7u fbZU; 3; aABrAGEAcABsAGEAbgBAAGEAYwBtAGUAcABhAGMAawBlAHQALgBjAG8AbQA7AGoAbwBoAG4ALgBlAGwAdwBlAGwAbABAAHMAaQBlAG0AZQBuAHMALQBlAG4AdABlAHIAcAByAGkAcwBlAC4AYwBvAG0AOwBzAGkAcAByAGUAYwBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {BD4BE87E-FD59-47AC-9759-96D83FA2FFEF}; ZQBjAGsAZQBsAGMAdQBAAGMAaQBzAGMAbwAuAGMAbwBtAA==; Fri, 06 May 2011 22:56:44 GMT; UgBFADoAIABbAHMAaQBwAHIAZQBjAF0AIABQAGEAcgB0AGkAYQBsACAAdQBwAGQAYQB0AGUAcwAgAGEAbgBkACAAaQBkAGUAbgB0AGkAZgBpAGUAcgBzAA== MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {BD4BE87E-FD59-47AC-9759-96D83FA2FFEF} Content-class: urn:content-classes:message Date: Fri, 6 May 2011 15:56:44 -0700 Message-ID: In-Reply-To: <4DC469EF.6040705@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Partial updates and identifiers Thread-Index: AcwMNbtKwE04CzQ3SjOPU5ou/d9IHwACbthA References: <4DC31AC4.9030309@cisco.com> <4DC3E53E.9050202@cisco.com> <4DC469EF.6040705@cisco.com> From: "Charles Eckel (eckelcu)" To: "Paul Kyzivat (pkyzivat)" X-OriginalArrivalTime: 06 May 2011 22:56:50.0721 (UTC) FILETIME=[E2AB2910:01CC0C40] 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: Fri, 06 May 2011 22:56:54 -0000 If the participant generates its own ID instead, it could represent itself the same for all instances that it wants correlated. This could be a To/From URI, or a P-Asserted-Identity URI. It will not work in all cases, but it could in some. If I understand your point correctly, an SRC/SRS could still use some metadata to achieve this same thing, and having globally unique participant IDs enables having other mechanisms, outside the scope of SIPREC, that do not rely on endpoints to represent themselves in a consistent fashion. Do I have it straight now? Thanks, Charles > -----Original Message----- > From: Paul Kyzivat (pkyzivat) > Sent: Friday, May 06, 2011 2:37 PM > To: Charles Eckel (eckelcu) > Cc: Elwell, John; Parthasarathi R (partr); siprec@ietf.org; Peter Saint-Andre (psaintan); Joe > Hildebrand (jhildebr); Hadriel Kaplan > Subject: Re: [siprec] Partial updates and identifiers >=20 > Charles, >=20 > On 5/6/2011 1:04 PM, Charles Eckel (eckelcu) wrote: > > The reason I brought this up was in response to Partha's assertion that > > participant IDs need to be globally unique rather than unique within a > > given CS, RS, or recording. The point I was trying to make was that an > > SRS might actually want a way to correlate participants, either by > > participant ID or some other metadata or some mechanism outside the > > scope of SIPREC. While this is still possible with globally unique > > participant IDs, it is made more difficult. >=20 > ??? >=20 > How? Having globally unique ones makes it *possible* for more than one > src to reference the same one. If the SRS wants to correlate ones that > are different, how does this make it more difficult? >=20 > > So in this case, mandating > > that participant IDs be globally unique make things more > > complex/difficult. Why are globally unique participant IDs across all > > CSs and RSs required? That is what I am trying to understand. > > They is some cost associated with this, and I want to make sure the cost > > is warranted. >=20 > As noted above, being globally unique means that two different SRCs that > find a way of discovering each others ids MAY then reference/reuse them. >=20 > If the ids are instead *locally* unique to an SRC, then the SRS still > has to make them globally unique if it stores in common the data from > multiple SRCs. (It can do that by prefixing the src-local id with a uid > for the SRC.) But that has its own problems. >=20 > In that environment if src1 knows and wants to reference an id generated > by src2, it can't do so unless there is a way for src1 to include an id > like src2:id. And if we allow that we are back to globally unique ids - > just of a different format. Or else you just can't cross reference at all. >=20 > Another issue with this is that if the ids are not globally unique, then > *exactly* what is the scope in which they *are* unique. For the SRS to > understand them properly that must be nailed down. Once you get beyond a > single RS session, there starts to be uncertainty whether two RSs > involved the same SRC or different ones. Of course we could solve that > by requiring the SRC to provide a globally unique id for itself, and > other ids that are unique within the scope of that one. But that is > again just a different way of encoding globally unique ids. >=20 > Thanks, > Paul >=20 > > Cheers, > > Charles > > > >> -----Original Message----- > >> From: Paul Kyzivat (pkyzivat) > >> Sent: Friday, May 06, 2011 5:11 AM > >> To: Elwell, John > >> Cc: Charles Eckel (eckelcu); Parthasarathi R (partr); siprec@ietf.org; > > Peter Saint-Andre (psaintan); > >> Joe Hildebrand (jhildebr); Hadriel Kaplan > >> Subject: Re: [siprec] Partial updates and identifiers > >> > >> John, > >> > >> I think we are in agreement. My point was that some SRCs may be > > smarter > >> about this than others. If they are able to figure out when to reuse > > the > >> same participant id, then that is great, but not required. > >> > >> (Of course they must not reuse the same participant id *by accident*.) > >> > >> Thanks, > >> Paul > >> > >> On 5/6/2011 3:14 AM, Elwell, John wrote: > >>> When is a participant the same participant and when is it different? > > I call into a conference from > >> my desk phone. I later drop out and then call in again to the same > > conference from my cell phone. The > >> conference is being recorded. In this case it is unlikely that the SRC > > will have any information to > >> correlate the new caller with the caller who dropped out, unless they > > happen to share the same SIP > >> AOR. > >>> > >>> I think it is fine for participants to be assigned new IDs each time > > they join a call or participate > >> in different calls / different recordings. If other attributes of the > > Participant object can be used > >> to correlate two different Participant IDs (e.g., the same SIP AoR), > > this can be made use of. > >> Otherwise they are treated as different participants, even though it > > might be the same person. > >>> > >>> John (as individual) > >>> > >>> > >>>> -----Original Message----- > >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>>> Sent: 05 May 2011 22:47 > >>>> To: Charles Eckel (eckelcu) > >>>> Cc: Parthasarathi R (partr); Elwell, John; siprec@ietf.org; > >>>> Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr); > >>>> Hadriel Kaplan > >>>> Subject: Re: [siprec] Partial updates and identifiers > >>>> > >>>> > >>>> > >>>> On 5/5/2011 1:10 PM, Charles Eckel (eckelcu) wrote: > >>>>> I follow the logic, but let me run through a simple use case. > >>>>> > >>>>> 0) I am on a call that is part of a recording. Initially, this is > >>>>> through CS1 which results in RS1, which is part of recording X. My > >>>>> unique participant ID is p0. > >>>>> > >>>>> I drop off and call back in. I need to be brought back into the > > same > >>>>> recording X. Possible scenarios are: > >>>>> > >>>>> 1) I call back into CS1, and am added into recording X > >>>> through RS1. My > >>>>> unique participant ID is p1? > >>>> > >>>> Maybe. It depends on whether the SRC recognizes you as the same > >>>> participant and remembers that it had assigned p1 to you. > >>>> If not, then you will presumably appear as a new participant. > >>>> > >>>>> 2) I call into CS2, and am added to recording X through > >>>> RS1. My unique > >>>>> participant ID is p2? > >>>> > >>>> Pretty much the same answer as above. > >>>> > >>>> Its also up to the SRC to decide if this is part of CS1 or CS2. > >>>> > >>>>> 3) I call into CS2, and am added to recording X through > >>>> RS2. My unique > >>>>> participant ID is p3? > >>>> > >>>> Pretty much the same again. If it is the same SRC, and has > >>>> some history > >>>> to figure out what is going on, it can continue to use p1. > >>>> > >>>> If it is a different SRC, then its more of a challenge. There > >>>> would have > >>>> to be some sharing of info between the two for the new SRC to > > recover > >>>> the old p1. More likely you will get a new p3. > >>>> > >>>>> If the SRS is able to make use of some other metadata to > >>>> realize that > >>>>> p0=3Dp1=3Dp2=3Dp3, great, if not, they look like different participants. > >>>> > >>>> Yes, if the p(i) are different the SRS could still attempt > >>>> correlation, > >>>> but its outside our current scope. > >>>> > >>>> Thanks, > >>>> Paul > >>>> > >>>>> Cheers, > >>>>> Charles > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Parthasarathi R (partr) > >>>>>> Sent: Tuesday, May 03, 2011 9:46 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 > >>>>>> > >>>>>> Hi Charles, > >>>>>> > >>>>>> In case participants id has to be unique for single RS > >>>> with multiple > >>>>> CS as you mentioned below mail > >>>>>> and also, participant id has to be unique within single CS > >>>> which span > >>>>> across multiple RS (start& stop > >>>>>> of recording within CS scenario), then participant unique > >>>> id needs to > >>>>> be global (URN UUID) rather than > >>>>>> local id like xml:id. Please let me know in case you have any > > other > >>>>> opinion on the same. > >>>>>> > >>>>>> Thanks > >>>>>> Partha > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: Charles Eckel (eckelcu) > >>>>>> Sent: Wednesday, April 20, 2011 2:54 AM > >>>>>> 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 > >>>>>> > >>>>>> 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 > >>>>>>> > >>>>>>> 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? > >>>>>>> > >>>>>>> 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 eckelcu@cisco.com Fri May 6 16:27: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 0C22FE069A for ; Fri, 6 May 2011 16:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.371 X-Spam-Level: X-Spam-Status: No, score=-10.371 tagged_above=-999 required=5 tests=[AWL=0.228, 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 bWYMYmwhs0aH for ; Fri, 6 May 2011 16:27:03 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id AC56DE0708 for ; Fri, 6 May 2011 16:27:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=37266; q=dns/txt; s=iport; t=1304724423; x=1305934023; h=mime-version:subject:date:message-id:references:from:to; bh=uw4M4C0n2SlzWpKA2kIwGi7aYQanrGnrw+6mkZZzito=; b=Tvqx1yokA6kQKPPF/P8t5Q4lm1HmGJ3iriTc09ssGe71T9wdNDbKqmpP 6wC53I1AIKKH/cU4LqtTfZyOUoKWFPh4UWAM7NK/o0QUJOR2+CKiqwwfl s1d26z63CflvX2dEYk4g+/bhTj6oVnnSbtOkQR6Up9hF58q9Ti8XVkL2p c=; X-Files: RTP for SIPREC.txt : 12860 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlsBAPSCxE2rRDoG/2dsb2JhbACXc44rd4hxnnuddoMME4JqBIY9jUiKRw X-IronPort-AV: E=Sophos;i="4.64,329,1301875200"; d="txt'?scan'208";a="310288135" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-3.cisco.com with ESMTP; 06 May 2011 23:27:02 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p46NR2W8014422; Fri, 6 May 2011 23:27:02 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); Fri, 6 May 2011 16:27:02 -0700 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_01CC0C45.1A8172A8" Date: Fri, 6 May 2011 16:27:01 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RTP Recommendations (was RE: [siprec] summary of changes for draft-portman-siprec-protocol-04) Thread-Index: AcwIaR0YuGqr5XvNSMqltXB+NekCpQBR+yhgAAMNUZAAPOGiUABA+nAAABdOo4AADK6PAA== References: <059AF07365DC474393A19A3AF187DF7407028E4B@NAHALD.us.int.genesyslab.com> <059AF07365DC474393A19A3AF187DF74070292B2@NAHALD.us.int.genesyslab.com> From: "Charles Eckel (eckelcu)" To: "Charles Eckel (eckelcu)" , "Elwell, John" , "Henry Lum" , X-OriginalArrivalTime: 06 May 2011 23:27:02.0835 (UTC) FILETIME=[1AC5D030:01CC0C45] Subject: Re: [siprec] RTP Recommendations (was RE: summary of changes for draft-portman-siprec-protocol-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: Fri, 06 May 2011 23:27:06 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC0C45.1A8172A8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The attached document addresses the comments provided by John and includes a copy/paste of the RTP models provided by Andy. I have placed them both within this single document to facilitate discussion in Monday's session. What we actually want to say and how/where to arrange it will be a subject of Monday's discussion. Cheers, Charles=20 > -----Original Message----- > From: Charles Eckel (eckelcu) > Sent: Friday, May 06, 2011 10:23 AM > To: 'Elwell, John'; Henry Lum; siprec@ietf.org > Subject: RE: RTP Recommendations (was RE: [siprec] summary of changes for draft-portman-siprec- > protocol-04) >=20 > Sounds good. I am not sure if I will find time to put any slides together by the end of today, but > worst case we can walk through the e-mails. > 15 minutes is great. >=20 > Cheers, > Charles >=20 > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Thursday, May 05, 2011 11:41 PM > > To: Charles Eckel (eckelcu); Henry Lum; siprec@ietf.org > > Subject: RTP Recommendations (was RE: [siprec] summary of changes for draft-portman-siprec-protocol- > > 04) > > > > Charles, > > > > Thanks for producing this. I see that Andy has also proposed some text on RTP, although there is > very > > little overlap between the two. Perhaps the two of you can work on a merged proposal. > > > > As has been stated before, I think we want to see some or all of this material in the architecture > > document, although if we need any normative material (e.g., on recommending profiles), that would > > probably need to go into the protocol document (the architecture document is only Informational). > > > > But I think the first thing to do is get some sort of consensus on what we want to say. If producing > > an additional individual draft as an interim placeholder is the pragmatic way to do it, fine. In any > > case, we should certainly try to have some discussions on these points on Monday's call - if you > wish > > I could let you lead that discussion (say 15 minutes, stealing from each of the other slots). Let me > > know. > > > > John (as chair) > > > > > -----Original Message----- > > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > Sent: 05 May 2011 00:17 > > > To: Henry Lum; Elwell, John; siprec@ietf.org > > > Subject: RE: [siprec] summary of changes for > > > draft-portman-siprec-protocol-04 > > > > > > I intended to put together a draft covering RTP recommendations and > > > models. Unfortunately, I did not have enough bandwidth to get > > > this done > > > in time for the interim meeting. Instead, I have attached my > > > thoughts to > > > get some feedback. I would be happy to continue work in this area if > > > people think it is useful. > > > > > > ------------------- > > > Version 0.2 > > > April 26, 2011 > > > > > > (1) Introduction > > > > > > This document provides recommendations and guidelines for RTP and RTCP > > > in the context of SIPREC. In order to communicate most > > > effectively, the > > > Session Recording Client (SRC) and the Session Recording (SRS) should > > > utilize the mechanisms provided by RTP in a well defined and > > > predicable > > > manner. It is the goal of this document to make the reader aware of > > > these mechanisms and provide recommendations and guidelines. This > > > document is completely informational. It includes no > > > requirements and no > > > normative language. > > > > > > (2) Definitions > > > > > > This document uses the definitions provided in > > > draft-ietf-siprec-architecture for all SIPREC modules. A Session > > > Recording Client (SRC), as defined within SIPREC, is expected to > > > implement one or more of a variety of RTP roles within the context of > > > various SIPREC use cases. These roles include, but are not limited to, > > > acting as an end system, a mixer, or a translator. This document uses > > > the definitions provided in "RTP: A Transport Protocol for Real-Time > > > Application" [RFC 3550] for these roles. > > > > > > > > > (3) RTCP > > > > > > The RTP data transport is augmented by a control protocol (RTCP) to > > > allow monitoring of the data delivery. RTCP, as defined in > > > [RFC3550], is > > > based on the periodic transmission of control packets to all > > > participants in the RTP session, using the same distribution mechanism > > > as the data packets. > > > Support for RTCP is recommended as it provides, among other > > > things, the > > > following important functionality in relation to SIPREC: > > > > > > 1) Feedback on the quality of the data distribution. This feedback is > > > important for flow and congestion control functions, and to > > > get feedback > > > from the receivers to diagnose faults in the distribution. As > > > such, RTCP > > > is a well defined and efficient mechanism for the SRS to > > > inform the SRC > > > or any issues that arise in the reception of media that is to be > > > recorded. > > > > > > 2) Carries a persistent transport-level identifier for an RTP source > > > called the canonical name or CNAME. The SSRC identifier may > > > change if a > > > conflict is discovered or a program is restarted; in which case > > > receivers can use the CNAME to keep track of each participant. > > > Receivers may also use the CNAME to associate multiple data > > > streams from > > > a given participant in a set of related RTP sessions, for example to > > > synchronize audio and video. Synchronization of media streams is also > > > facilitated by the NTP and RTP timestamps included in RTCP packets by > > > data senders. > > > > > > > > > (4) RTP Profile > > > > > > The recommended RTP profiles for both the SRC and SRS are "Extended > > > Secure RTP Profile for Real-time Transport Control Protocol > > > (RTCP)-Based > > > Feedback (RTP/SAVPF)", [RFC5124] when using encrypted RTP streams, and > > > "Extended RTP Profile for Real-time Transport Control Protocol > > > (RTCP)-Based Feedback (RTP/AVPF)", [RFC4585] when using non encrypted > > > media streams. However, as this is not a requirement, some > > > implementations may use "The Secure Real-time Transport Protocol > > > (SRTP)", [RFC 3711] and "RTP Profile for Audio and Video Conferences > > > with Minimal Control", AVP [RFC 3551]. Therefore, it is > > > recommended that > > > the SRC and SRS not rely entirely on SAVPF or AVPF for core > > > functionality that may be at least partially achievable using SAVP and > > > AVP. > > > > > > AVPF and SAVPF provide an improved RTCP timer model that allows more > > > flexible transmission of RTCP packets as response to events, > > > rather than > > > strictly according to bandwidth. > > > SAVP and SAVPF provide media encryption, integrity protection, replay > > > protection, and a limited form of source authentication. They do not > > > contain or require a specific keying mechanism. > > > > > > > > > (5) SRSC > > > > > > The synchronization source (SSRC), as defined in [RFC3550], is carried > > > in the RTP header and in various fields of RTCP packets. It > > > is a random > > > 32-bit number that is required to be globally unique within an RTP > > > session. It is crucial that the number be chosen with care in order > > > that participants on the same network or starting at the same time are > > > not likely to choose the same number. Guidelines regarding SSRC value > > > selection and conflict resolution are provided in [RFC3550]. > > > > > > The SSRC may also be used to separate different sources of > > > media within > > > a single RTP session. For this reason as well as for conflict > > > resolution, it is important that the SRC and SRC handle > > > changes in SSRC > > > values and properly identify the reason of the change. The > > > CNAME values > > > carried in RTCP facilitate this identification. > > > > > > > > > (6) CSRC > > > > > > The contributing source (CSRC), as defined in [RFC3550], > > > identifies the > > > source of a stream of RTP packets that has contributed to the combined > > > stream produced by an RTP mixer. The mixer inserts a list of the SSRC > > > identifiers of the sources that contributed to the generation of a > > > particular packet into the RTP header of that packet. This list is > > > called the CSRC list. It is recommended that a SRC, when > > > acting a mixer, > > > sets the CSRC list accordingly, and that the SRS interprets the CSRC > > > list appropriately when received. > > > > > > > > > (7) SDES > > > > > > The Source Description (SDES), as defined in [RFC3550], contains an > > > SSRC/CSRC identifier followed by a list of zero or more items, which > > > carry information about the SSRC/CSRC. End systems send one > > > SDES packet > > > containing their own source identifier (the same as the SSRC in the > > > fixed RTP header). A mixer sends one SDES packet containing > > > a chunk for > > > each contributing source from which it is receiving SDES > > > information, or > > > multiple complete SDES packets. > > > > > > (8) CNAME > > > > > > The Canonical End-Point Identifier (CNAME), as defined in [RFC3550], > > > provide the binding from the SSRC identifier to an identifier for the > > > source (sender or receiver) that remains constant. It is > > > important the > > > an SRC and SRS generate CNAMEs appropriately and use them for this > > > purpose. Guidelines for generating CNAME values are provided in > > > "Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names > > > (CNAMEs)" [RFC6222]. > > > > > > > > > (9) Keepalive > > > > > > It is anticipated that media streams in SIPREC may exist in inactive > > > states for extended periods of times for an of a number of valid > > > reasons. In order to the bindings and any pinholes in > > > NATs/firewalls to > > > remain active during such intervals, it is recommended to follow the > > > keep-alive procedures in "Application Mechanism for keeping alive the > > > Network Address Translator > > > (NAT) mappings associated to RTP/RTCP flows", > > > [draft-ietf-avt-app-rtp-keepalive] for all RTP media streams. > > > > > > > > > (10) RTCP Feedback Messages > > > > > > "Codec Control Messages in the RTP Audio-Visual Profile with Feedback > > > (AVPF)" [RFC 5104] specifies extensions to the messages > > > defined in AVPF > > > [RFC4585]. Support for and proper usage of these messages is important > > > to SRC and SRS implementations. > > > > > > (10.1) Full Intra Request > > > > > > A Full Intra Request (FIR) Command, when received by the > > > designate media > > > sender, requires that the media sender sends a Decoder > > > Refresh Point at > > > the earliest opportunity. Using a decoder refresh point implies > > > refraining from using any picture sent prior to that point as a > > > reference for the encoding process of any subsequent picture > > > sent in the > > > stream. > > > > > > Decoder refresh points, especially Intra or IDR pictures for > > > H.264 video > > > codecs, are in general several times larger in size than predicted > > > pictures. Thus, in scenarios in which the available bit rate is small, > > > the use of a decoder refresh point implies a delay that is > > > significantly > > > longer than the typical picture duration. > > > > > > (10.1.1) SIP INFO for FIR > > > > > > "XML Schema for Media Control" [RFC5168] defines an Extensible Markup > > > Language (XML) Schema for video fast update. Implementations are > > > discouraged from using the method described except for backward > > > compatibility purposes. Implementations should use FIR messages, as > > > described in (10.1) instead. > > > > > > > > > (10.2) Picture Loss Indicator > > > Using the FIR command to recover from errors is explicitly disallowed, > > > and instead the PLI message defined in AVPF [RFC4585] should be used. > > > The PLI message reports lost pictures and has been included > > > in AVPF for > > > precisely that purpose. > > > > > > > > > (10.3) Temporary Maximum Media Stream Bit Rate Request > > > > > > A receiver, translator, or mixer uses the Temporary Maximum > > > Media Stream > > > Bit Rate Request (TMMBR) to request a sender to limit the maximum bit > > > rate for a media stream to the provided value. Appropriate > > > use of TMMBR > > > facilitates rapid adaptation to changes in available bandwidth. > > > > > > (10.3.1) Renegotiation of SDP bandwidth attribute > > > > > > If it is likely that the new value indicated by TMMBR will be > > > valid for > > > the remainder of the session, the TMMBR sender is expected to > > > perform a > > > renegotiation of the session upper limit using the session signaling > > > protocol. Therefore for SIPREC, implementations are recommended to use > > > TMMBR for temporary changes, and renegotiation of bandwidth via SDP > > > offer/answer of more permanent changes. > > > > > > > > > (11) Symmetric RTP/RTCP > > > > > > Within the SDP offer/answer, RTP entities choose the RTP and RTCP > > > transport addresses (i.e., IP addresses and port numbers) on which to > > > receive packets. When sending RTP packets; however, they may use a > > > different IP address or port number for RTP, RTCP, or both. Symmetric > > > RTP/RTCP requires that the IP address and port number for sending and > > > receiving RTP/RTCP packets are identical. Using Symmetric RTP and RTCP > > > [RFC4961] is recommended. > > > > > > --------------------- > > > > > > Cheers, > > > Charles > > > > > > > -----Original Message----- > > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > > Behalf Of Henry Lum > > > > Sent: Tuesday, May 03, 2011 11:18 AM > > > > To: Elwell, John; siprec@ietf.org > > > > Subject: Re: [siprec] summary of changes for > > > draft-portman-siprec-protocol-04 > > > > > > > > Hi John, > > > > > > > > Okay, let's discuss this topic further in the interim meeting to > > > > determine whether there is any need to specify any protocol related > > > > changes. > > > > > > > > Regards, > > > > Henry > > > > > > > > > -----Original Message----- > > > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > > Sent: Tuesday, May 03, 2011 12:44 PM > > > > > To: Henry Lum; siprec@ietf.org > > > > > Subject: RE: summary of changes for > > > draft-portman-siprec-protocol-04 > > > > > > > > > > Henry, > > > > > > > > > > Concerning the RTP model, I agree that the consensus to date seems > > > to > > > > > be to cover different RTP models, but I feel we should > > > get something > > > > > into the architecture draft to start with, and then later see > > > whether > > > > > there is any impact on the protocol draft. > > > > > > > > > > John > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: siprec-bounces@ietf.org > > > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Henry Lum > > > > > > Sent: 02 May 2011 04:09 > > > > > > To: siprec@ietf.org > > > > > > Subject: [siprec] summary of changes for > > > > > > draft-portman-siprec-protocol-04 > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > I want to summarize the list of changes we are planning to > > > > > > include in the next revision of the document: > > > > > > > > > > > > > > > > > > > > > > > > - Remove use of INFO > > > > > > > > > > > > - Both INVITE or UPDATE can be used for metadata > > > > > > transport through content-disposition > > > > > > > > > > > > - Recording indication is placed at SDP media level > > > > > > > > > > > > - Recording awareness is indicated at SIP level with > > > > > > options; feature tag was also considered > > > > > > > > > > > > - Recording preference is placed at SDP media level > > > > > > > > > > > > - RTP model discussion and time synchronization; so > > > > > > far we seem to agree to handle different RTP models rather > > > > > > than requiring a single model. There are 3 models we have > > > > > > identified so far: > > > > > > > > > > > > o RTP mixer - SRC mixes media streams and can directly > > > > > > synchronize timestamps with metadata and also generate RTCP > > > > > > > > > > > > o RTP translator - Media streams are simply forwarded to > > > > > > the SRS by the SRC. SRC is only capable to indicating > > > > > > start/stop times to the SRS in metadata. > > > > > > > > > > > > o RTP endpoint (is that the right term?) - SRC is neither a > > > > > > mixer nor translator, but is capable of rewriting RTP and > > > > > > RTCP in order to synchronize on the timestamps with metadata. > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > Henry > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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. > > > > > > > > _______________________________________________ > > > > siprec mailing list > > > > siprec@ietf.org > > > > https://www.ietf.org/mailman/listinfo/siprec > > > ------_=_NextPart_001_01CC0C45.1A8172A8 Content-Type: text/plain; name="RTP for SIPREC.txt" Content-Transfer-Encoding: base64 Content-Description: RTP for SIPREC.txt Content-Disposition: attachment; filename="RTP for SIPREC.txt" VmVyc2lvbiAwLjMNCk1heSA2LCAyMDExDQoNCigxKSBJbnRyb2R1Y3Rpb24NCg0KVGhpcyBkb2N1 bWVudCBwcm92aWRlcyByZWNvbW1lbmRhdGlvbnMgYW5kIGd1aWRlbGluZXMgZm9yIFJUUCBhbmQg UlRDUCBpbiB0aGUgY29udGV4dCBvZiBTSVBSRUMuIEluIG9yZGVyIHRvIGNvbW11bmljYXRlIG1v c3QgZWZmZWN0aXZlbHksIHRoZSBTZXNzaW9uIFJlY29yZGluZyBDbGllbnQgKFNSQykgYW5kIHRo ZSBTZXNzaW9uIFJlY29yZGluZyAoU1JTKSBzaG91bGQgdXRpbGl6ZSB0aGUgbWVjaGFuaXNtcyBw cm92aWRlZCBieSBSVFAgaW4gYSB3ZWxsIGRlZmluZWQgYW5kIHByZWRpY2FibGUgbWFubmVyLiBJ dCBpcyB0aGUgZ29hbCBvZiB0aGlzIGRvY3VtZW50IHRvIG1ha2UgdGhlIHJlYWRlciBhd2FyZSBv ZiB0aGVzZSBtZWNoYW5pc21zIGFuZCBwcm92aWRlIHJlY29tbWVuZGF0aW9ucyBhbmQgZ3VpZGVs aW5lcy4gVGhpcyBkb2N1bWVudCBpcyBjb21wbGV0ZWx5IGluZm9ybWF0aW9uYWwuIEl0IGluY2x1 ZGVzIG5vIHJlcXVpcmVtZW50cyBhbmQgbm8gbm9ybWF0aXZlIGxhbmd1YWdlLiANCg0KDQooMikg RGVmaW5pdGlvbnMNCg0KVGhpcyBkb2N1bWVudCB1c2VzIHRoZSBkZWZpbml0aW9ucyBwcm92aWRl ZCBpbiBkcmFmdC1pZXRmLXNpcHJlYy1hcmNoaXRlY3R1cmUgZm9yIGFsbCBTSVBSRUMgbW9kdWxl cy4gQSBTZXNzaW9uIFJlY29yZGluZyBDbGllbnQgKFNSQyksIGFzIGRlZmluZWQgd2l0aGluIFNJ UFJFQywgaXMgZXhwZWN0ZWQgdG8gaW1wbGVtZW50IG9uZSBvciBtb3JlIG9mIGEgdmFyaWV0eSBv ZiBSVFAgcm9sZXMgd2l0aGluIHRoZSBjb250ZXh0IG9mIHZhcmlvdXMgU0lQUkVDIHVzZSBjYXNl cy4gVGhlc2Ugcm9sZXMgaW5jbHVkZSwgYnV0IGFyZSBub3QgbGltaXRlZCB0bywgYWN0aW5nIGFz IGFuIGVuZCBzeXN0ZW0sIGEgbWl4ZXIsIG9yIGEgdHJhbnNsYXRvci4gVGhpcyBkb2N1bWVudCB1 c2VzIHRoZSBkZWZpbml0aW9ucyBwcm92aWRlZCBpbiAiUlRQOiBBIFRyYW5zcG9ydCBQcm90b2Nv bCBmb3IgUmVhbC1UaW1lIEFwcGxpY2F0aW9uIiBbUkZDIDM1NTBdIGZvciB0aGVzZSByb2xlcy4g DQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLQ0KUjMueCBSVFAgUm9sZXMNCkFuIFNSQyBoYXMgdGhl IHRhc2sgb2YgZ2F0aGVyaW5nIFJUUCBtZWRpYSBmcm9tIHRoZSB2YXJpb3VzIHBhcnRpY2lwYW50 cyBpbiBhIENTIGFuZCBmb3J3YXJkaW5nIHRoZSBpbmZvcm1hdGlvbiB0byB0aGUgU1JTIGluIHRo ZSBjb250ZXh0IG9mIHRoZSBSUy4gRm9yIGEgZ2l2ZW4gbWVkaWEgc3RyZWFtIHRoZSBTUkMgaGFz IGEgbnVtYmVyIG9mIHdheXMgb2YgZG9pbmcgdGhpcyBhbmQgbWF5IGNob29zZSBkaWZmZXJlbnQg d2F5cyBmb3IgZGlmZmVyZW50IG1lZGlhIHN0cmVhbXMuDQoNClIzLnguMSBTUkMgYWN0aW5nIGFz IGFuIFJUUCBUcmFuc2xhdG9yLg0KDQpUaGUgU1JDIG1heSBhY3QgYXMgYSB0cmFuc2xhdG9yLCBh cyBkZWZpbmVkIGluIFtSRkMzNTUwXS4gSW4gdGhpcyBjYXNlLCB0aGUgU1JDIGZvcndhcmRzIFJU UCBwYWNrZXRzIHRvIHRoZSBTUlMgd2l0aCB0aGVpciBzeW5jaHJvbml6YXRpb24gc291cmNlIGlk ZW50aWZpZXIgdW5jaGFuZ2VkLiBPcHRpb25hbGx5IGFuIFNSQyBhY3RpbmcgYXMgYSB0cmFuc2xh dG9yIGNhbiAgcGVyZm9ybSB0cmFuc2NvZGluZyAoZnJvbSBvbmUgY29kZWMgdG8gYW5vdGhlciks IGFuZCB0aGlzIGNhbiByZXN1bHQgaW4gYSBkaWZmZXJlbnQgcmF0ZSBvZiBwYWNrZXRzLiBXaXRo IHRoaXMgYXBwcm9hY2gsIFJUUCBmcm9tIGRpZmZlcmVudCBzb3VyY2VzIChpLmUuLCBmcm9tIGRp ZmZlcmVudCBwYXJ0aWNpcGFudHMpIGNhbm5vdCBiZSBtaXhlZCBieSB0aGUgU1JDIGFuZCBtdXN0 IGJlIHNlbnQgc2VwYXJhdGVseSB0byB0aGUgU1JTLiBJbiB0aGlzIGNhc2UgYWxsIFJUQ1AgcmVw b3J0cyBhcmUgcGFzc2VkIG9uIGJ5IHRoZSBTUkMgdG8gdGhlIHBhcnRpY2lwYW50cyB3aGljaCB3 aWxsIGJlIGFibGUgdG8gZGV0ZWN0IGFueSBTU1JDIGNvbGxpc2lvbnMuDQoNClJUQ1AgcGFja2V0 cyBTZW5kZXIgUmVwb3J0cyB3aWxsIGdlbmVyYXRlZCBieSBhIHBhcnRpY2lwYW50IHNlbmRpbmcg YSBzdHJlYW0gYW5kIHdpbGwgbmVlZCB0byBiZSBmb3J3YXJkZWQgdG8gdGhlIFNSUyAoaW4gYWRk aXRpb24gdG8gYmVpbmcgc2VudCB0byByZWNlaXZpbmcgcGFydGljaXBhbnRzKS4gUlRDUCBSZWNl aXZlciBSZXBvcnRzIHdpbGwgYmUgZ2VuZXJhdGVkIGJ5IHRoZSBTUlMgYW5kIG5lZWQgdG8gYmUg Zm9yd2FyZGVkIHRvIHRoZSByZWxldmFudCBwYXJ0aWNpcGFudCwgdGhlIFNSQyBpbiB0aGUgY2Fz ZSBtYXkgbmVlZCB0byBtYW5pcHVsYXRlIHRoZSBSVENQIFJlY2VpdmVyIFJlcG9ydHMgdG8gdGFr ZSBhY2NvdW50IG9mIGFueSB0cmFuc2NvZGluZyB0aGF0IGhhcyB0YWtlbiBwbGFjZS4gDQoNCk9Q RU4gSVNTVUUuIFdpdGggdGhpcyBhcHByb2FjaCwgY2FuIFNSVFAgYmUgdXNlZD8gQ2FuIFNSVFAg YmUgdXNlZCBvbiB0aGUgQ1MgYW5kIG5vdCBvbiB0aGUgUlMgYW5kIHZpY2UgdmVyc2E/IElmIFNS VFAgaXMgdXNlZCBvbiBib3RoIHRoZSBDUyBhbmQgdGhlIFJTLCBjYW4gZGVjcnlwdGlvbiBhbmQg cmUtZW5jcnlwdGlvbiBvY2N1ciBhbmQvb3IgY2FuIGRlY3J5cHRpb24gYW5kIHJlLWVuY3J5cHRp b24gYmUgYXZvaWRlZCAoY2xlYXJseSBub3Qgd2hlbiB0cmFuc2NvZGluZyBpcyBpbnZvbHZlZCBv ciBpZiBkaWZmZXJlbnQga2V5cyBhcmUgdG8gYmUgdXNlZD8gDQoNClIzLnguMiBTUkMgYWN0aW5n IGFzIGFuIFJUUCBNaXhlci4NCg0KSW4gdGhlIGNhc2Ugb2YgdGhlIFNSQyBhY3RpbmcgYXMgYSBS VFAgbWl4ZXIuIGFzIGRlZmluZWQgaW4gW1JGQzM1NTBdLCB0aGUgU1JDIGNvbWJpbmVzIFJUUCBz dHJlYW1zIGZyb20gZGlmZmVyZW50IHBhcnRpY2lwYW50cyBhbmQgc2VuZHMgdGhlbSB0b3dhcmRz IHRoZSBTUlMgdXNpbmcgaXRzIG93biBzeW5jaHJvbml6YXRpb24gc291cmNlIGlkZW50aWZpZXIu IEl0IHdpbGwgbWFrZSB0aW1pbmcgYWRqdXN0bWVudHMgYW1vbmcgdGhlIHJlY2VpdmVkIHN0cmVh bXMgYW5kIGdlbmVyYXRlIGl0cyBvd24gdGltaW5nIG9uIHRoZSBzdHJlYW0gc2VudCB0byB0aGUg U1JTLiBPcHRpb25hbGx5IGFuIFNSQyBhY3RpbmcgYXMgYSBtaXhlciBjYW4gcGVyZm9ybSB0cmFu c2NvZGluZywgYW5kIGNhbiBldmVuIGNvcGUgd2l0aCBkaWZmZXJlbnQgY29kaW5ncyByZWNlaXZl ZCBmcm9tIGRpZmZlcmVudCBwYXJ0aWNpcGFudHMuIFJUQ1AgU2VuZGVyIFJlcG9ydHMgYW5kIFJl Y2VpdmVyIFJlcG9ydHMgYXJlIG5vdCBmb3J3YXJkZWQgYnkgYW4gU1JDIGFjdGluZyBhcyBtaXhl ciwgYnV0IHRoZXJlIGFyZSByZXF1aXJlbWVudHMgZm9yIGZvcndhcmRpbmcgUlRDUCBTb3VyY2Ug RGVzY3JpcHRpb24gKFNERVMpIHBhY2tldHMuIFRoZSB1c2Ugb2YgU1JUUCBiZXR3ZWVuIHRoZSBT UkMgYW5kIHRoZSBTUlMgaXMgaW5kZXBlbmRlbnQgb2YgdGhlIHVzZSBvZiBTUlRQIG9uIHRoZSBD Uy4NCg0KUjMueC4zIFNSQyBhY3RpbmcgYXMgYW4gUlRQIEVuZHBvaW50Lg0KDQpUaGUgY2FzZSBv ZiB0aGUgU1JDIGFjdGluZyBhcyBhbiBSVFAgZW5kcG9pbnQsIGFzIGRlZmluZWQgaW4gW1JGQzM1 NTBdLCBpcyBzaW1pbGFyIHRvIHRoZSBtaXhlciBjYXNlLCBleGNlcHQgdGhhdCB0aGUgUlRQIHNl c3Npb24gYmV0d2VlbiB0aGUgU1JDIGFuZCB0aGUgU1JTIGlzIGNvbnNpZGVyZWQgY29tcGxldGVs eSBpbmRlcGVuZGVudCBmcm9tIHRoZSBSVFAgc2Vzc2lvbiB0aGF0IGlzIHBhcnQgb2YgdGhlIENT LiBUaGUgU1JDIGNhbiwgYnV0IG5lZWQgbm90LCBtaXggUlRQIHN0cmVhbXMgZnJvbSBkaWZmZXJl bnQgcGFydGljaXBhbnRzIHByaW9yIHRvIHNlbmRpbmcgdG8gdGhlIFNSUy4gUlRDUCBiZXR3ZWVu IHRoZSBTUkMgYW5kIHRoZSBTUlMgaXMgY29tcGxldGVseSBpbmRlcGVuZGVudCBvZiBSVENQIG9u IHRoZSBDUy4gVGhlIHVzZSBvZiBTUlRQIGJldHdlZW4gdGhlIFNSQyBhbmQgdGhlIFNSUyBpcyBp bmRlcGVuZGVudCBvZiB0aGUgdXNlIG9mIFNSVFAgb24gdGhlIENTLg0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCg0KDQooMykgUlRDUA0KDQpUaGUgUlRQIGRhdGEgdHJhbnNwb3J0IGlz IGF1Z21lbnRlZCBieSBhIGNvbnRyb2wgcHJvdG9jb2wgKFJUQ1ApIHRvIGFsbG93IA0KbW9uaXRv cmluZyBvZiB0aGUgZGF0YSBkZWxpdmVyeS4gUlRDUCwgYXMgZGVmaW5lZCBpbiBbUkZDMzU1MF0s IGlzIGJhc2VkIG9uIHRoZSBwZXJpb2RpYyB0cmFuc21pc3Npb24gb2YgY29udHJvbCBwYWNrZXRz IHRvIGFsbCBwYXJ0aWNpcGFudHMgaW4gdGhlIFJUUCBzZXNzaW9uLCB1c2luZyB0aGUgc2FtZSBk aXN0cmlidXRpb24gbWVjaGFuaXNtIGFzIHRoZSBkYXRhIHBhY2tldHMuIFN1cHBvcnQgZm9yIFJU Q1AgaXMgcmVxdWlyZWQgYnkgUkZDIDM1NTAsIGFuZCBpdCBwcm92aWRlcywgYW1vbmcgb3RoZXIg dGhpbmdzLCB0aGUgZm9sbG93aW5nIGltcG9ydGFudCBmdW5jdGlvbmFsaXR5IGluIHJlbGF0aW9u IHRvIFNJUFJFQzoNCg0KMSkgRmVlZGJhY2sgb24gdGhlIHF1YWxpdHkgb2YgdGhlIGRhdGEgZGlz dHJpYnV0aW9uLiBUaGlzIGZlZWRiYWNrIGlzIA0KaW1wb3J0YW50IGZvciBmbG93IGFuZCBjb25n ZXN0aW9uIGNvbnRyb2wgZnVuY3Rpb25zLCBhbmQgdG8gZ2V0IGZlZWRiYWNrIGZyb20gdGhlIHJl Y2VpdmVycyB0byBkaWFnbm9zZSBmYXVsdHMgaW4gdGhlIGRpc3RyaWJ1dGlvbi4gQXMgc3VjaCwg UlRDUCBpcyBhIHdlbGwgZGVmaW5lZCBhbmQgZWZmaWNpZW50IG1lY2hhbmlzbSBmb3IgdGhlIFNS UyB0byBpbmZvcm0gdGhlIFNSQyBvciBhbnkgaXNzdWVzIHRoYXQgYXJpc2UgaW4gdGhlIHJlY2Vw dGlvbiBvZiBtZWRpYSB0aGF0IGlzIHRvIGJlIHJlY29yZGVkLiANCg0KMikgQ2FycmllcyBhIHBl cnNpc3RlbnQgdHJhbnNwb3J0LWxldmVsIGlkZW50aWZpZXIgZm9yIGFuIFJUUCBzb3VyY2UgY2Fs bGVkIHRoZSBjYW5vbmljYWwgbmFtZSBvciBDTkFNRS4gVGhlIFNTUkMgaWRlbnRpZmllciBtYXkg Y2hhbmdlIGlmIGEgY29uZmxpY3QgaXMgZGlzY292ZXJlZCBvciBhIHByb2dyYW0gaXMgcmVzdGFy dGVkOyBpbiB3aGljaCBjYXNlIHJlY2VpdmVycyBjYW4gdXNlIHRoZSBDTkFNRSB0byBrZWVwIHRy YWNrIG9mIGVhY2ggcGFydGljaXBhbnQuICBSZWNlaXZlcnMgbWF5IGFsc28gdXNlIHRoZSBDTkFN RSB0byBhc3NvY2lhdGUgbXVsdGlwbGUgZGF0YSBzdHJlYW1zIGZyb20gYSBnaXZlbiBwYXJ0aWNp cGFudCBpbiBhIHNldCBvZiByZWxhdGVkIFJUUCBzZXNzaW9ucywgZm9yIGV4YW1wbGUgdG8gc3lu Y2hyb25pemUgYXVkaW8gYW5kIHZpZGVvLiBTeW5jaHJvbml6YXRpb24gb2YgbWVkaWEgc3RyZWFt cyBpcyBhbHNvIGZhY2lsaXRhdGVkIGJ5IHRoZSBOVFAgYW5kIFJUUCB0aW1lc3RhbXBzIGluY2x1 ZGVkIGluIFJUQ1AgcGFja2V0cyBieSBkYXRhIHNlbmRlcnMuDQoNCg0KKDQpIFJUUCBQcm9maWxl DQoNClRoZSByZWNvbW1lbmRlZCBSVFAgcHJvZmlsZXMgZm9yIGJvdGggdGhlIFNSQyBhbmQgU1JT IGFyZSAiRXh0ZW5kZWQgU2VjdXJlIFJUUCBQcm9maWxlIGZvciBSZWFsLXRpbWUgVHJhbnNwb3J0 IENvbnRyb2wgUHJvdG9jb2wgKFJUQ1ApLUJhc2VkIEZlZWRiYWNrIChSVFAvU0FWUEYpIiwgW1JG QzUxMjRdIHdoZW4gdXNpbmcgZW5jcnlwdGVkIFJUUCBzdHJlYW1zLCBhbmQgIkV4dGVuZGVkIFJU UCBQcm9maWxlIGZvciBSZWFsLXRpbWUgVHJhbnNwb3J0IENvbnRyb2wgUHJvdG9jb2wgKFJUQ1Ap LUJhc2VkIEZlZWRiYWNrIChSVFAvQVZQRikiLCBbUkZDNDU4NV0gd2hlbiB1c2luZyBub24gZW5j cnlwdGVkIG1lZGlhIHN0cmVhbXMuIEhvd2V2ZXIsIGFzIHRoaXMgaXMgbm90IGEgcmVxdWlyZW1l bnQsIHNvbWUgaW1wbGVtZW50YXRpb25zIG1heSB1c2UgIlRoZSBTZWN1cmUgUmVhbC10aW1lIFRy YW5zcG9ydCBQcm90b2NvbCAoU1JUUCkiLCBbUkZDIDM3MTFdIGFuZCAiUlRQIFByb2ZpbGUgZm9y IEF1ZGlvIGFuZCBWaWRlbyBDb25mZXJlbmNlcyB3aXRoIE1pbmltYWwgQ29udHJvbCIsIEFWUCBb UkZDIDM1NTFdLiBUaGVyZWZvcmUsIGl0IGlzIHJlY29tbWVuZGVkIHRoYXQgdGhlIFNSQyBhbmQg U1JTIG5vdCByZWx5IGVudGlyZWx5IG9uIFNBVlBGIG9yIEFWUEYgZm9yIGNvcmUgZnVuY3Rpb25h bGl0eSB0aGF0IG1heSBiZSBhdCBsZWFzdCBwYXJ0aWFsbHkgYWNoaWV2YWJsZSB1c2luZyBTQVZQ IGFuZCBBVlAuDQoNCkFWUEYgYW5kIFNBVlBGIHByb3ZpZGUgYW4gaW1wcm92ZWQgUlRDUCB0aW1l ciBtb2RlbCB0aGF0IGFsbG93cyBtb3JlIGZsZXhpYmxlIHRyYW5zbWlzc2lvbiBvZiBSVENQIHBh Y2tldHMgYXMgcmVzcG9uc2UgdG8gZXZlbnRzLCByYXRoZXIgdGhhbiBzdHJpY3RseSBhY2NvcmRp bmcgdG8gYmFuZHdpZHRoLiBBVlBGIGJhc2VkIGNvZGVjIGNvbnRyb2wgbWVzc2FnZXMgcHJvdmlk ZSBlZmZpY2llbnQgbWVjaGFuaXNtcyBmb3IgYW4gU1JDIGFuZCBTUlMgdG8gaGFuZGxlIGV2ZW50 cyBzdWNoIGFzIHNjZW5lIGNoYW5nZXMsIGVycm9yIHJlY292ZXJ5LCBhbmQgZHluYW1pYyBiYW5k d2lkdGggYWRqdXN0bWVudHMuIFRoZXNlIG1lc3NhZ2VzIGFyZSBkaXNjdXNzZWQgaW4gbW9yZSBk ZXRhaWwgbGF0ZXIgaW4gdGhpcyBkb2N1bWVudC4NCg0KU0FWUCBhbmQgU0FWUEYgcHJvdmlkZSBt ZWRpYSBlbmNyeXB0aW9uLCBpbnRlZ3JpdHkgcHJvdGVjdGlvbiwgcmVwbGF5IHByb3RlY3Rpb24s IGFuZCBhIGxpbWl0ZWQgZm9ybSBvZiBzb3VyY2UgYXV0aGVudGljYXRpb24uIFRoZXkgZG8gbm90 IGNvbnRhaW4gb3IgcmVxdWlyZSBhIHNwZWNpZmljIGtleWluZyBtZWNoYW5pc20uIA0KDQoNCig1 KSBTUlNDDQoNClRoZSBzeW5jaHJvbml6YXRpb24gc291cmNlIChTU1JDKSwgYXMgZGVmaW5lZCBp biBbUkZDMzU1MF0sIGlzIGNhcnJpZWQgaW4gdGhlIFJUUCBoZWFkZXIgYW5kIGluIHZhcmlvdXMg ZmllbGRzIG9mIFJUQ1AgcGFja2V0cy4gSXQgaXMgYSByYW5kb20gMzItYml0IG51bWJlciB0aGF0 IGlzIHJlcXVpcmVkIHRvIGJlIGdsb2JhbGx5IHVuaXF1ZSB3aXRoaW4gYW4gUlRQIHNlc3Npb24u ICBJdCBpcyBjcnVjaWFsIHRoYXQgdGhlIG51bWJlciBiZSBjaG9zZW4gd2l0aCBjYXJlIGluIG9y ZGVyIHRoYXQgcGFydGljaXBhbnRzIG9uIHRoZSBzYW1lIG5ldHdvcmsgb3Igc3RhcnRpbmcgYXQg dGhlIHNhbWUgdGltZSBhcmUgbm90IGxpa2VseSB0byBjaG9vc2UgdGhlIHNhbWUgbnVtYmVyLiBH dWlkZWxpbmVzIHJlZ2FyZGluZyBTU1JDIHZhbHVlIHNlbGVjdGlvbiBhbmQgY29uZmxpY3QgcmVz b2x1dGlvbiBhcmUgcHJvdmlkZWQgaW4gW1JGQzM1NTBdLg0KDQpUaGUgU1NSQyBtYXkgYWxzbyBi ZSB1c2VkIHRvIHNlcGFyYXRlIGRpZmZlcmVudCBzb3VyY2VzIG9mIG1lZGlhIHdpdGhpbiBhIHNp bmdsZSBSVFAgc2Vzc2lvbi4gRm9yIHRoaXMgcmVhc29uIGFzIHdlbGwgYXMgZm9yIGNvbmZsaWN0 IHJlc29sdXRpb24sIGl0IGlzIGltcG9ydGFudCB0aGF0IHRoZSBTUkMgYW5kIFNSQyBoYW5kbGUg Y2hhbmdlcyBpbiBTU1JDIHZhbHVlcyBhbmQgcHJvcGVybHkgaWRlbnRpZnkgdGhlIHJlYXNvbiBv ZiB0aGUgY2hhbmdlLiBUaGUgQ05BTUUgdmFsdWVzIGNhcnJpZWQgaW4gUlRDUCBmYWNpbGl0YXRl IHRoaXMgaWRlbnRpZmljYXRpb24uDQoNCg0KKDYpIENTUkMNCg0KVGhlIGNvbnRyaWJ1dGluZyBz b3VyY2UgKENTUkMpLCBhcyBkZWZpbmVkIGluIFtSRkMzNTUwXSwgaWRlbnRpZmllcyB0aGUgc291 cmNlIG9mIGEgc3RyZWFtIG9mIFJUUCBwYWNrZXRzIHRoYXQgaGFzIGNvbnRyaWJ1dGVkIHRvIHRo ZSBjb21iaW5lZCBzdHJlYW0gcHJvZHVjZWQgYnkgYW4gUlRQIG1peGVyLiBUaGUgbWl4ZXIgaW5z ZXJ0cyBhIGxpc3Qgb2YgdGhlIFNTUkMgaWRlbnRpZmllcnMgb2YgdGhlIHNvdXJjZXMgdGhhdCBj b250cmlidXRlZCB0byB0aGUgZ2VuZXJhdGlvbiBvZiBhIHBhcnRpY3VsYXIgcGFja2V0IGludG8g dGhlIA0KUlRQIGhlYWRlciBvZiB0aGF0IHBhY2tldC4gVGhpcyBsaXN0IGlzIGNhbGxlZCB0aGUg Q1NSQyBsaXN0LiBJdCBpcyByZWNvbW1lbmRlZCB0aGF0IGEgU1JDLCB3aGVuIGFjdGluZyBhIG1p eGVyLCBzZXRzIHRoZSBDU1JDIGxpc3QgYWNjb3JkaW5nbHksIGFuZCB0aGF0IHRoZSBTUlMgaW50 ZXJwcmV0cyB0aGUgQ1NSQyBsaXN0IGFwcHJvcHJpYXRlbHkgd2hlbiByZWNlaXZlZC4NCg0KDQoo NykgU0RFUw0KDQpUaGUgU291cmNlIERlc2NyaXB0aW9uIChTREVTKSwgYXMgZGVmaW5lZCBpbiBb UkZDMzU1MF0sIGNvbnRhaW5zIGFuIFNTUkMvQ1NSQyBpZGVudGlmaWVyIGZvbGxvd2VkIGJ5IGEg bGlzdCBvZiB6ZXJvIG9yIG1vcmUgaXRlbXMsIHdoaWNoIGNhcnJ5IGluZm9ybWF0aW9uIGFib3V0 IHRoZSBTU1JDL0NTUkMuIEVuZCBzeXN0ZW1zIHNlbmQgb25lIFNERVMgcGFja2V0IGNvbnRhaW5p bmcgdGhlaXIgb3duIHNvdXJjZSBpZGVudGlmaWVyICh0aGUgc2FtZSBhcyB0aGUgU1NSQyBpbiB0 aGUgZml4ZWQgUlRQIGhlYWRlcikuICBBIG1peGVyIHNlbmRzIG9uZSBTREVTIHBhY2tldCBjb250 YWluaW5nIGEgY2h1bmsgZm9yIGVhY2ggY29udHJpYnV0aW5nIHNvdXJjZSBmcm9tIHdoaWNoIGl0 IGlzIHJlY2VpdmluZyBTREVTIGluZm9ybWF0aW9uLCBvciBtdWx0aXBsZSBjb21wbGV0ZSBTREVT IHBhY2tldHMuDQoNCg0KKDgpIENOQU1FDQoNClRoZSBDYW5vbmljYWwgRW5kLVBvaW50IElkZW50 aWZpZXIgKENOQU1FKSwgYXMgZGVmaW5lZCBpbiBbUkZDMzU1MF0sIHByb3ZpZGUgdGhlIGJpbmRp bmcgZnJvbSB0aGUgU1NSQyAgaWRlbnRpZmllciB0byBhbiBpZGVudGlmaWVyIGZvciB0aGUgc291 cmNlIChzZW5kZXIgb3IgcmVjZWl2ZXIpICB0aGF0IHJlbWFpbnMgY29uc3RhbnQuIEl0IGlzIGlt cG9ydGFudCB0aGUgYW4gU1JDIGFuZCBTUlMgZ2VuZXJhdGUgQ05BTUVzIGFwcHJvcHJpYXRlbHkg YW5kIHVzZSB0aGVtIGZvciB0aGlzIHB1cnBvc2UuIEd1aWRlbGluZXMgZm9yIGdlbmVyYXRpbmcg Q05BTUUgdmFsdWVzIGFyZSBwcm92aWRlZCBpbiAiR3VpZGVsaW5lcyBmb3IgQ2hvb3NpbmcgUlRQ IENvbnRyb2wgUHJvdG9jb2wgKFJUQ1ApIENhbm9uaWNhbCBOYW1lcyAoQ05BTUVzKSIgW1JGQzYy MjJdLg0KDQoNCig5KSBLZWVwYWxpdmUNCg0KSXQgaXMgYW50aWNpcGF0ZWQgdGhhdCBtZWRpYSBz dHJlYW1zIGluIFNJUFJFQyBtYXkgZXhpc3QgaW4gaW5hY3RpdmUgc3RhdGVzIGZvciBleHRlbmRl ZCBwZXJpb2RzIG9mIHRpbWVzIGZvciBhbiBvZiBhIG51bWJlciBvZiB2YWxpZCByZWFzb25zLiBJ biBvcmRlciB0byB0aGUgYmluZGluZ3MgYW5kIGFueSBwaW5ob2xlcyBpbiBOQVRzL2ZpcmV3YWxs cyB0byByZW1haW4gYWN0aXZlIGR1cmluZyBzdWNoIGludGVydmFscywgaXQgaXMgcmVjb21tZW5k ZWQgdG8gZm9sbG93IHRoZSBrZWVwLWFsaXZlIHByb2NlZHVyZXMgaW4gIkFwcGxpY2F0aW9uIE1l Y2hhbmlzbSBmb3Iga2VlcGluZyBhbGl2ZSB0aGUgTmV0d29yayBBZGRyZXNzIFRyYW5zbGF0b3Ig KE5BVCkgbWFwcGluZ3MgYXNzb2NpYXRlZCB0byBSVFAvUlRDUCBmbG93cyIsIFtkcmFmdC1pZXRm LWF2dC1hcHAtcnRwLWtlZXBhbGl2ZV0gZm9yIGFsbCBSVFAgbWVkaWEgc3RyZWFtcy4gDQoNCg0K KDEwKSBSVENQIEZlZWRiYWNrIE1lc3NhZ2VzDQoNCiJDb2RlYyBDb250cm9sIE1lc3NhZ2VzIGlu IHRoZSBSVFAgQXVkaW8tVmlzdWFsIFByb2ZpbGUgd2l0aCBGZWVkYmFjayAoQVZQRikiIFtSRkMg NTEwNF0gc3BlY2lmaWVzIGV4dGVuc2lvbnMgdG8gdGhlIG1lc3NhZ2VzIGRlZmluZWQgaW4gQVZQ RiBbUkZDNDU4NV0uIFN1cHBvcnQgZm9yIGFuZCBwcm9wZXIgdXNhZ2Ugb2YgdGhlc2UgbWVzc2Fn ZXMgaXMgaW1wb3J0YW50IHRvIFNSQyBhbmQgU1JTIGltcGxlbWVudGF0aW9ucy4gTm90ZSB0aGF0 IHRoZXNlIG1lc3NhZ2VzIGFyZSBhcHBsaWNhYmxlIG9ubHkgd2hlbiB1c2luZyB0aGUgQVZGUCBv ciBTQVZQRiBSVFAgcHJvZmlsZXMuDQoNCg0KKDEwLjEpIEZ1bGwgSW50cmEgUmVxdWVzdCANCg0K QSBGdWxsIEludHJhIFJlcXVlc3QgKEZJUikgQ29tbWFuZCwgd2hlbiByZWNlaXZlZCBieSB0aGUg ZGVzaWduYXRlIG1lZGlhIA0Kc2VuZGVyLCByZXF1aXJlcyB0aGF0IHRoZSBtZWRpYSBzZW5kZXIg c2VuZHMgYSBEZWNvZGVyIFJlZnJlc2ggUG9pbnQgYXQgdGhlIGVhcmxpZXN0IG9wcG9ydHVuaXR5 LiBVc2luZyBhIGRlY29kZXIgcmVmcmVzaCBwb2ludCBpbXBsaWVzIHJlZnJhaW5pbmcgZnJvbSB1 c2luZyBhbnkgcGljdHVyZSBzZW50IHByaW9yIHRvIHRoYXQgcG9pbnQgYXMgYSByZWZlcmVuY2Ug Zm9yIHRoZSBlbmNvZGluZyBwcm9jZXNzIG9mIGFueSBzdWJzZXF1ZW50IHBpY3R1cmUgc2VudCBp biB0aGUgc3RyZWFtLg0KDQpEZWNvZGVyIHJlZnJlc2ggcG9pbnRzLCBlc3BlY2lhbGx5IEludHJh IG9yIElEUiBwaWN0dXJlcyBmb3IgSC4yNjQgdmlkZW8gDQpjb2RlY3MsIGFyZSBpbiBnZW5lcmFs IHNldmVyYWwgdGltZXMgbGFyZ2VyIGluIHNpemUgdGhhbiBwcmVkaWN0ZWQgcGljdHVyZXMuIFRo dXMsIGluIHNjZW5hcmlvcyBpbiB3aGljaCB0aGUgYXZhaWxhYmxlIGJpdCByYXRlIGlzIHNtYWxs LCB0aGUgdXNlIG9mIGEgZGVjb2RlciByZWZyZXNoIHBvaW50IGltcGxpZXMgYSBkZWxheSB0aGF0 IGlzIHNpZ25pZmljYW50bHkgbG9uZ2VyIHRoYW4gdGhlIHR5cGljYWwgcGljdHVyZSBkdXJhdGlv bi4NCg0KDQooMTAuMS4xKSBTSVAgSU5GTyBmb3IgRklSDQoNCiJYTUwgU2NoZW1hIGZvciBNZWRp YSBDb250cm9sIiBbUkZDNTE2OF0gZGVmaW5lcyBhbiBFeHRlbnNpYmxlIE1hcmt1cCBMYW5ndWFn ZSAoWE1MKSBTY2hlbWEgZm9yIHZpZGVvIGZhc3QgdXBkYXRlLiBJbXBsZW1lbnRhdGlvbnMgYXJl IGRpc2NvdXJhZ2VkIGZyb20gdXNpbmcgdGhlIG1ldGhvZCBkZXNjcmliZWQgZXhjZXB0IGZvciBi YWNrd2FyZCBjb21wYXRpYmlsaXR5IHB1cnBvc2VzLiBJbXBsZW1lbnRhdGlvbnMgc2hvdWxkIHVz ZSBGSVIgbWVzc2FnZXMsIGFzIGRlc2NyaWJlZCBpbiAoMTAuMSkgaW5zdGVhZC4NCg0KDQooMTAu MikgUGljdHVyZSBMb3NzIEluZGljYXRvcg0KVXNpbmcgdGhlIEZJUiBjb21tYW5kIHRvIHJlY292 ZXIgZnJvbSBlcnJvcnMgaXMgZXhwbGljaXRseSBkaXNhbGxvd2VkLCBhbmQgaW5zdGVhZCB0aGUg UExJIG1lc3NhZ2UgZGVmaW5lZCBpbiBBVlBGIFtSRkM0NTg1XSBzaG91bGQgYmUgdXNlZC4gVGhl IFBMSSBtZXNzYWdlIHJlcG9ydHMgbG9zdCBwaWN0dXJlcyBhbmQgaGFzIGJlZW4gaW5jbHVkZWQg aW4gQVZQRiBmb3IgcHJlY2lzZWx5IHRoYXQgcHVycG9zZS4NCg0KDQooMTAuMykgVGVtcG9yYXJ5 IE1heGltdW0gTWVkaWEgU3RyZWFtIEJpdCBSYXRlIFJlcXVlc3QNCg0KQSByZWNlaXZlciwgdHJh bnNsYXRvciwgb3IgbWl4ZXIgdXNlcyB0aGUgVGVtcG9yYXJ5IE1heGltdW0gTWVkaWEgU3RyZWFt IEJpdCBSYXRlIFJlcXVlc3QgKFRNTUJSKSB0byByZXF1ZXN0IGEgc2VuZGVyIHRvIGxpbWl0IHRo ZSBtYXhpbXVtIGJpdCByYXRlIGZvciBhIG1lZGlhIHN0cmVhbSB0byB0aGUgcHJvdmlkZWQgdmFs dWUuIEFwcHJvcHJpYXRlIHVzZSBvZiBUTU1CUiBmYWNpbGl0YXRlcyByYXBpZCBhZGFwdGF0aW9u IHRvIGNoYW5nZXMgaW4gYXZhaWxhYmxlIGJhbmR3aWR0aC4gDQoNCg0KKDEwLjMuMSkgUmVuZWdv dGlhdGlvbiBvZiBTRFAgYmFuZHdpZHRoIGF0dHJpYnV0ZQ0KDQpJZiBpdCBpcyBsaWtlbHkgdGhh dCB0aGUgbmV3IHZhbHVlIGluZGljYXRlZCBieSBUTU1CUiB3aWxsIGJlIHZhbGlkIGZvciB0aGUg cmVtYWluZGVyIG9mIHRoZSBzZXNzaW9uLCB0aGUgVE1NQlIgc2VuZGVyIGlzIGV4cGVjdGVkIHRv IHBlcmZvcm0gYSANCnJlbmVnb3RpYXRpb24gb2YgdGhlIHNlc3Npb24gdXBwZXIgbGltaXQgdXNp bmcgdGhlIHNlc3Npb24gc2lnbmFsaW5nIHByb3RvY29sLiBUaGVyZWZvcmUgZm9yIFNJUFJFQywg aW1wbGVtZW50YXRpb25zIGFyZSByZWNvbW1lbmRlZCB0byB1c2UgVE1NQlIgZm9yIHRlbXBvcmFy eSBjaGFuZ2VzLCBhbmQgcmVuZWdvdGlhdGlvbiBvZiBiYW5kd2lkdGggdmlhIFNEUCBvZmZlci9h bnN3ZXIgb2YgbW9yZSBwZXJtYW5lbnQgY2hhbmdlcy4NCg0KDQooMTEpIFN5bW1ldHJpYyBSVFAv UlRDUCBmb3IgU2VuZGluZyBhbmQgUmVjZWl2aW5nDQoNCldpdGhpbiB0aGUgU0RQIG9mZmVyL2Fu c3dlciwgUlRQIGVudGl0aWVzIGNob29zZSB0aGUgUlRQIGFuZCBSVENQIHRyYW5zcG9ydCBhZGRy ZXNzZXMgKGkuZS4sIElQIGFkZHJlc3NlcyBhbmQgcG9ydCBudW1iZXJzKSBvbiB3aGljaCB0byBy ZWNlaXZlIHBhY2tldHMuIFdoZW4gc2VuZGluZyBSVFAgcGFja2V0czsgaG93ZXZlciwgdGhleSBt YXkgdXNlIGEgZGlmZmVyZW50IElQIGFkZHJlc3Mgb3IgcG9ydCBudW1iZXIgZm9yIFJUUCwgUlRD UCwgb3IgYm90aC4gIFN5bW1ldHJpYyBSVFAvUlRDUCByZXF1aXJlcyB0aGF0IHRoZSBJUCBhZGRy ZXNzIGFuZCBwb3J0IG51bWJlciBmb3Igc2VuZGluZyBhbmQgcmVjZWl2aW5nIFJUUC9SVENQIHBh Y2tldHMgYXJlIGlkZW50aWNhbC4gVXNpbmcgU3ltbWV0cmljIFJUUCBhbmQgUlRDUCwgYXMgZGVm aW5lZCBpbiCTU3ltbWV0cmljIFJUUCAvIFJUUCBDb250cm9sIFByb3RvY29sIChSVENQKZQgW1JG QzQ5NjFdIGlzIHJlY29tbWVuZGVkLiBJdCBzaG91bGQgbm90IGJlIGNvbmZ1c2VkIHdpdGgsIG9y IHVzZWQgaW4gcGxhY2Ugb2YsIJNNdWx0aXBsZXhpbmcgUlRQIERhdGEgYW5kIENvbnRyb2wgUGFj a2V0cyBvbiBhIFNpbmdsZSBQb3J0lCBbUkZDNTc2MV0uDQo= ------_=_NextPart_001_01CC0C45.1A8172A8-- From pkyzivat@cisco.com Fri May 6 16:29:19 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA9C7E06A3 for ; Fri, 6 May 2011 16:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.422 X-Spam-Level: X-Spam-Status: No, score=-110.422 tagged_above=-999 required=5 tests=[AWL=0.177, 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 vpdB6y+579Qt for ; Fri, 6 May 2011 16:29:18 -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 B0923E069A for ; Fri, 6 May 2011 16:29:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=1476; q=dns/txt; s=iport; t=1304724558; x=1305934158; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=G3sPXWaNcZTmzi5Qbi8/08q183UtNrfFA4q3aFyT1nM=; b=XLmxddpy0PiDh82iVjDE9N5kvsp0an3lBSe0jaRPsu9gMWg4OlLGe+4l oRNQ/bq0GzSOuW/X4EhXl/96uRfkkNJFN5OoSnOkro9k9Q8AbqRVFq9XT k31BObhZmi1DXovg+uNPZfgEkjn9qzNPckzXBoRf1nnXPc/v6YNcCf807 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQHAB+ExE2tJV2b/2dsb2JhbACYM41rd4hxnnuddoYJBI9YhCSKTA X-IronPort-AV: E=Sophos;i="4.64,329,1301875200"; d="scan'208";a="693458358" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by sj-iport-6.cisco.com with ESMTP; 06 May 2011 23:29:18 +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 p46NTHM9022334 for ; Fri, 6 May 2011 23:29:17 GMT Message-ID: <4DC4844D.6010003@cisco.com> Date: Fri, 06 May 2011 19:29:17 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: siprec@ietf.org References: <059AF07365DC474393A19A3AF187DF7407028E4B@NAHALD.us.int.genesyslab.com> <059AF07365DC474393A19A3AF187DF74070292B2@NAHALD.us.int.genesyslab.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] RTP Recommendations (was RE: summary of changes for draft-portman-siprec-protocol-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: Fri, 06 May 2011 23:29:19 -0000 Charles, John, On 5/6/2011 6:24 PM, Charles Eckel (eckelcu) wrote: > I always felt RTCP was required as well, but when challenged on that, I > was not able to see where in RFC 3550 it is stated as mandatory. Looking > more closely at RFC 3550, I think the following text in section 6 does > mandate RTCP, "The first two functions require that all participants > send RTCP packets, therefore the rate must be controlled in order for > RTP to scale up to a large number of participants." > Armed with this, I agree completely with your comment. For now, I will > update that, and we can decide later if it simply want to remove that > section as unnecessary. Disclaimers: 1) I know almost no details of RTP. 2) I've no axe to grind here one way or the other I was curious and so I looked at the referenced section of 3550, just parsing it as a standards lawyer. There a no normative terms in bullets 1-4 of Section 6. The paragraph after them applies normative terms to them: Functions 1-3 SHOULD be used in all environments, but particularly in the IP multicast environment. ... I think that makes 1 & 2 non-required. The statement Charles quotes asserts that 1 & 2 require sending RTCP. But that is only meaningful *if* you are implementing 1 & 2, which is optional. So, legalistically, it appears to me that use of RTCP can inferred to be only SHOULD strength, especially in a unicast environment. Thanks, Paul From pkyzivat@cisco.com Fri May 6 16:48:10 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20C8BE069A for ; Fri, 6 May 2011 16:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.529 X-Spam-Level: X-Spam-Status: No, score=-109.529 tagged_above=-999 required=5 tests=[AWL=-0.730, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LOu9+GTNXFfx for ; Fri, 6 May 2011 16:48:07 -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 6FB6FE064B for ; Fri, 6 May 2011 16:48:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=35324; q=dns/txt; s=iport; t=1304725686; x=1305935286; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=TGNzhCmotE/QYEJG9G8g3r06LhF/HQ4OyeAVVfvE/Dg=; b=XrHWLoy82pZZTY/eR+OPZkRupvAfjU6DxK0//1cSBVouP9jTOZ3hCvno MZ029HIN6O40Q2zBnBLSqY0Tr+RQxnyX62GRYI9HEz31SQHHrdDDogKUt J3JyF+MOpUUJK8ljR+XRcNNPBoyULtju5apvJZw/V57q/PKyPbctBjTEF E=; X-IronPort-AV: E=Sophos;i="4.64,329,1301875200"; d="scan'208";a="29054274" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 06 May 2011 23:48:05 +0000 Received: from [161.44.174.124] (dhcp-161-44-174-124.cisco.com [161.44.174.124]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p46Nm4kX006274; Fri, 6 May 2011 23:48:04 GMT Message-ID: <4DC488B4.2020705@cisco.com> Date: Fri, 06 May 2011 19:48:04 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Charles Eckel (eckelcu)" References: <4DC31AC4.9030309@cisco.com> <4DC3E53E.9050202@cisco.com> <4DC469EF.6040705@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: Fri, 06 May 2011 23:48:10 -0000 On 5/6/2011 6:56 PM, Charles Eckel (eckelcu) wrote: > If the participant generates its own ID instead, it could represent > itself the same for all instances that it wants correlated. This could > be a To/From URI, or a P-Asserted-Identity URI. There would have to be agreement on what it is that identifies the scope of uniqueness. And IIUC, you are saying two or more SRCs might choose to operate within the same identity scope by providing the same "SRC identity". That probably means it couldn't be to/from/paid, because that would limit those who could be in the same group. So lets assume for a moment that it is some other, globally unique id that is provided by the SRC to the SRS, and which the SRS would then have to couple with the other ids to make them unique in its db. So what you have arrived at is a globally unique id. All you have done is changed the wire encoding. If, in any given RS, the SRC is limited to referencing ids within the one SRC-id it has provided for that RS, then you have partitioned the SRS db into subdomains based on the SRC-id, without any possibility of an SRC reaching across the domain boundaries. You could fix that by allowing the src to explicitly provide a different src-id with a specific id-reference, perhaps as an optional field. But at that point you again actually have globally unique ids, with perhaps a coding efficiency. (Or maybe not - it might be worse.) > It will not work in all > cases, but it could in some. If I understand your point correctly, an > SRC/SRS could still use some metadata to achieve this same thing, and I don't quite understand what you are saying. > having globally unique participant IDs enables having other mechanisms, > outside the scope of SIPREC, that do not rely on endpoints to represent > themselves in a consistent fashion. Do I have it straight now? There are a lot of things that we care about in siprec that are out of scope. For instance querying the data we are writing. (A write-only db isn't really very interesting.) IMO this is a decision where if we limit this now it will be hard to fix in the future. We don't need to be designing the mechanism for sharing these ids in order to imagine that somebody will want to. Thanks, Paul > Thanks, > Charles > >> -----Original Message----- >> From: Paul Kyzivat (pkyzivat) >> Sent: Friday, May 06, 2011 2:37 PM >> To: Charles Eckel (eckelcu) >> Cc: Elwell, John; Parthasarathi R (partr); siprec@ietf.org; Peter > Saint-Andre (psaintan); Joe >> Hildebrand (jhildebr); Hadriel Kaplan >> Subject: Re: [siprec] Partial updates and identifiers >> >> Charles, >> >> On 5/6/2011 1:04 PM, Charles Eckel (eckelcu) wrote: >>> The reason I brought this up was in response to Partha's assertion > that >>> participant IDs need to be globally unique rather than unique within > a >>> given CS, RS, or recording. The point I was trying to make was that > an >>> SRS might actually want a way to correlate participants, either by >>> participant ID or some other metadata or some mechanism outside the >>> scope of SIPREC. While this is still possible with globally unique >>> participant IDs, it is made more difficult. >> >> ??? >> >> How? Having globally unique ones makes it *possible* for more than one >> src to reference the same one. If the SRS wants to correlate ones that >> are different, how does this make it more difficult? >> >>> So in this case, mandating >>> that participant IDs be globally unique make things more >>> complex/difficult. Why are globally unique participant IDs across > all >>> CSs and RSs required? That is what I am trying to understand. >>> They is some cost associated with this, and I want to make sure the > cost >>> is warranted. >> >> As noted above, being globally unique means that two different SRCs > that >> find a way of discovering each others ids MAY then reference/reuse > them. >> >> If the ids are instead *locally* unique to an SRC, then the SRS still >> has to make them globally unique if it stores in common the data from >> multiple SRCs. (It can do that by prefixing the src-local id with a > uid >> for the SRC.) But that has its own problems. >> >> In that environment if src1 knows and wants to reference an id > generated >> by src2, it can't do so unless there is a way for src1 to include an > id >> like src2:id. And if we allow that we are back to globally unique ids > - >> just of a different format. Or else you just can't cross reference at > all. >> >> Another issue with this is that if the ids are not globally unique, > then >> *exactly* what is the scope in which they *are* unique. For the SRS to >> understand them properly that must be nailed down. Once you get beyond > a >> single RS session, there starts to be uncertainty whether two RSs >> involved the same SRC or different ones. Of course we could solve that >> by requiring the SRC to provide a globally unique id for itself, and >> other ids that are unique within the scope of that one. But that is >> again just a different way of encoding globally unique ids. >> >> Thanks, >> Paul >> >>> Cheers, >>> Charles >>> >>>> -----Original Message----- >>>> From: Paul Kyzivat (pkyzivat) >>>> Sent: Friday, May 06, 2011 5:11 AM >>>> To: Elwell, John >>>> Cc: Charles Eckel (eckelcu); Parthasarathi R (partr); > siprec@ietf.org; >>> Peter Saint-Andre (psaintan); >>>> Joe Hildebrand (jhildebr); Hadriel Kaplan >>>> Subject: Re: [siprec] Partial updates and identifiers >>>> >>>> John, >>>> >>>> I think we are in agreement. My point was that some SRCs may be >>> smarter >>>> about this than others. If they are able to figure out when to > reuse >>> the >>>> same participant id, then that is great, but not required. >>>> >>>> (Of course they must not reuse the same participant id *by > accident*.) >>>> >>>> Thanks, >>>> Paul >>>> >>>> On 5/6/2011 3:14 AM, Elwell, John wrote: >>>>> When is a participant the same participant and when is it > different? >>> I call into a conference from >>>> my desk phone. I later drop out and then call in again to the same >>> conference from my cell phone. The >>>> conference is being recorded. In this case it is unlikely that the > SRC >>> will have any information to >>>> correlate the new caller with the caller who dropped out, unless > they >>> happen to share the same SIP >>>> AOR. >>>>> >>>>> I think it is fine for participants to be assigned new IDs each > time >>> they join a call or participate >>>> in different calls / different recordings. If other attributes of > the >>> Participant object can be used >>>> to correlate two different Participant IDs (e.g., the same SIP > AoR), >>> this can be made use of. >>>> Otherwise they are treated as different participants, even though > it >>> might be the same person. >>>>> >>>>> John (as individual) >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>>> Sent: 05 May 2011 22:47 >>>>>> To: Charles Eckel (eckelcu) >>>>>> Cc: Parthasarathi R (partr); Elwell, John; siprec@ietf.org; >>>>>> Peter Saint-Andre (psaintan); Joe Hildebrand (jhildebr); >>>>>> Hadriel Kaplan >>>>>> Subject: Re: [siprec] Partial updates and identifiers >>>>>> >>>>>> >>>>>> >>>>>> On 5/5/2011 1:10 PM, Charles Eckel (eckelcu) wrote: >>>>>>> I follow the logic, but let me run through a simple use case. >>>>>>> >>>>>>> 0) I am on a call that is part of a recording. Initially, this > is >>>>>>> through CS1 which results in RS1, which is part of recording X. > My >>>>>>> unique participant ID is p0. >>>>>>> >>>>>>> I drop off and call back in. I need to be brought back into the >>> same >>>>>>> recording X. Possible scenarios are: >>>>>>> >>>>>>> 1) I call back into CS1, and am added into recording X >>>>>> through RS1. My >>>>>>> unique participant ID is p1? >>>>>> >>>>>> Maybe. It depends on whether the SRC recognizes you as the same >>>>>> participant and remembers that it had assigned p1 to you. >>>>>> If not, then you will presumably appear as a new participant. >>>>>> >>>>>>> 2) I call into CS2, and am added to recording X through >>>>>> RS1. My unique >>>>>>> participant ID is p2? >>>>>> >>>>>> Pretty much the same answer as above. >>>>>> >>>>>> Its also up to the SRC to decide if this is part of CS1 or CS2. >>>>>> >>>>>>> 3) I call into CS2, and am added to recording X through >>>>>> RS2. My unique >>>>>>> participant ID is p3? >>>>>> >>>>>> Pretty much the same again. If it is the same SRC, and has >>>>>> some history >>>>>> to figure out what is going on, it can continue to use p1. >>>>>> >>>>>> If it is a different SRC, then its more of a challenge. There >>>>>> would have >>>>>> to be some sharing of info between the two for the new SRC to >>> recover >>>>>> the old p1. More likely you will get a new p3. >>>>>> >>>>>>> If the SRS is able to make use of some other metadata to >>>>>> realize that >>>>>>> p0=p1=p2=p3, great, if not, they look like different > participants. >>>>>> >>>>>> Yes, if the p(i) are different the SRS could still attempt >>>>>> correlation, >>>>>> but its outside our current scope. >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>>> Cheers, >>>>>>> Charles >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Parthasarathi R (partr) >>>>>>>> Sent: Tuesday, May 03, 2011 9:46 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 >>>>>>>> >>>>>>>> Hi Charles, >>>>>>>> >>>>>>>> In case participants id has to be unique for single RS >>>>>> with multiple >>>>>>> CS as you mentioned below mail >>>>>>>> and also, participant id has to be unique within single CS >>>>>> which span >>>>>>> across multiple RS (start& stop >>>>>>>> of recording within CS scenario), then participant unique >>>>>> id needs to >>>>>>> be global (URN UUID) rather than >>>>>>>> local id like xml:id. Please let me know in case you have any >>> other >>>>>>> opinion on the same. >>>>>>>> >>>>>>>> Thanks >>>>>>>> Partha >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Charles Eckel (eckelcu) >>>>>>>> Sent: Wednesday, April 20, 2011 2:54 AM >>>>>>>> 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 >>>>>>>> >>>>>>>> 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 >>>>>>>>> >>>>>>>>> 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? >>>>>>>>> >>>>>>>>> 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 krehor@cisco.com Sat May 7 09:33:34 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB50E06FF for ; Sat, 7 May 2011 09:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.546 X-Spam-Level: X-Spam-Status: No, score=-9.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, RCVD_IN_DNSWL_HI=-8, 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 lopQSuAgH22d for ; Sat, 7 May 2011 09:33:33 -0700 (PDT) Received: from sj-iport-1.cisco.com (unknown [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 55D21E06F0 for ; Sat, 7 May 2011 09:33:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=krehor@cisco.com; l=3077; q=dns/txt; s=iport; t=1304786013; x=1305995613; h=mime-version:subject:date:message-id:from:to; bh=DUEXOW4JgKAvfDO4ITSuBTZvQQlGmeblFQXNkyv46NY=; b=QPWSYvV+qUP9hkhlttkltktNwYaLosvP2ewCZ8SJ4hv3WN0b+qQwWedU P67P4+VbX8D7/kIJpYCZZuEeNk1PblCwELpwXqf1ELRmVaGXPV2s6KBsW bJduEg6ms26fO5cc2R+cNiC1ssUMPbnXFCU7b79yEo/fHbE+8lLSJMgdF w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisJAKlzxU2rRDoJ/2dsb2JhbACCY5VQhiwThzN3pRmBHZ0zhgwEhkCNVopM X-IronPort-AV: E=Sophos;i="4.64,331,1301875200"; d="scan'208,217";a="443582787" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-1.cisco.com with ESMTP; 07 May 2011 16:33:33 +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 p47GXWa5017879 for ; Sat, 7 May 2011 16:33:33 GMT Received: from xmb-sjc-22e.amer.cisco.com ([128.107.191.115]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 7 May 2011 09:33:32 -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_01CC0CD4.811BB2F7" Date: Sat, 7 May 2011 09:33:30 -0700 Message-ID: <7744FE52C78D944587F03773EB4514610A1836FC@xmb-sjc-22e.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Interim meeting schedule and slides posted Thread-Index: AcwM1H9JeeVVgvsdTgW2geDv7IGNUg== From: "Ken Rehor (krehor)" To: X-OriginalArrivalTime: 07 May 2011 16:33:32.0902 (UTC) FILETIME=[81503860:01CC0CD4] Subject: [siprec] Interim meeting schedule and slides posted X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 07 May 2011 16:33:34 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC0CD4.811BB2F7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The meeting agenda, WebEx details and slides have been updated at http://kenrehor.com/ietf/siprec/ =20 Ken =20 For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html =20 ------_=_NextPart_001_01CC0CD4.811BB2F7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The meeting = agenda, WebEx details and slides have been updated at http://kenrehor.com/ietf/siprec= /

 

Ken

 

For corporate = legal information go = to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html=

 

------_=_NextPart_001_01CC0CD4.811BB2F7-- From john.elwell@siemens-enterprise.com Sun May 8 01:53:38 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23180E06B4 for ; Sun, 8 May 2011 01:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.312 X-Spam-Level: X-Spam-Status: No, score=-105.312 tagged_above=-999 required=5 tests=[AWL=1.287, 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 HYC4uno1piZl for ; Sun, 8 May 2011 01:53:37 -0700 (PDT) Received: from mail174.messagelabs.com (mail174.messagelabs.com [85.158.138.51]) by ietfa.amsl.com (Postfix) with SMTP id C1339E0681 for ; Sun, 8 May 2011 01:53:35 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-2.tower-174.messagelabs.com!1304844814!19108342!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 11287 invoked from network); 8 May 2011 08:53:34 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-2.tower-174.messagelabs.com with SMTP; 8 May 2011 08:53:34 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 4304A23F03DB for ; Sun, 8 May 2011 10:53:34 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Sun, 8 May 2011 10:53:34 +0200 From: "Elwell, John" To: "siprec@ietf.org" Date: Sun, 8 May 2011 10:53:32 +0200 Thread-Topic: Interim call reminder Thread-Index: AcwNXWjeqXCvPSlETR+Klxr3PQwuAA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] Interim call reminder X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 08 May 2011 08:53:38 -0000 The interim call is Monday 14.00-16.00 GMT/UTC. Webex details are available here: http://kenrehor.com/ietf/siprec/IETF80.1/ Updated agenda and slides will also be posted there shortly. The revised agenda is: Administrivia Note Takers Participant list Note Well Agenda bash none 10 min chairs Architecture https://datatracker.ietf.org/doc/draft-ietf-siprec-architectur= e/=20 5 min Andy Hutton RTP model - proposed text 15 min Charles Eckel / Andy Hutton Metadata model https://datatracker.ietf.org/doc/draft-ietf-siprec-metadata/= =20 35 min Ram Ravindranath / Parthasarathi Ravindran Metadata format https://datatracker.ietf.org/doc/draft-ram-siprec-metadata-= format/=20 35 min Ram Ravindranath / Parthasarathi Ravindran Protocol https://datatracker.ietf.org/doc/draft-portman-siprec-protocol/=20 15 min Leon Portman Wrap-up - Hums and Next Steps 5 min chairs John= From partr@cisco.com Sun May 8 20:45:56 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 8FFDBE0684 for ; Sun, 8 May 2011 20:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.196 X-Spam-Level: X-Spam-Status: No, score=-10.196 tagged_above=-999 required=5 tests=[AWL=0.403, 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 04YMVQXWoztz for ; Sun, 8 May 2011 20:45:55 -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 AC688E067A for ; Sun, 8 May 2011 20:45:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=8516; q=dns/txt; s=iport; t=1304912754; x=1306122354; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=iMavpe7nyQljHBgc+JEXoF134cdV4spaOjcXOZEN6qY=; b=fj5Qu7/cFXuRPz3ZbdHkPBM1CweboY6Cc6PmnHTHQPLax/9dG02wKSFu 1K2lcU6WWv+v6UW9VsGHcMqwr2J9kYmlRMLks8AG/pSrZcBKdF1i9kjz+ tBzy4gzHg6yrZHaI/NwhbV0MyUu1RRBNY5Mw2yvMDoZ1QyO3ZQaWLb2Sa Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0BAJhix02Q/khMgWdsb2JhbACXUI4yFAEBFiYliHGeM5x9hgwEhj6NWIo0 X-IronPort-AV: E=Sophos;i="4.64,338,1301875200"; d="scan'208";a="29226044" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 09 May 2011 03:45:53 +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 p493j6JA012656; Mon, 9 May 2011 03:45:53 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, 9 May 2011 09:15: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: Mon, 9 May 2011 09:15:11 +0530 Message-ID: In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E30B6D880650@MCHP058A.global-ad.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] I-D Action:draft-ietf-siprec-architecture-02.txt Thread-Index: Acv54yOePwZLBlTgQPChIkDA4jWhawPDzBjgAIcZ5bAADbLfIAACOYzAAKrHZKA= References: <20110413140001.12509.2089.idtracker@ietfc.amsl.com> <101C6067BEC68246B0C3F6843BCCC1E30B6D880494@MCHP058A.global-ad.net> <101C6067BEC68246B0C3F6843BCCC1E30B6D880650@MCHP058A.global-ad.net> From: "Parthasarathi R (partr)" To: "Hutton, Andrew" , X-OriginalArrivalTime: 09 May 2011 03:45:13.0501 (UTC) FILETIME=[80C15CD0:01CC0DFB] Subject: Re: [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: Mon, 09 May 2011 03:45:56 -0000 Andy, I wrongly thought of CS may be any signaling protocol (Jingle, PSTN) based on earlier mailer discussion and provided the example which is outside the scope of SIPREC. I'll provide the use case which is within SIPREC now: A + SRC--------------B | -----------------SRS In the above topology, A & B are acting as UA. The scenario is as follows: 1) B starts INVITE (CS) towards A by acting as "uac" 2) A receives INVITE (CS) and act as "uas" 3) A sends response towards B which is a normal SIP UA behavior and apart from this, A (SRC) has to send INVITE (RS) towards SRS by acting as "uac". My point here is that A acts as kind of B2BUA rather than simple UA but current architecture depicts as UA. By introducing the decomposition within SRC, it will be clear that A acts as uas towards B and A acts as uac towards SRS and two instance of UA involved in each SRC session. Let us discuss in detail during today's meeting. Thanks Partha =20 -----Original Message----- From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com]=20 Sent: Thursday, May 05, 2011 11:39 PM To: Parthasarathi R (partr); siprec@ietf.org Subject: RE: [siprec] I-D Action:draft-ietf-siprec-architecture-02.txt Hi Partha, Of course it could be that the SRC is recording something other than a SIP session and using SIPREC with the SRS. However for the purposes of SIPREC the definiton of the CS is as follows: "Communication Session (CS): A SIP session created between two or more UA's for the purpose of communication which may be recorded." Therefore I believe your scenario is out of scope and should not be covered in the architecture draft. I noticed a slight difference between the architecture and requirements draft on the definition but it is only in the wording and both state that it is a SIP session. Regards Andy =20 > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > Sent: 05 May 2011 18:06 > To: Hutton, Andrew; siprec@ietf.org > Subject: RE: [siprec] I-D Action:draft-ietf-siprec-architecture-02.txt >=20 > Hi Andy, >=20 > Let me explain with simple SRC examples for the need of this=20 > decomposition. >=20 > SRC is non-SIP entity namely H.323 gateway which has SIP UA for=20 > recording purpose only. CS of SRC is H.323 session whereas RS is SIP=20 > session. In these scenario, the architecture has to mention both H.323 > gateway, SIP UA combination as SRC instead of mere H.323 gateway as=20 > SRC. >=20 >=20 > In case you foresee more discussion required, let us discuss on=20 > interim meeting. >=20 > Thanks > Partha >=20 > -----Original Message----- > From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com] > Sent: Thursday, May 05, 2011 7:41 PM > To: Parthasarathi R (partr); siprec@ietf.org > Subject: RE: [siprec] I-D Action:draft-ietf-siprec-architecture-02.txt >=20 > Hi Partha, >=20 > I don't understand the need for showing the decomposition of the SRC=20 > in this way. The current figures in the architecture document are=20 > there to help explain the relationship to Mediactrl but I don't see=20 > the value in this change. >=20 > It also appears to incorrectly show the SIP based Communication=20 > Session terminating at the MediaCtrl application server. >=20 > Maybe we could discuss why you think we need this in the interim next=20 > week. >=20 > Regards > Andy =20 > =20 >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi > R (partr) > > Sent: 02 May 2011 19:22 > > To: siprec@ietf.org > > Subject: Re: [siprec] I-D > Action:draft-ietf-siprec-architecture-02.txt > >=20 > > As part of the discussion about Metadata and RTP model with lot of=20 > > folks, I realized that it is better to show "UA instance" which is=20 > > associated with SRC to create RS as a separate instance. > Fig 4 in the > > draft shall be updated as > >=20 > > Session Recording > Server (SRS) > > +----------+ > > (Recording Session) | | > > +-----------SIP------------------------->| UA-A | > > | | (SRS) | > > | +----------+ > > | Session Recording Client (SRC) | > > +----------------------------------------+ | > > | +-----------+ | | > > | | Session | +------------+ | | > > | | Recording | | | | | =20 > > +---------+ > > | | UA | | Media | | <--RTP--+ |=20 > > | > > | +-----------+ | | | |=20 > > | > > | ^ | | | |=20 > > | > > | | | | | |=20 > > | > >=20 > > | V | | | |=20 > > | > > | +-----------+ | Server | | |=20 > > UA-B | > > | | MediaCtrl |MEDIACTRL | |<-----RTP------>|=20 > > | > > | |Application|<-------->| | | =20 > > +---------+ > > | | Server | +------------+ | ^ > > | +-----------+ | | > > +--------^-------------------------------+ | > > | | > > +-----------------------SIP-------------------------+ > > (Communication Session) > >=20 > > Figure 4: Example of Session Recording Client using=20 > > MEDIACTRL > >=20 > > Here in the above figure, session recording UA is a separate UA=20 > > instance apart from CS creating UA (Mediactrl application server)=20 > > instance. > > Cooridination between Session Recording UA and Mediactrl > application > > server is outside the scope of SIPREC. The same logical > figure shall > > be extended to other SRC architecture figure by which the > importance > > of SIP based RS UA with non-sip CS is clear. Please let me know=20 > > opinion on the same. > >=20 > > Thanks > > Partha > >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf Of > Internet-Drafts@ietf.org > > Sent: Wednesday, April 13, 2011 7:30 PM > > To: i-d-announce@ietf.org > > Cc: siprec@ietf.org > > Subject: [siprec] I-D Action:draft-ietf-siprec-architecture-02.txt > >=20 > > A New Internet-Draft is available from the on-line Internet-Drafts=20 > > directories. > > This draft is a work item of the SIP Recording Working Group of the=20 > > IETF. > >=20 > >=20 > > 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 > >=20 > > Session recording is a critical requirement in many communications=20 > > environments such as call centers and financial trading. > In some of > > these environments, all calls must be recorded for regulatory,=20 > > compliance, and consumer protection reasons. Recording of > a session > > is typically performed by sending a copy of a media stream to a=20 > > recording device. This document describes architectures > for deploying >=20 > > session recording solutions in an environment which is based on the=20 > > Session Initiation Protocol (SIP). > >=20 > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-siprec-architec > ture-02.tx > > t > >=20 > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > >=20 > > Below is the data which will enable a MIME compliant mail reader=20 > > implementation to automatically retrieve the ASCII version of the=20 > > Internet-Draft. > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > >=20 >=20 From eckelcu@cisco.com Mon May 9 16:10:51 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3F55E0771 for ; Mon, 9 May 2011 16:10:51 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MsR2x5sdmtLZ for ; Mon, 9 May 2011 16:10:50 -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 32EF3E06E1 for ; Mon, 9 May 2011 16:10:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=2227; q=dns/txt; s=iport; t=1304982650; x=1306192250; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=kIZB4rb1SN3G5xtFmcRNIpzl+/LHlge1ofmzS10HYy0=; b=YUBtTyAQgYCbuAbnC+NZ3WWnBvsqSYzVujiCMQGAdd9VpIaHflU2Pim2 2NZ1HOg1XGZECrQNCmkXljehbnCoABSA1L0ifySc6AGkoPXQpIAutCekb cC8gU0sdAFVRTR0szIM4mmspXjtg/XkdOHu4il/yQNKD+RrWmBHG7Z+0j 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMIAPlyyE2rRDoJ/2dsb2JhbACYEo1vd6cOgR2eNIYMBIZAjVWKTQ X-IronPort-AV: E=Sophos;i="4.64,342,1301875200"; d="scan'208";a="444560656" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-1.cisco.com with ESMTP; 09 May 2011 23:10:49 +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 p49NAnlp004803 for ; Mon, 9 May 2011 23:10:49 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, 9 May 2011 16:10:49 -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, 9 May 2011 16:10:48 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RS Group / Recording Object issue from interim meeting Thread-Index: AcwOnlUD796ZsvbMTUylbGle0/maUw== From: "Charles Eckel (eckelcu)" To: X-OriginalArrivalTime: 09 May 2011 23:10:49.0322 (UTC) FILETIME=[55C0C4A0:01CC0E9E] Subject: [siprec] RS Group / Recording Object issue from 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: Mon, 09 May 2011 23:10:51 -0000 I am attempting to summarize the discussion we had around this issue, and provide what I understood to be the accepted proposal. First, let me settle on a single term. The term RS Group will be used to mean a collection of RS elements that comprise a single recording. For example, RS1 and RS2 may be two independent sessions that together form a single recording. In such a case, the media streams associated with RS1 and RS2 are combined into a single recording. Question1: Do we need an RS Group element within the metadata model? Question2: If the answer to Q1 is no, do we need an RS element in the metadata model? Use Cases: t0: UA1 and UA2 establish CS1, and SRC1, which may be co-located with UA1 or UA2 or may be somewhere in between, decides to record CS1 t1: SRC1 establishes RS1 toward SRS1 for the purpose of starting a new recording. t2: At some point in time, RS1 is terminated for whatever reason (e.g. network issue, SRS failure, etc.) t3: SRC1 establishes RS2 toward SRS1 for the purpose of continuing the recording. Option1 (using new RS Group element): If there was a metadata element for an RS Group, RSG1, it could have been created containing RS1 at time t1, then referenced at time t3 to cause RS2 to be added to RSG1 rather than creating RSG2. Option2 (using globally unique CS ID): Alternatively, if SRC1 wants RS1 and RS2 to be considered part of the same recording, SRC1 could indicate in both RS1 and RS2 that is it CS1 that is being recorded. Since CS1 is globally unique, SRS1 could recognize this as being an attempt to continue the same recording.=20 If SRC1 instead prefers to have two separate recordings, SRC1 could indicate in RS1 that it is CS1 that is being recorded, and in RS2 indicate that it is CS2 that is being recorded. CS1 and CS2 may contain the same actual media, but by using different globally unique IDs within each RS, SRC1 can force them to be two independent recordings. In this case, there is no need for an RS Group element, nor is there a need for an RS element. I previously favored Option1. Following the discussion up to and including that in the interim meeting, I am okay with Option2. Cheers, Charles =20 From pkyzivat@cisco.com Mon May 9 18:37:18 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5ACE069B for ; Mon, 9 May 2011 18:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.373 X-Spam-Level: X-Spam-Status: No, score=-110.373 tagged_above=-999 required=5 tests=[AWL=0.226, 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 qBH+12vDzJ2T for ; Mon, 9 May 2011 18:37:17 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id E8DDFE09BF for ; Mon, 9 May 2011 18:37:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=2852; q=dns/txt; s=iport; t=1304991437; x=1306201037; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=65jphk6Jh7y1aHSy/OxAoJ8lxkrzvo4wPO9/Pfizasw=; b=XOnRe4bTtXH6PvyeuQ0kQo9WQssSty2g9bYb99nqyC7+KF7yCFxGAIuR PBxbVTYfO38GCO0/LKYf0H4cpwWSa6HxzJ/K3YQ0Mwmbbm0Q2gVIh/5SM Vi7yJcXupzWLtsrVOCan3Pc8TAvCjAp0h6Ly4aKUouUUbFPykag6bwvqM I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGWWyE2rRDoG/2dsb2JhbACmAnelfoEdnjWGDASPZIQoilI X-IronPort-AV: E=Sophos;i="4.64,343,1301875200"; d="scan'208";a="311980198" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-3.cisco.com with ESMTP; 10 May 2011 01:37:15 +0000 Received: from [161.44.174.124] (dhcp-161-44-174-124.cisco.com [161.44.174.124]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4A1bFtW028519 for ; Tue, 10 May 2011 01:37:15 GMT Message-ID: <4DC896CA.6070802@cisco.com> Date: Mon, 09 May 2011 21:37:14 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "siprec@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [siprec] Multiple recordings of the same CS/CSG... X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 10 May 2011 01:37:18 -0000 During the call today we got into a discussion of the pros/cons/mechanisms for achieving multiple recordings of the same CS or CSG. I'm pretty sure this was initially posed as a potential requirement by Charles Eckel in: http://www.ietf.org/mail-archive/web/siprec/current/msg01876.html Paraphrasing, the argument is that two different participants in a CS, possibly with different SRCs, may both want to record the CS, and have control over *how* it is recorded. For instance, one may want to do its own mixing of the media streams and send the mix to the SRS for recording. It might also transcode, affecting the fidelity of the recording. Another participant might want all the streams recorded independently so they may later be analyzed separately. It isn't immediately apparent if this sort of operation is possible with the current model. Superficially it seems it is not. One question is whether this is something important to address. (If it happens to fall out without extra work then probably nobody will object, but if its extra work, then its something we really need to decide.) Its my assertion that from a practical perspective this sort of behavior can be achieved with the model we have, as follows: The mechanism currently on the table has each SRC assigning globally unique IDs for each CS, CSG, and various other things. This is still under debate, but whatever things don't end of having a globally unique id will almost certainly be scoped within something that does. Unless they go to some effort to coordinate, two SRCs involved with the "same" CS will each assign their own unique id to it. When the SRC receives metadata, this CS will appear to it as two independent CSs. Hence, *by default* there will be two independent recordings. If two SRCs what something different from that, they can potentially achieve it by coordinating unique id assignments among themselves. I am not proposing that we define a way to do that - at least for now it would be something proprietary between them. A "simple" example could be a fault-tolerant pair of SRCs that coordinate so that if one fails the other can take over and continue the recording. Here the pair would be coordinating a lot of sip knowledge in addition to the uuids. *If* some SRCs are coordinating their uuid assigments, and if there are cases where they want to cause independent recordings to be made, then they can achieve that by simply *not* using the same uuid for a CS. Of course this opens up a whole can of worms about how they decide when they want to be part of the same recording and when not. But we don't need to get into that - it is their problem to solve. AFAIK this ought to be sufficient for addressing Charle' problem. Discussion welcome. Thanks, Paul From mperumal@cisco.com Mon May 9 22:17:40 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6764E066A for ; Mon, 9 May 2011 22:17: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ogujzCki-Nx for ; Mon, 9 May 2011 22:17: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 C447BE0665 for ; Mon, 9 May 2011 22:17:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=4196; q=dns/txt; s=iport; t=1305004659; x=1306214259; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=aTnmmEvPWdbSQzellnthN7Nm5DMnedqjC8e9KBc35IY=; b=QZOpUyML9eoRzUJ6YmVJhz5S14is47oxxOinQP7SNZwRuy/FjVQiN4+b tTttvPSNolv+ogcZCQWSzRafuQU0uBR8YcEj8QMP33Z54GPgIrg9FPsPx thtwhkMMlsKHUwI2Jx0ejXGTwIg1h32ca2Iqqsl8F1eLwMCSDHRvIfx8I o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgABAGvJyE2Q/khLgWdsb2JhbACXUo4xFAEBFiYlpmOeQIYOBIY/jV+KNQ X-IronPort-AV: E=Sophos;i="4.64,344,1301875200"; d="scan'208";a="87623599" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 10 May 2011 05:17: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 p4A5HbSB015204 for ; Tue, 10 May 2011 05:17: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); Tue, 10 May 2011 10:47: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: Tue, 10 May 2011 10:47:29 +0530 Message-ID: <1D062974A4845E4D8A343C65380492020561AF0F@XMB-BGL-414.cisco.com> In-Reply-To: <4DC896CA.6070802@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Multiple recordings of the same CS/CSG... Thread-Index: AcwOstFw+YuI3ir1StqSbtWgwooHrwAGkv2w References: <4DC896CA.6070802@cisco.com> From: "Muthu ArulMozhi Perumal (mperumal)" To: "Paul Kyzivat (pkyzivat)" , X-OriginalArrivalTime: 10 May 2011 05:17:33.0877 (UTC) FILETIME=[917D6650:01CC0ED1] Subject: Re: [siprec] Multiple recordings of the same CS/CSG... X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 10 May 2011 05:17:40 -0000 This looks a pragmatic use-case and it seems at times it may need no coordination among the SRCs at all to come up with such a unique ID because it is reserved/distributed well ahead. Consider a meeting where participants join from different geographic regions and each region has an SRC performing mixing and recording of media streams generated by the participants from that region. The meeting has a meeting ID reserved in advance and each participant joins the meeting hosted at the SRC in that region. The SRS can use the meeting ID to correlate these disparate recordings. However, it looks it would be a real challenge for the SRS to be able to synchronously playback these disparate recording -- this doesn't look a trivial problem to solve. In essence, I agree we need a unique ID to address these use-cases. But, the system should try to minimize the number of unique IDs needed. Muthu |-----Original Message----- |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat (pkyzivat) |Sent: Tuesday, May 10, 2011 7:07 AM |To: siprec@ietf.org |Subject: [siprec] Multiple recordings of the same CS/CSG... | |During the call today we got into a discussion of the |pros/cons/mechanisms for achieving multiple recordings of the same CS or |CSG. | |I'm pretty sure this was initially posed as a potential requirement by |Charles Eckel in: |http://www.ietf.org/mail-archive/web/siprec/current/msg01876.html | |Paraphrasing, the argument is that two different participants in a CS, |possibly with different SRCs, may both want to record the CS, and have |control over *how* it is recorded. For instance, one may want to do its |own mixing of the media streams and send the mix to the SRS for |recording. It might also transcode, affecting the fidelity of the |recording. Another participant might want all the streams recorded |independently so they may later be analyzed separately. | |It isn't immediately apparent if this sort of operation is possible with |the current model. Superficially it seems it is not. | |One question is whether this is something important to address. (If it |happens to fall out without extra work then probably nobody will object, |but if its extra work, then its something we really need to decide.) | |Its my assertion that from a practical perspective this sort of behavior |can be achieved with the model we have, as follows: | |The mechanism currently on the table has each SRC assigning globally |unique IDs for each CS, CSG, and various other things. This is still |under debate, but whatever things don't end of having a globally unique |id will almost certainly be scoped within something that does. | |Unless they go to some effort to coordinate, two SRCs involved with the |"same" CS will each assign their own unique id to it. When the SRC |receives metadata, this CS will appear to it as two independent CSs. |Hence, *by default* there will be two independent recordings. | |If two SRCs what something different from that, they can potentially |achieve it by coordinating unique id assignments among themselves. I am |not proposing that we define a way to do that - at least for now it |would be something proprietary between them. A "simple" example could be |a fault-tolerant pair of SRCs that coordinate so that if one fails the |other can take over and continue the recording. Here the pair would be |coordinating a lot of sip knowledge in addition to the uuids. | |*If* some SRCs are coordinating their uuid assigments, and if there are |cases where they want to cause independent recordings to be made, then |they can achieve that by simply *not* using the same uuid for a CS. Of |course this opens up a whole can of worms about how they decide when |they want to be part of the same recording and when not. But we don't |need to get into that - it is their problem to solve. | |AFAIK this ought to be sufficient for addressing Charle' problem. |Discussion welcome. | | Thanks, | Paul |_______________________________________________ |siprec mailing list |siprec@ietf.org |https://www.ietf.org/mailman/listinfo/siprec From mperumal@cisco.com Mon May 9 22:30:55 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7BD5E069E for ; Mon, 9 May 2011 22:30:55 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cLGwnH6cfAkx for ; Mon, 9 May 2011 22:30:54 -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 69188E0665 for ; Mon, 9 May 2011 22:30:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=2851; q=dns/txt; s=iport; t=1305005454; x=1306215054; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=vcvmWC3FFS7GAd+TIhPdzwbyrA7XH3nFSyi1MRm88Lk=; b=g09eRpgnnA3ghws9QVmW9v2uw6e5ORanfReQDBP+DgWmOsHZUWbX1m4h g6miWsQ8s7XhXhDmpxOIkok8N9AEpGuwcNicmZeAy3DshTNc2Db+3+qpK 8+yRN/04hD7SFRvpi6id6GJD5xAn0Gb7ptV8DnPC/bN4hEba9A7Fu5iDX g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgABAPXMyE2Q/khRgWdsb2JhbACXUo4xFAEBFiYlplyeQIYOBIY/jV+KNQ X-IronPort-AV: E=Sophos;i="4.64,345,1301875200"; d="scan'208";a="87625531" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 10 May 2011 05:30:53 +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 p4A5UkGk025877 for ; Tue, 10 May 2011 05:30:53 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, 10 May 2011 11:00:50 +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, 10 May 2011 11:00:48 +0530 Message-ID: <1D062974A4845E4D8A343C65380492020561AF20@XMB-BGL-414.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] RS Group / Recording Object issue from interim meeting Thread-Index: AcwOnlUD796ZsvbMTUylbGle0/maUwANDJYw References: From: "Muthu ArulMozhi Perumal (mperumal)" To: "Charles Eckel (eckelcu)" , X-OriginalArrivalTime: 10 May 2011 05:30:50.0123 (UTC) FILETIME=[6C16E5B0:01CC0ED3] Subject: Re: [siprec] RS Group / Recording Object issue from 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: Tue, 10 May 2011 05:30:56 -0000 To me it seems the unique CS ID should suffice to continue a (broken) recording as well as correlate disparate recordings, so I am inclined to option2. Muthu |-----Original Message----- |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Charles Eckel (eckelcu) |Sent: Tuesday, May 10, 2011 4:41 AM |To: siprec@ietf.org |Subject: [siprec] RS Group / Recording Object issue from interim meeting | |I am attempting to summarize the discussion we had around this issue, |and provide what I understood to be the accepted proposal. First, let me |settle on a single term. The term RS Group will be used to mean a |collection of RS elements that comprise a single recording. For example, |RS1 and RS2 may be two independent sessions that together form a single |recording. In such a case, the media streams associated with RS1 and RS2 |are combined into a single recording. | |Question1: Do we need an RS Group element within the metadata model? |Question2: If the answer to Q1 is no, do we need an RS element in the |metadata model? | |Use Cases: |t0: UA1 and UA2 establish CS1, and SRC1, which may be co-located with |UA1 or UA2 or may be somewhere in between, decides to record CS1 |t1: SRC1 establishes RS1 toward SRS1 for the purpose of starting a new |recording. |t2: At some point in time, RS1 is terminated for whatever reason (e.g. |network issue, SRS failure, etc.) |t3: SRC1 establishes RS2 toward SRS1 for the purpose of continuing the |recording. | |Option1 (using new RS Group element): |If there was a metadata element for an RS Group, RSG1, it could have |been created containing RS1 at time t1, then referenced at time t3 to |cause RS2 to be added to RSG1 rather than creating RSG2. | |Option2 (using globally unique CS ID): |Alternatively, if SRC1 wants RS1 and RS2 to be considered part of the |same recording, SRC1 could indicate in both RS1 and RS2 that is it CS1 |that is being recorded. Since CS1 is globally unique, SRS1 could |recognize this as being an attempt to continue the same recording. | |If SRC1 instead prefers to have two separate recordings, SRC1 could |indicate in RS1 that it is CS1 that is being recorded, and in RS2 |indicate that it is CS2 that is being recorded. CS1 and CS2 may contain |the same actual media, but by using different globally unique IDs within |each RS, SRC1 can force them to be two independent recordings. | |In this case, there is no need for an RS Group element, nor is there a |need for an RS element. | |I previously favored Option1. Following the discussion up to and |including that in the interim meeting, I am okay with Option2. | |Cheers, |Charles | | | |_______________________________________________ |siprec mailing list |siprec@ietf.org |https://www.ietf.org/mailman/listinfo/siprec From rmohanr@cisco.com Mon May 9 23:19: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 55E59E0780 for ; Mon, 9 May 2011 23:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.547 X-Spam-Level: X-Spam-Status: No, score=-9.547 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, 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 NXuDRY6vdyup for ; Mon, 9 May 2011 23:19:55 -0700 (PDT) Received: from ams-iport-1.cisco.com (unknown [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3C815E0669 for ; Mon, 9 May 2011 23:19:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=3078; q=dns/txt; s=iport; t=1305008395; x=1306217995; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=/D1xLCVqFPgE2W7XSgAKMHGTeDnVySVOYI0Ych7gIDM=; b=WEDjqrbLUP4y8L7QpbrXv8fzSYwKUsfdm3bAy76FdqYUMenZ7UOw6tNd /ReH6bnwGEGyOz1Px/n+66KduS8JSpq5SQBEHgIsukV9O8cxhprYJwG3V Rrrhn/yP4X03mFgnoKdrYWjy/Jyv/kgXM6DRZBmy94N5XzBLZY4iFYMJT E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgABAK/YyE2Q/khRgWdsb2JhbACXUo4xFAEBFiYlpnmeQIYOBIY/jV+KNQ X-IronPort-AV: E=Sophos;i="4.64,345,1301875200"; d="scan'208";a="87633079" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 10 May 2011 06:19:52 +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 p4A6JhAE006531 for ; Tue, 10 May 2011 06:19:51 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, 10 May 2011 11:49: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: Tue, 10 May 2011 11:49:48 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD06480A28@XMB-BGL-417.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] RS Group / Recording Object issue from interim meeting Thread-Index: AcwOnlUD796ZsvbMTUylbGle0/maUwAOn8yA References: From: "Ram Mohan R (rmohanr)" To: "Charles Eckel (eckelcu)" , X-OriginalArrivalTime: 10 May 2011 06:19:49.0941 (UTC) FILETIME=[445B8650:01CC0EDA] Subject: Re: [siprec] RS Group / Recording Object issue from 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: Tue, 10 May 2011 06:19:57 -0000 As I mentioned in the meeting yesterday, CS Unique ID should suffice to correlate disparate recordings and hence we don't need RS-Group element. How SRC(s) share this CS Unique ID is something that is currently left to implementers(out of scope). so I favor Option2=20 Regards, Ram > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Charles Eckel (eckelcu) > Sent: Tuesday, May 10, 2011 4:41 AM > To: siprec@ietf.org > Subject: [siprec] RS Group / Recording Object issue from interim > meeting >=20 > I am attempting to summarize the discussion we had around this issue, > and provide what I understood to be the accepted proposal. First, let > me > settle on a single term. The term RS Group will be used to mean a > collection of RS elements that comprise a single recording. For > example, > RS1 and RS2 may be two independent sessions that together form a single > recording. In such a case, the media streams associated with RS1 and > RS2 > are combined into a single recording. >=20 > Question1: Do we need an RS Group element within the metadata model? > Question2: If the answer to Q1 is no, do we need an RS element in the > metadata model? >=20 > Use Cases: > t0: UA1 and UA2 establish CS1, and SRC1, which may be co-located with > UA1 or UA2 or may be somewhere in between, decides to record CS1 > t1: SRC1 establishes RS1 toward SRS1 for the purpose of starting a new > recording. > t2: At some point in time, RS1 is terminated for whatever reason (e.g. > network issue, SRS failure, etc.) > t3: SRC1 establishes RS2 toward SRS1 for the purpose of continuing the > recording. >=20 > Option1 (using new RS Group element): > If there was a metadata element for an RS Group, RSG1, it could have > been created containing RS1 at time t1, then referenced at time t3 to > cause RS2 to be added to RSG1 rather than creating RSG2. >=20 > Option2 (using globally unique CS ID): > Alternatively, if SRC1 wants RS1 and RS2 to be considered part of the > same recording, SRC1 could indicate in both RS1 and RS2 that is it CS1 > that is being recorded. Since CS1 is globally unique, SRS1 could > recognize this as being an attempt to continue the same recording. >=20 > If SRC1 instead prefers to have two separate recordings, SRC1 could > indicate in RS1 that it is CS1 that is being recorded, and in RS2 > indicate that it is CS2 that is being recorded. CS1 and CS2 may contain > the same actual media, but by using different globally unique IDs > within > each RS, SRC1 can force them to be two independent recordings. >=20 > In this case, there is no need for an RS Group element, nor is there a > need for an RS element. >=20 > I previously favored Option1. Following the discussion up to and > including that in the interim meeting, I am okay with Option2. >=20 > Cheers, > Charles >=20 >=20 >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From partr@cisco.com Tue May 10 00:25: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 1810EE069B for ; Tue, 10 May 2011 00:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.184 X-Spam-Level: X-Spam-Status: No, score=-10.184 tagged_above=-999 required=5 tests=[AWL=0.415, 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 Egkj5tL6C4p9 for ; Tue, 10 May 2011 00:25:25 -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 8F6C3E067E for ; Tue, 10 May 2011 00:25:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=4108; q=dns/txt; s=iport; t=1305012324; x=1306221924; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=DHPrR0wcxUIsmLrUNB9jgorgahKfMC2lBPpm/dTdC9A=; b=WlLmhPDri92+JGkevJOMxsjoriFh9SnPsSA+Mf1AbsMblWzLpyWD3OHl hLvDcvcewdIuwnqatj01hS0p0SookFULM6UTQCL2PU8mH/lBVGxTxKAe2 OrbSusoMMMbY4ac4aymvUFTrQGXjVsdthj2HeNvyw5bbK82JFaq4yIuxX c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgABAO3nyE2Q/khNgWdsb2JhbACXUo4uFAEBFiYliHGdfJ4+hg4Ehj+NX4o1 X-IronPort-AV: E=Sophos;i="4.64,345,1301875200"; d="scan'208";a="87645433" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 10 May 2011 07:25: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 p4A7PHxL007582 for ; Tue, 10 May 2011 07:25:20 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, 10 May 2011 12:55: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, 10 May 2011 12:55:17 +0530 Message-ID: In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD06480A28@XMB-BGL-417.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] RS Group / Recording Object issue from interim meeting Thread-Index: AcwOnlUD796ZsvbMTUylbGle0/maUwAOn8yAAAGlS7A= References: <35BCE99A477D6A4986FB2216D8CF2CFD06480A28@XMB-BGL-417.cisco.com> From: "Parthasarathi R (partr)" To: "Ram Mohan R (rmohanr)" , "Charles Eckel (eckelcu)" , X-OriginalArrivalTime: 10 May 2011 07:25:17.0903 (UTC) FILETIME=[699AF5F0:01CC0EE3] Subject: Re: [siprec] RS Group / Recording Object issue from 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: Tue, 10 May 2011 07:25:26 -0000 Charles, Just adding to Ram mentioned, draft-jones-ipmc-session-id-01 Session-UUID or draft-kaplan-dispatch-session-id-03 Session-id or other proprietary unique-id may be used in CS to make your proposed solution work. IMO, it is outside the scope of SIPREC and I favor OPTION 2. The reason for having RS element in the model is to show the model from SRS perspective and in case of metadata format, SIP Message information (Dialog-id, Date header) shall be re-used instead of having separate RS specific XML elements. Thanks Partha =20 -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Ram Mohan R (rmohanr) Sent: Tuesday, May 10, 2011 11:50 AM To: Charles Eckel (eckelcu); siprec@ietf.org Subject: Re: [siprec] RS Group / Recording Object issue from interim meeting As I mentioned in the meeting yesterday, CS Unique ID should suffice to correlate disparate recordings and hence we don't need RS-Group element. How SRC(s) share this CS Unique ID is something that is currently left to implementers(out of scope). so I favor Option2=20 Regards, Ram > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > Behalf Of Charles Eckel (eckelcu) > Sent: Tuesday, May 10, 2011 4:41 AM > To: siprec@ietf.org > Subject: [siprec] RS Group / Recording Object issue from interim=20 > meeting >=20 > I am attempting to summarize the discussion we had around this issue,=20 > and provide what I understood to be the accepted proposal. First, let=20 > me settle on a single term. The term RS Group will be used to mean a=20 > collection of RS elements that comprise a single recording. For=20 > example, > RS1 and RS2 may be two independent sessions that together form a single > recording. In such a case, the media streams associated with RS1 and > RS2 > are combined into a single recording. >=20 > Question1: Do we need an RS Group element within the metadata model? > Question2: If the answer to Q1 is no, do we need an RS element in the=20 > metadata model? >=20 > Use Cases: > t0: UA1 and UA2 establish CS1, and SRC1, which may be co-located with > UA1 or UA2 or may be somewhere in between, decides to record CS1 > t1: SRC1 establishes RS1 toward SRS1 for the purpose of starting a new > recording. > t2: At some point in time, RS1 is terminated for whatever reason (e.g. > network issue, SRS failure, etc.) > t3: SRC1 establishes RS2 toward SRS1 for the purpose of continuing the > recording. >=20 > Option1 (using new RS Group element): > If there was a metadata element for an RS Group, RSG1, it could have=20 > been created containing RS1 at time t1, then referenced at time t3 to=20 > cause RS2 to be added to RSG1 rather than creating RSG2. >=20 > Option2 (using globally unique CS ID): > Alternatively, if SRC1 wants RS1 and RS2 to be considered part of the=20 > same recording, SRC1 could indicate in both RS1 and RS2 that is it CS1 > that is being recorded. Since CS1 is globally unique, SRS1 could=20 > recognize this as being an attempt to continue the same recording. >=20 > If SRC1 instead prefers to have two separate recordings, SRC1 could=20 > indicate in RS1 that it is CS1 that is being recorded, and in RS2=20 > indicate that it is CS2 that is being recorded. CS1 and CS2 may contain > the same actual media, but by using different globally unique IDs=20 > within each RS, SRC1 can force them to be two independent recordings. >=20 > In this case, there is no need for an RS Group element, nor is there a > need for an RS element. >=20 > I previously favored Option1. Following the discussion up to and=20 > including that in the interim meeting, I am okay with Option2. >=20 > Cheers, > 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 From john.elwell@siemens-enterprise.com Tue May 10 00:34: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 1AD62E07DB for ; Tue, 10 May 2011 00:34:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.418 X-Spam-Level: X-Spam-Status: No, score=-105.418 tagged_above=-999 required=5 tests=[AWL=1.181, 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 8DmVOae3LgsP for ; Tue, 10 May 2011 00:34:03 -0700 (PDT) Received: from mail182.messagelabs.com (mail182.messagelabs.com [85.158.139.83]) by ietfa.amsl.com (Postfix) with SMTP id CFC30E06A1 for ; Tue, 10 May 2011 00:34:02 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-14.tower-182.messagelabs.com!1305012841!6350233!1 X-StarScan-Version: 6.2.16; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 25855 invoked from network); 10 May 2011 07:34:01 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-14.tower-182.messagelabs.com with SMTP; 10 May 2011 07:34:01 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 114C81EB83D3 for ; Tue, 10 May 2011 09:34:01 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 10 May 2011 09:34:01 +0200 From: "Elwell, John" To: "siprec@ietf.org" Date: Tue, 10 May 2011 09:34:00 +0200 Thread-Topic: Draft minutes from interim virtual meeting Thread-Index: AcwO5KDR8XmfvxKgSBOB06TomviNeA== 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 from interim virtual 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: Tue, 10 May 2011 07:34:06 -0000 Unfortunately, in my hurry I misinterpreted the Webex controls and thought = the meeting was being recorded when it was not. So we have no recording, an= d I have put the minutes together based on notes from Andy and my own notes= / memory. I suspect some of the points raised have been lost, but I hope t= he main conclusions are about right. Please send your changes/additions within one week. John ################################################# Minutes of the SIPREC WG Interim Virtual Meeting 2011-05-09, 14.00-16.00 GMT/UTC =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Meeting chaired by Brian Rosen and John Elwell. Participants: Brian Rosen, John Elwell, Ken Rehor, Leon Portman, Henry Lum,= Ram Mohen, Andy Hutton, Paul Kyzivat, Parthasarathi, Dan Romascanu, Charle= s Eckel, Mary Barnes, Arul Muthu Minutes produced by John Elwell based on notes from Andy Hutton. Jabber log: None of the meeting participants were on Jabber. Recording: Owing to misoperation, the meeting was not recorded. Meeting started at 14.05. Topic - Administrivia (chairs) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D Slides: http://kenrehor.com/ietf/siprec/IETF80.1/Chairs.pdf No changes to published agenda. Topic - Architecture (Andy Hutton) draft-ietf-siprec-architecture-02 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D Draft: https://datatracker.ietf.org/doc/draft-ietf-siprec-architecture/ Slides: http://kenrehor.com/ietf/siprec/IETF80.1/201105_SIPREC_Interim_Draf= t-ietf-siprec-architecture-Status.pdf Slides 4/5 - There was a discussion on SRC Decomposition and Partha's comme= nt that the figures in the document should show the SRC split into two sepa= rate UA's one on the CS side and one on the RS side. Andy stated that he di= d not fully understand the need for showing such a decomposition but maybe = further study of the RTP Model might indicate a reason why this might be ne= eded. No other views were expressed and it was agreed that Andy would keep = the discussion going on the list to get consensus. Topic - RTP Model (Charles Eckel) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D Slides: http://kenrehor.com/ietf/siprec/IETF80.1/RTP%20model.pdf Charles had sent out on the list some proposed text on the RTP model (incor= porating text from Andy Hutton merged with earlier text from himself). The = text was targeted at incorporation into the architecture draft. Arul pointed out that the RTP translator model did not allow the SRC to add= any value in terms of synchronising streams, therefore the model might nee= d augmenting (in the area of RTCP handling) or considered not applicable. The text certainly needs more discussion to gain WG consensus before incorp= oration in the architecture draft, and therefore Charles kindly agreed to p= ut it into a separate individual draft (with the help of others as necessar= y) for further discussion. Also, when this is available, the chairs will tr= y to get some involvement of experts in AVTCORE and try to avoid clashes wi= th AVTxxx meetings in Quebec City, so that experts can attend if needed. Topic - Metadata model(Parthasarasi R) draft-ietf-siprec-metadata-00 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Draft: https://datatracker.ietf.org/doc/draft-ietf-siprec-metadata/ Slides: http://kenrehor.com/ietf/siprec/IETF80.1/SIPREC%20Metamodel%20-%20V= irtual%20Interim-May09_2011.pdf Slide 6 - On the open issue concerning any additional direct associates wit= h the RS block, there were no proposals for additions. Slide 7 - There was considerable discussion on the need for a Recording Ses= sion object. Paul Kyzivat doubted that we really need to refer to an RS obj= ect from elsewhere, and if not, why model an RS in metadata? Henry asked wh= ether we have a requirement for pausing a whole RS, as opposed to media str= eams, since this might be justification for an RS object. Although the meet= ing was tending towards considering pause of the entire RS as not needed, m= ore discussion is required on the need for this and on the consequences for= the model if it is needed. Notwithstanding the pause issue, can we move forward without an RS object a= nd without any other object representing a Recording or Recording Group (an= object we had previously but discarded)? Charles pointed out two cases: wh= en two SRCs need to create separate recordings of the same CS; and when som= ething goes wrong during recording of a CS and the SRC wants to initiate a = new RS to continue recording the same CS. Although the unique CS object ide= ntifier is sufficient for either case, it is not sufficient to distinguish = the two cases. The meeting was probably tending towards not needing an RS object (or any o= ther object representing a recording or group of recordings), but more list= discussion is needed. Charles kindly agreed to start a new thread and list= his summary of the situation and his views. There was agreement that the attributes of an RS are not needed (there had = been email discussion stating why not). There was insufficient time to review the remaining issues in the slides. Topic - Metadata format(Parthasarasi R) draft-ram-siprec-metadata-format-01 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Draft: https://datatracker.ietf.org/doc/draft-ram-siprec-metadata-format/ Slides: http://kenrehor.com/ietf/siprec/IETF80.1/SIPREC%20Metamodel%20Forma= t-Interim-May9-2011.pdf Slide 5, open issue 1 - There was no disagreement on allowing a many-to-man= y relationship between RS and CS objects. Slide 6, open issue 2 - Skipped, as this relates to the ongoing discussion = on the model. Slide 7, open issue 3 - There was no disagreement that both CSG and CS obje= cts should have globally unique IDs. Slide 8, open issue 4 - The issue of whether a Media Stream (MS) object nee= ds a globally unique ID seems to depend on whether a single MS can have a l= ifetime outside the context of a single CS. Needs further list discussion. Slide 9, open issue 5 - Although some thought it would be sufficient for a = Participant object to be unique within the context of a CS or CSG, Charles = was concerned we may need a means of identifying the same Participant in se= veral CSs, e.g., over a call transfer. Charles noted that the general concept of globally unique identifiers and r= amifications for back-end storage had arisen at the Prague meeting, but tho= se with concerns on that occasion were not present on this occasion. Paul s= uggested that the use of globally unique identifiers on the SIPREC interfac= e does not necessarily prevent the SRS finding other solutions for back-end= storage or retrieval. More list discussion needed. Slide 10, open Issue 6 - There was only time for limited discussion. This i= s not really an XML extensibility issue. There was insufficient time to review the remaining issues in the slides. Topic - Protocol (Henry Lum) draft-portman-siprec-protocol-04 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Draft: https://datatracker.ietf.org/doc/draft-portman-siprec-protocol/ Slides: http://kenrehor.com/ietf/siprec/IETF80.1/SIPREC%20Protocol%20-%20Vi= rtual%20Interim%20-%2020110509.pdf There was no time for this topic. Wrap-up =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D In view of failing to finish the agenda, it was suggested we have another i= nterim virtual meeting during the second half of June. This should cover th= e protocol as well as some specific topics that are still open following li= st discussion. However, the aim should be to try to resolve as much as poss= ible on the list during the next few weeks. The chairs will try to arrange = a second interim virtual meeting, which can be cancelled if not needed. The meeting was closed at 16.05. From john.elwell@siemens-enterprise.com Tue May 10 00:34: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 B5C54E0811 for ; Tue, 10 May 2011 00:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.433 X-Spam-Level: X-Spam-Status: No, score=-105.433 tagged_above=-999 required=5 tests=[AWL=1.166, 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 1Is2h5TBcyDm for ; Tue, 10 May 2011 00:34:07 -0700 (PDT) Received: from mail21.messagelabs.com (mail21.messagelabs.com [85.158.143.35]) by ietfa.amsl.com (Postfix) with SMTP id 50D04E06A1 for ; Tue, 10 May 2011 00:34:07 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1305012831!41425573!1 X-StarScan-Version: 6.2.16; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 17423 invoked from network); 10 May 2011 07:33:51 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-7.tower-21.messagelabs.com with SMTP; 10 May 2011 07:33:51 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 10F3D23F03DB for ; Tue, 10 May 2011 09:34: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, 10 May 2011 09:34:06 +0200 From: "Elwell, John" To: "siprec@ietf.org" Date: Tue, 10 May 2011 09:34:04 +0200 Thread-Topic: Agreements at virtual interim meeting Thread-Index: AcwO5KOVlP34Aiq8QkCSb3ZZo2lkdA== 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] Agreements at 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: Tue, 10 May 2011 07:34:08 -0000 Although many topics need further list discussion, the following were agree= d at the meeting. If you have any objections, please raise them on the list= within one week (by 2011-05-16). - Metadata model - the additional direction relationships with the RS block= are needed (although this is also impacted by the ongoing discussion on th= e need for the RS block - Metadata model - even if RS is retained, its attributes are not needed. - Metadata format - many-to-many relationship between CS and RS will be all= owed for. - Metadata format - both CSG and CS objects should have globally unique IDs John= From john.elwell@siemens-enterprise.com Tue May 10 01:01:55 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13673E08A7 for ; Tue, 10 May 2011 01:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.448 X-Spam-Level: X-Spam-Status: No, score=-105.448 tagged_above=-999 required=5 tests=[AWL=1.151, 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 ZrRT5PQ-ZPRO for ; Tue, 10 May 2011 01:01:53 -0700 (PDT) Received: from mail174.messagelabs.com (mail174.messagelabs.com [85.158.138.51]) by ietfa.amsl.com (Postfix) with SMTP id D7E81E08A3 for ; Tue, 10 May 2011 01:01:52 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1305014111!12897022!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 27573 invoked from network); 10 May 2011 07:55:11 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-15.tower-174.messagelabs.com with SMTP; 10 May 2011 07:55:11 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 0522E1EB83EE for ; Tue, 10 May 2011 09:55:11 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 10 May 2011 09:55:11 +0200 From: "Elwell, John" To: "siprec@ietf.org" Date: Tue, 10 May 2011 09:55:09 +0200 Thread-Topic: Poll for dates for next interim virtual meeting Thread-Index: AcwO55V9NupxN2VvQmuzKsE7oYixHw== 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] Poll for dates for next interim virtual 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: Tue, 10 May 2011 08:01:55 -0000 As agreed yesterday, I have initiated a poll for dates in late June for ano= ther call, to focus on the protocol (which we didn't get done yesterday) an= d perhaps some specific issues we fail to resolve on the list in the meanti= me. We can cancel if no longer needed. Here is the link - please respond by 2011-05-17. http://doodle.com/dpu5w4w73uk49mb8 John From pkyzivat@cisco.com Tue May 10 03:24:29 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AF08E08C8 for ; Tue, 10 May 2011 03:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.495 X-Spam-Level: X-Spam-Status: No, score=-108.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1, 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 NPAQ5DsxkGEr for ; Tue, 10 May 2011 03:24:28 -0700 (PDT) Received: from sj-iport-2.cisco.com (unknown [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 4424CE089A for ; Tue, 10 May 2011 03:24:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=4853; q=dns/txt; s=iport; t=1305023068; x=1306232668; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=IGwVOclcGPT0hKDDrpmv6Y7jSWU6JbVd/+mCcmZq0CA=; b=gaXYzfNzBnVGWk04q7PSjQYZTaEeaLmRORW6QaNPm15NLTonizFZag8P q9m1qb0C+pipEWNkcr00yOQvk7qnHlYqpt23nynb/fJehjULVggV8VQUu +CHZBQ3OFV9bU3Jx1HR9f0dg1ZK1/k9fldNTiWVRfPtc35wFc3JcMv4ND Q=; X-IronPort-AV: E=Sophos;i="4.64,345,1301875200"; d="scan'208";a="353859629" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-2.cisco.com with ESMTP; 10 May 2011 10:24:27 +0000 Received: from [10.86.255.2] ([10.86.255.2]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p4AAOQSv005109; Tue, 10 May 2011 10:24:26 GMT Message-ID: <4DC91259.2030106@cisco.com> Date: Tue, 10 May 2011 06:24:25 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Muthu ArulMozhi Perumal (mperumal)" References: <4DC896CA.6070802@cisco.com> <1D062974A4845E4D8A343C65380492020561AF0F@XMB-BGL-414.cisco.com> In-Reply-To: <1D062974A4845E4D8A343C65380492020561AF0F@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] Multiple recordings of the same CS/CSG... X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 10 May 2011 10:24:29 -0000 Muthu, If the SRCs *know* they will want to coordinate in this case there a number of ways they could use the currently proposed mechanisms to achieve that. For example, a uuid could be assigned as part of the predefined meeting state. Then each SRC could use this uuid as a CSG id. Each connection to the focus could be defined with a unique CS id within the common CSG id. Thanks, Paul On 5/10/2011 1:17 AM, Muthu ArulMozhi Perumal (mperumal) wrote: > This looks a pragmatic use-case and it seems at times it may need no > coordination among the SRCs at all to come up with such a unique ID > because it is reserved/distributed well ahead. Consider a meeting where > participants join from different geographic regions and each region has > an SRC performing mixing and recording of media streams generated by the > participants from that region. The meeting has a meeting ID reserved in > advance and each participant joins the meeting hosted at the SRC in that > region. The SRS can use the meeting ID to correlate these disparate > recordings. > > However, it looks it would be a real challenge for the SRS to be able to > synchronously playback these disparate recording -- this doesn't look a > trivial problem to solve. > > In essence, I agree we need a unique ID to address these use-cases. But, > the system should try to minimize the number of unique IDs needed. > > Muthu > > |-----Original Message----- > |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Paul Kyzivat (pkyzivat) > |Sent: Tuesday, May 10, 2011 7:07 AM > |To: siprec@ietf.org > |Subject: [siprec] Multiple recordings of the same CS/CSG... > | > |During the call today we got into a discussion of the > |pros/cons/mechanisms for achieving multiple recordings of the same CS > or > |CSG. > | > |I'm pretty sure this was initially posed as a potential requirement by > |Charles Eckel in: > |http://www.ietf.org/mail-archive/web/siprec/current/msg01876.html > | > |Paraphrasing, the argument is that two different participants in a CS, > |possibly with different SRCs, may both want to record the CS, and have > |control over *how* it is recorded. For instance, one may want to do its > |own mixing of the media streams and send the mix to the SRS for > |recording. It might also transcode, affecting the fidelity of the > |recording. Another participant might want all the streams recorded > |independently so they may later be analyzed separately. > | > |It isn't immediately apparent if this sort of operation is possible > with > |the current model. Superficially it seems it is not. > | > |One question is whether this is something important to address. (If it > |happens to fall out without extra work then probably nobody will > object, > |but if its extra work, then its something we really need to decide.) > | > |Its my assertion that from a practical perspective this sort of > behavior > |can be achieved with the model we have, as follows: > | > |The mechanism currently on the table has each SRC assigning globally > |unique IDs for each CS, CSG, and various other things. This is still > |under debate, but whatever things don't end of having a globally unique > |id will almost certainly be scoped within something that does. > | > |Unless they go to some effort to coordinate, two SRCs involved with the > |"same" CS will each assign their own unique id to it. When the SRC > |receives metadata, this CS will appear to it as two independent CSs. > |Hence, *by default* there will be two independent recordings. > | > |If two SRCs what something different from that, they can potentially > |achieve it by coordinating unique id assignments among themselves. I am > |not proposing that we define a way to do that - at least for now it > |would be something proprietary between them. A "simple" example could > be > |a fault-tolerant pair of SRCs that coordinate so that if one fails the > |other can take over and continue the recording. Here the pair would be > |coordinating a lot of sip knowledge in addition to the uuids. > | > |*If* some SRCs are coordinating their uuid assigments, and if there are > |cases where they want to cause independent recordings to be made, then > |they can achieve that by simply *not* using the same uuid for a CS. Of > |course this opens up a whole can of worms about how they decide when > |they want to be part of the same recording and when not. But we don't > |need to get into that - it is their problem to solve. > | > |AFAIK this ought to be sufficient for addressing Charle' problem. > |Discussion welcome. > | > | Thanks, > | Paul > |_______________________________________________ > |siprec mailing list > |siprec@ietf.org > |https://www.ietf.org/mailman/listinfo/siprec > From john.elwell@siemens-enterprise.com Tue May 10 05:46: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 54022E06D5 for ; Tue, 10 May 2011 05:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.462 X-Spam-Level: X-Spam-Status: No, score=-105.462 tagged_above=-999 required=5 tests=[AWL=1.137, 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 PEa4lwkIoChM for ; Tue, 10 May 2011 05:46:11 -0700 (PDT) Received: from mail21.messagelabs.com (mail21.messagelabs.com [85.158.143.35]) by ietfa.amsl.com (Postfix) with SMTP id 64654E06CD for ; Tue, 10 May 2011 05:45:41 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1305031536!44837239!1 X-StarScan-Version: 6.2.16; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 8991 invoked from network); 10 May 2011 12:45:36 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-14.tower-21.messagelabs.com with SMTP; 10 May 2011 12:45:36 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id AD1C11EB83EE for ; Tue, 10 May 2011 14:45:39 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 10 May 2011 14:45:40 +0200 From: "Elwell, John" To: "siprec@ietf.org" Date: Tue, 10 May 2011 14:45:37 +0200 Thread-Topic: Agreements at virtual interim meeting Thread-Index: AcwO5KOVlP34Aiq8QkCSb3ZZo2lkdA== 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] Agreements at 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: Tue, 10 May 2011 12:46:12 -0000 Resend with bullet one corrected (thanks, Ram) ############################################## Although many topics need further list discussion, the following were agree= d at the meeting. If you have any objections, please raise them on the list= within one week (by 2011-05-16). - Metadata model - the additional direction relationships with the RS block= are NOT needed (although this is also impacted by the ongoing discussion o= n the need for the RS block - Metadata model - even if RS is retained, its attributes are not needed. - Metadata format - many-to-many relationship between CS and RS will be all= owed for. - Metadata format - both CSG and CS objects should have globally unique IDs John= From eckelcu@cisco.com Tue May 10 08:54:22 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9E62E075C for ; Tue, 10 May 2011 08:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.387 X-Spam-Level: X-Spam-Status: No, score=-10.387 tagged_above=-999 required=5 tests=[AWL=0.212, 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 JsqvnAa4jpwf for ; Tue, 10 May 2011 08:54:22 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0825FE077A for ; Tue, 10 May 2011 08:54:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=3383; q=dns/txt; s=iport; t=1305042862; x=1306252462; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=SBpVwhZYxWDcgtXVDFq/4Kg2p8OXL2gwFZX/x0ikM9o=; b=Yv5N/hvrn+io1g68PLW+pF5IptYpFjHlemGlHTxQSBioZuSZZt0Z2s2/ 0HHFB/2cbIflcEKtlj3ihurddoLzPZNv6D7RWjyw0Yi0k2GPqPmr8b9sF BEmgM9VPsSLDeiTL/SFfYWHY1Yq/k0OC6gelL+OHeczfWMxJg98S88tc1 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwBAC9fyU2rRDoJ/2dsb2JhbACXWo4vd6hInk6GDwSGQo1eik4 X-IronPort-AV: E=Sophos;i="4.64,346,1301875200"; d="scan'208";a="312493910" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 10 May 2011 15:54:21 +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 p4AFsL9l000682 for ; Tue, 10 May 2011 15:54:21 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 May 2011 08:54: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: Tue, 10 May 2011 08:54:12 -0700 Message-ID: In-Reply-To: <4DC896CA.6070802@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Multiple recordings of the same CS/CSG... Thread-Index: AcwOstC8OBE753XYSXagrL3WGZkVXAAd2Gbw References: <4DC896CA.6070802@cisco.com> From: "Charles Eckel (eckelcu)" To: "Paul Kyzivat (pkyzivat)" , X-OriginalArrivalTime: 10 May 2011 15:54:13.0484 (UTC) FILETIME=[823ADAC0:01CC0F2A] Subject: Re: [siprec] Multiple recordings of the same CS/CSG... X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 10 May 2011 15:54:22 -0000 I agree. > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat (pkyzivat) > Sent: Monday, May 09, 2011 6:37 PM > To: siprec@ietf.org > Subject: [siprec] Multiple recordings of the same CS/CSG... >=20 > During the call today we got into a discussion of the > pros/cons/mechanisms for achieving multiple recordings of the same CS or > CSG. >=20 > I'm pretty sure this was initially posed as a potential requirement by > Charles Eckel in: > http://www.ietf.org/mail-archive/web/siprec/current/msg01876.html >=20 > Paraphrasing, the argument is that two different participants in a CS, > possibly with different SRCs, may both want to record the CS, and have > control over *how* it is recorded. For instance, one may want to do its > own mixing of the media streams and send the mix to the SRS for > recording. It might also transcode, affecting the fidelity of the > recording. Another participant might want all the streams recorded > independently so they may later be analyzed separately. >=20 > It isn't immediately apparent if this sort of operation is possible with > the current model. Superficially it seems it is not. >=20 > One question is whether this is something important to address. (If it > happens to fall out without extra work then probably nobody will object, > but if its extra work, then its something we really need to decide.) >=20 > Its my assertion that from a practical perspective this sort of behavior > can be achieved with the model we have, as follows: >=20 > The mechanism currently on the table has each SRC assigning globally > unique IDs for each CS, CSG, and various other things. This is still > under debate, but whatever things don't end of having a globally unique > id will almost certainly be scoped within something that does. >=20 > Unless they go to some effort to coordinate, two SRCs involved with the > "same" CS will each assign their own unique id to it. When the SRC > receives metadata, this CS will appear to it as two independent CSs. > Hence, *by default* there will be two independent recordings. >=20 > If two SRCs what something different from that, they can potentially > achieve it by coordinating unique id assignments among themselves. I am > not proposing that we define a way to do that - at least for now it > would be something proprietary between them. A "simple" example could be > a fault-tolerant pair of SRCs that coordinate so that if one fails the > other can take over and continue the recording. Here the pair would be > coordinating a lot of sip knowledge in addition to the uuids. >=20 > *If* some SRCs are coordinating their uuid assigments, and if there are > cases where they want to cause independent recordings to be made, then > they can achieve that by simply *not* using the same uuid for a CS. Of > course this opens up a whole can of worms about how they decide when > they want to be part of the same recording and when not. But we don't > need to get into that - it is their problem to solve. >=20 > AFAIK this ought to be sufficient for addressing Charle' problem. > Discussion welcome. >=20 > Thanks, > Paul > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From eckelcu@cisco.com Tue May 10 09:02:11 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF401E07BA for ; Tue, 10 May 2011 09:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.342 X-Spam-Level: X-Spam-Status: No, score=-9.342 tagged_above=-999 required=5 tests=[AWL=-0.847, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, 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 wejf-L+YBWah for ; Tue, 10 May 2011 09:02:10 -0700 (PDT) Received: from sj-iport-1.cisco.com (unknown [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id A7CFAE0731 for ; Tue, 10 May 2011 09:02:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=4716; q=dns/txt; s=iport; t=1305043330; x=1306252930; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=v2O97c6kSX9ku01lHj0SxQxbiAG+vdvrMX5j/JwYWRc=; b=RKMI7khxuDx4vaLhlyZsO7061EsptvJ1kAhUkhk1I+sxlHgwnIuqwvZc +dukJZNRv+u6oQElBQ6lVZ51baxNmsSaRLCIctsyMv7H7aToY/vzj503H NFLK53UuOTe0qZWKSE+TT1xB4Ry61BeXEk/rjQCpiPe0minlL/gBLW6h1 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwBADZhyU2rRDoG/2dsb2JhbACXW44vd6hmnkiGDwSGQo1eik4 X-IronPort-AV: E=Sophos;i="4.64,346,1301875200"; d="scan'208";a="445059955" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-1.cisco.com with ESMTP; 10 May 2011 16:02:09 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4AG292m031695 for ; Tue, 10 May 2011 16:02:09 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 May 2011 09:02:09 -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, 10 May 2011 09:02:08 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] RS Group / Recording Object issue from interim meeting Thread-Index: AcwOnlUD796ZsvbMTUylbGle0/maUwAOn8yAAAGlS7AAEs9kUA== References: <35BCE99A477D6A4986FB2216D8CF2CFD06480A28@XMB-BGL-417.cisco.com> From: "Charles Eckel (eckelcu)" To: "Parthasarathi R (partr)" , "Ram Mohan R (rmohanr)" , X-OriginalArrivalTime: 10 May 2011 16:02:09.0669 (UTC) FILETIME=[9E0EEB50:01CC0F2B] Subject: Re: [siprec] RS Group / Recording Object issue from 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: Tue, 10 May 2011 16:02:12 -0000 Hi Partha, The problem for me was that I started thinking of the RS as being equivalent to a recording. If we leave the RS in the model, it would be good to clarify the distinction. Cheers, Charles=20 > -----Original Message----- > From: Parthasarathi R (partr) > Sent: Tuesday, May 10, 2011 12:25 AM > To: Ram Mohan R (rmohanr); Charles Eckel (eckelcu); siprec@ietf.org > Subject: RE: [siprec] RS Group / Recording Object issue from interim meeting >=20 > Charles, >=20 > Just adding to Ram mentioned, draft-jones-ipmc-session-id-01 Session-UUID or draft-kaplan-dispatch- > session-id-03 Session-id or other proprietary unique-id may be used in CS to make your proposed > solution work. IMO, it is outside the scope of SIPREC and I favor OPTION 2. >=20 > The reason for having RS element in the model is to show the model from SRS perspective and in case of > metadata format, SIP Message information (Dialog-id, Date header) shall be re-used instead of having > separate RS specific XML elements. >=20 > Thanks > Partha >=20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Ram Mohan R (rmohanr) > Sent: Tuesday, May 10, 2011 11:50 AM > To: Charles Eckel (eckelcu); siprec@ietf.org > Subject: Re: [siprec] RS Group / Recording Object issue from interim meeting >=20 > As I mentioned in the meeting yesterday, CS Unique ID should suffice to correlate disparate recordings > and hence we don't need RS-Group element. > How SRC(s) share this CS Unique ID is something that is currently left to implementers(out of scope). >=20 > so I favor Option2 >=20 > Regards, > Ram >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Charles Eckel (eckelcu) > > Sent: Tuesday, May 10, 2011 4:41 AM > > To: siprec@ietf.org > > Subject: [siprec] RS Group / Recording Object issue from interim > > meeting > > > > I am attempting to summarize the discussion we had around this issue, > > and provide what I understood to be the accepted proposal. First, let > > me settle on a single term. The term RS Group will be used to mean a > > collection of RS elements that comprise a single recording. For > > example, > > RS1 and RS2 may be two independent sessions that together form a > single > > recording. In such a case, the media streams associated with RS1 and > > RS2 > > are combined into a single recording. > > > > Question1: Do we need an RS Group element within the metadata model? > > Question2: If the answer to Q1 is no, do we need an RS element in the > > metadata model? > > > > Use Cases: > > t0: UA1 and UA2 establish CS1, and SRC1, which may be co-located with > > UA1 or UA2 or may be somewhere in between, decides to record CS1 > > t1: SRC1 establishes RS1 toward SRS1 for the purpose of starting a new > > recording. > > t2: At some point in time, RS1 is terminated for whatever reason (e.g. > > network issue, SRS failure, etc.) > > t3: SRC1 establishes RS2 toward SRS1 for the purpose of continuing the > > recording. > > > > Option1 (using new RS Group element): > > If there was a metadata element for an RS Group, RSG1, it could have > > been created containing RS1 at time t1, then referenced at time t3 to > > cause RS2 to be added to RSG1 rather than creating RSG2. > > > > Option2 (using globally unique CS ID): > > Alternatively, if SRC1 wants RS1 and RS2 to be considered part of the > > same recording, SRC1 could indicate in both RS1 and RS2 that is it CS1 > > that is being recorded. Since CS1 is globally unique, SRS1 could > > recognize this as being an attempt to continue the same recording. > > > > If SRC1 instead prefers to have two separate recordings, SRC1 could > > indicate in RS1 that it is CS1 that is being recorded, and in RS2 > > indicate that it is CS2 that is being recorded. CS1 and CS2 may > contain > > the same actual media, but by using different globally unique IDs > > within each RS, SRC1 can force them to be two independent recordings. > > > > In this case, there is no need for an RS Group element, nor is there a > > need for an RS element. > > > > I previously favored Option1. Following the discussion up to and > > including that in the interim meeting, I am okay with Option2. > > > > Cheers, > > Charles > > > > > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From partr@cisco.com Tue May 10 09:11:25 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76808E076D for ; Tue, 10 May 2011 09:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.204 X-Spam-Level: X-Spam-Status: No, score=-10.204 tagged_above=-999 required=5 tests=[AWL=0.395, 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 Z7NwT4sOaQZi for ; Tue, 10 May 2011 09:11:23 -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 4113BE0744 for ; Tue, 10 May 2011 09:11:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=5169; q=dns/txt; s=iport; t=1305043883; x=1306253483; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=V7QWFBtX/ByMVqgJ1Rxev/f1yPE3K+/H0SpKahy54fs=; b=BtP/z6QUVbnYSrMfNNis3y4ej0gDiwLzCWx51i683LOlukCpAagKlHQ1 SKFSBU0IE2HjsXMcojRG5I0Q435rCApwuSw/1HXK004sexqYRaYZJdJxm mY/abQwZVTdChNOlN0Q6b/vKdbaQWOZBhlQntinbrXccUILcz9ifHVJS7 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqsAAPhiyU2Q/khRgWdsb2JhbACXW44vFAEBFiYliHCgCp5Ghg8EhkCNYIo2 X-IronPort-AV: E=Sophos;i="4.64,346,1301875200"; d="scan'208";a="87750313" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 10 May 2011 16:11:21 +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 p4AGBFj3004903 for ; Tue, 10 May 2011 16:11: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); Tue, 10 May 2011 21:41: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, 10 May 2011 21:41:14 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] RS Group / Recording Object issue from interim meeting Thread-Index: AcwOnlUD796ZsvbMTUylbGle0/maUwAOn8yAAAGlS7AAEs9kUAAAhHRQ References: <35BCE99A477D6A4986FB2216D8CF2CFD06480A28@XMB-BGL-417.cisco.com> From: "Parthasarathi R (partr)" To: "Charles Eckel (eckelcu)" , "Ram Mohan R (rmohanr)" , X-OriginalArrivalTime: 10 May 2011 16:11:17.0596 (UTC) FILETIME=[E4A5F1C0:01CC0F2C] Subject: Re: [siprec] RS Group / Recording Object issue from 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: Tue, 10 May 2011 16:11:25 -0000 Hi Charles, I agree with you to add the text which helps to distinct RS from recording.=20 Thanks Partha=20 -----Original Message----- From: Charles Eckel (eckelcu)=20 Sent: Tuesday, May 10, 2011 9:32 PM To: Parthasarathi R (partr); Ram Mohan R (rmohanr); 'siprec@ietf.org' Subject: RE: [siprec] RS Group / Recording Object issue from interim meeting Hi Partha, The problem for me was that I started thinking of the RS as being equivalent to a recording. If we leave the RS in the model, it would be good to clarify the distinction. Cheers, Charles=20 > -----Original Message----- > From: Parthasarathi R (partr) > Sent: Tuesday, May 10, 2011 12:25 AM > To: Ram Mohan R (rmohanr); Charles Eckel (eckelcu); siprec@ietf.org > Subject: RE: [siprec] RS Group / Recording Object issue from interim=20 > meeting >=20 > Charles, >=20 > Just adding to Ram mentioned, draft-jones-ipmc-session-id-01=20 > Session-UUID or draft-kaplan-dispatch- > session-id-03 Session-id or other proprietary unique-id may be used in > CS to make your proposed solution work. IMO, it is outside the scope of SIPREC and I favor OPTION 2. >=20 > The reason for having RS element in the model is to show the model=20 > from SRS perspective and in case of metadata format, SIP Message=20 > information (Dialog-id, Date header) shall be re-used instead of having separate RS specific XML elements. >=20 > Thanks > Partha >=20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > Behalf Of Ram Mohan R (rmohanr) > Sent: Tuesday, May 10, 2011 11:50 AM > To: Charles Eckel (eckelcu); siprec@ietf.org > Subject: Re: [siprec] RS Group / Recording Object issue from interim=20 > meeting >=20 > As I mentioned in the meeting yesterday, CS Unique ID should suffice=20 > to correlate disparate recordings and hence we don't need RS-Group element. > How SRC(s) share this CS Unique ID is something that is currently left to implementers(out of scope). >=20 > so I favor Option2 >=20 > Regards, > Ram >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > > Behalf Of Charles Eckel (eckelcu) > > Sent: Tuesday, May 10, 2011 4:41 AM > > To: siprec@ietf.org > > Subject: [siprec] RS Group / Recording Object issue from interim=20 > > meeting > > > > I am attempting to summarize the discussion we had around this=20 > > issue, and provide what I understood to be the accepted proposal.=20 > > First, let me settle on a single term. The term RS Group will be=20 > > used to mean a collection of RS elements that comprise a single=20 > > recording. For example, > > RS1 and RS2 may be two independent sessions that together form a > single > > recording. In such a case, the media streams associated with RS1 and > > RS2 > > are combined into a single recording. > > > > Question1: Do we need an RS Group element within the metadata model? > > Question2: If the answer to Q1 is no, do we need an RS element in=20 > > the metadata model? > > > > Use Cases: > > t0: UA1 and UA2 establish CS1, and SRC1, which may be co-located=20 > > with > > UA1 or UA2 or may be somewhere in between, decides to record CS1 > > t1: SRC1 establishes RS1 toward SRS1 for the purpose of starting a=20 > > new recording. > > t2: At some point in time, RS1 is terminated for whatever reason (e.g. > > network issue, SRS failure, etc.) > > t3: SRC1 establishes RS2 toward SRS1 for the purpose of continuing=20 > > the recording. > > > > Option1 (using new RS Group element): > > If there was a metadata element for an RS Group, RSG1, it could have > > been created containing RS1 at time t1, then referenced at time t3=20 > > to cause RS2 to be added to RSG1 rather than creating RSG2. > > > > Option2 (using globally unique CS ID): > > Alternatively, if SRC1 wants RS1 and RS2 to be considered part of=20 > > the same recording, SRC1 could indicate in both RS1 and RS2 that is=20 > > it CS1 that is being recorded. Since CS1 is globally unique, SRS1=20 > > could recognize this as being an attempt to continue the same recording. > > > > If SRC1 instead prefers to have two separate recordings, SRC1 could=20 > > indicate in RS1 that it is CS1 that is being recorded, and in RS2=20 > > indicate that it is CS2 that is being recorded. CS1 and CS2 may > contain > > the same actual media, but by using different globally unique IDs=20 > > within each RS, SRC1 can force them to be two independent recordings. > > > > In this case, there is no need for an RS Group element, nor is there > > a need for an RS element. > > > > I previously favored Option1. Following the discussion up to and=20 > > including that in the interim meeting, I am okay with Option2. > > > > Cheers, > > Charles > > > > > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From john.elwell@siemens-enterprise.com Tue May 10 09:37: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 406FEE07C6 for ; Tue, 10 May 2011 09:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.475 X-Spam-Level: X-Spam-Status: No, score=-105.475 tagged_above=-999 required=5 tests=[AWL=1.124, 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 yVQZ+aVZQsIz for ; Tue, 10 May 2011 09:37:34 -0700 (PDT) Received: from mail216.messagelabs.com (mail216.messagelabs.com [85.158.143.99]) by ietfa.amsl.com (Postfix) with SMTP id 5D29EE078A for ; Tue, 10 May 2011 09:37:32 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1305045451!4597512!1 X-StarScan-Version: 6.2.16; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 15146 invoked from network); 10 May 2011 16:37:31 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-7.tower-216.messagelabs.com with SMTP; 10 May 2011 16:37:31 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 81F401EB83D3; Tue, 10 May 2011 18:37: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, 10 May 2011 18:37:31 +0200 From: "Elwell, John" To: "Parthasarathi R (partr)" , "Charles Eckel (eckelcu)" , "Ram Mohan R (rmohanr)" , "siprec@ietf.org" Date: Tue, 10 May 2011 18:37:29 +0200 Thread-Topic: [siprec] RS Group / Recording Object issue from interim meeting Thread-Index: AcwOnlUD796ZsvbMTUylbGle0/maUwAOn8yAAAGlS7AAEs9kUAAAhHRQAAC4X4A= Message-ID: References: <35BCE99A477D6A4986FB2216D8CF2CFD06480A28@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 Subject: Re: [siprec] RS Group / Recording Object issue from 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: Tue, 10 May 2011 16:37:35 -0000 This thread looks like it is heading in a direction that is acceptable to m= e. Keeping RS in the model should not necessarily imply that it has to be r= eflected in XML, if the SIP dialog itself is sufficient. John (as individual)=20 > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi R (partr) > Sent: 10 May 2011 17:11 > To: Charles Eckel (eckelcu); Ram Mohan R (rmohanr); siprec@ietf.org > Subject: Re: [siprec] RS Group / Recording Object issue from=20 > interim meeting >=20 > Hi Charles, >=20 > I agree with you to add the text which helps to distinct RS from > recording.=20 >=20 > Thanks > Partha=20 >=20 > -----Original Message----- > From: Charles Eckel (eckelcu)=20 > Sent: Tuesday, May 10, 2011 9:32 PM > To: Parthasarathi R (partr); Ram Mohan R (rmohanr); 'siprec@ietf.org' > Subject: RE: [siprec] RS Group / Recording Object issue from interim > meeting >=20 > Hi Partha, >=20 > The problem for me was that I started thinking of the RS as being > equivalent to a recording. If we leave the RS in the model,=20 > it would be > good to clarify the distinction. >=20 > Cheers, > Charles=20 >=20 >=20 > > -----Original Message----- > > From: Parthasarathi R (partr) > > Sent: Tuesday, May 10, 2011 12:25 AM > > To: Ram Mohan R (rmohanr); Charles Eckel (eckelcu); siprec@ietf.org > > Subject: RE: [siprec] RS Group / Recording Object issue=20 > from interim=20 > > meeting > >=20 > > Charles, > >=20 > > Just adding to Ram mentioned, draft-jones-ipmc-session-id-01=20 > > Session-UUID or draft-kaplan-dispatch- > > session-id-03 Session-id or other proprietary unique-id may=20 > be used in >=20 > > CS to make your proposed solution work. IMO, it is outside the scope > of SIPREC and I favor OPTION 2. > >=20 > > The reason for having RS element in the model is to show the model=20 > > from SRS perspective and in case of metadata format, SIP Message=20 > > information (Dialog-id, Date header) shall be re-used instead of > having separate RS specific XML elements. > >=20 > > Thanks > > Partha > >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > > Behalf Of Ram Mohan R (rmohanr) > > Sent: Tuesday, May 10, 2011 11:50 AM > > To: Charles Eckel (eckelcu); siprec@ietf.org > > Subject: Re: [siprec] RS Group / Recording Object issue=20 > from interim=20 > > meeting > >=20 > > As I mentioned in the meeting yesterday, CS Unique ID=20 > should suffice=20 > > to correlate disparate recordings and hence we don't need RS-Group > element. > > How SRC(s) share this CS Unique ID is something that is=20 > currently left > to implementers(out of scope). > >=20 > > so I favor Option2 > >=20 > > Regards, > > Ram > >=20 > > > -----Original Message----- > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > > > Behalf Of Charles Eckel (eckelcu) > > > Sent: Tuesday, May 10, 2011 4:41 AM > > > To: siprec@ietf.org > > > Subject: [siprec] RS Group / Recording Object issue from interim=20 > > > meeting > > > > > > I am attempting to summarize the discussion we had around this=20 > > > issue, and provide what I understood to be the accepted proposal.=20 > > > First, let me settle on a single term. The term RS Group will be=20 > > > used to mean a collection of RS elements that comprise a single=20 > > > recording. For example, > > > RS1 and RS2 may be two independent sessions that together form a > > single > > > recording. In such a case, the media streams associated=20 > with RS1 and > > > RS2 > > > are combined into a single recording. > > > > > > Question1: Do we need an RS Group element within the=20 > metadata model? > > > Question2: If the answer to Q1 is no, do we need an RS element in=20 > > > the metadata model? > > > > > > Use Cases: > > > t0: UA1 and UA2 establish CS1, and SRC1, which may be co-located=20 > > > with > > > UA1 or UA2 or may be somewhere in between, decides to record CS1 > > > t1: SRC1 establishes RS1 toward SRS1 for the purpose of=20 > starting a=20 > > > new recording. > > > t2: At some point in time, RS1 is terminated for whatever reason > (e.g. > > > network issue, SRS failure, etc.) > > > t3: SRC1 establishes RS2 toward SRS1 for the purpose of=20 > continuing=20 > > > the recording. > > > > > > Option1 (using new RS Group element): > > > If there was a metadata element for an RS Group, RSG1, it=20 > could have >=20 > > > been created containing RS1 at time t1, then referenced=20 > at time t3=20 > > > to cause RS2 to be added to RSG1 rather than creating RSG2. > > > > > > Option2 (using globally unique CS ID): > > > Alternatively, if SRC1 wants RS1 and RS2 to be considered part of=20 > > > the same recording, SRC1 could indicate in both RS1 and=20 > RS2 that is=20 > > > it CS1 that is being recorded. Since CS1 is globally unique, SRS1=20 > > > could recognize this as being an attempt to continue the same > recording. > > > > > > If SRC1 instead prefers to have two separate recordings,=20 > SRC1 could=20 > > > indicate in RS1 that it is CS1 that is being recorded, and in RS2=20 > > > indicate that it is CS2 that is being recorded. CS1 and CS2 may > > contain > > > the same actual media, but by using different globally unique IDs=20 > > > within each RS, SRC1 can force them to be two independent > recordings. > > > > > > In this case, there is no need for an RS Group element,=20 > nor is there >=20 > > > a need for an RS element. > > > > > > I previously favored Option1. Following the discussion up to and=20 > > > including that in the interim meeting, I am okay with Option2. > > > > > > Cheers, > > > Charles > > > > > > > > > > > > _______________________________________________ > > > siprec mailing list > > > siprec@ietf.org > > > https://www.ietf.org/mailman/listinfo/siprec > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > = From rmohanr@cisco.com Tue May 10 09:47: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 E9E84E086B for ; Tue, 10 May 2011 09:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.482 X-Spam-Level: X-Spam-Status: No, score=-10.482 tagged_above=-999 required=5 tests=[AWL=0.117, 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 ei-CFo2wVU2t for ; Tue, 10 May 2011 09:47:32 -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 ED1BCE085E for ; Tue, 10 May 2011 09:47:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=7445; q=dns/txt; s=iport; t=1305046043; x=1306255643; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=ghJMs5he2YI2sPy0ss9NsOxFbJvTCzZk7x1iEYg9cWw=; b=gVxQqm22DYWEBtmOlI0v+Hylc4uHDIrc+CV9R3EyWYL5NH4ywHQ5r1ov CcUJmVPQu9R9bFswMTwNITBz2s36w6+tIyTQCDlJNnbUWtUOe6GIIHSYV kxcLRuw6D2cYKFUs6uREbfy2RGEPjxU0goEvb6omvs7wcgB4VYF6UVUcK U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqsAAOpqyU2Q/khLgWdsb2JhbACXW44wFAEBFiYliHCgCZ5Fhg8EhkCNYIo2 X-IronPort-AV: E=Sophos;i="4.64,346,1301875200"; d="scan'208";a="29552826" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 10 May 2011 16:47:22 +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 p4AGlLn6009648; Tue, 10 May 2011 16:47:21 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 May 2011 22:17: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: Tue, 10 May 2011 22:17:19 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD06480C54@XMB-BGL-417.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] RS Group / Recording Object issue from interim meeting Thread-Index: AcwOnlUD796ZsvbMTUylbGle0/maUwAOn8yAAAGlS7AAEs9kUAAAhHRQAAC4X4AAAGUVEA== References: <35BCE99A477D6A4986FB2216D8CF2CFD06480A28@XMB-BGL-417.cisco.com> From: "Ram Mohan R (rmohanr)" To: "Elwell, John" , "Parthasarathi R (partr)" , "Charles Eckel (eckelcu)" , X-OriginalArrivalTime: 10 May 2011 16:47:20.0594 (UTC) FILETIME=[EDE53F20:01CC0F31] Subject: Re: [siprec] RS Group / Recording Object issue from 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: Tue, 10 May 2011 16:47:34 -0000 Hi John / Charles, I will update the text in metadata model draft (draft-ietf-siprec-metadata-00) in the next revision to reflect this. Here is the text I suggest to be modified in Section 4.1 of draft. Please comment on this and edit/refine the text: Current text is=20 "A Recording Session element represents one instance of a Recording Session." Proposed text is :=20 "A Recording Session element represents the SIP session created between an SRC and SRS for the purpose of recording a Communication Session. The SIP RS dialog SHALL be mapped to this element and hence there is no need for this element to be reflected in XML" Regards, Ram > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Tuesday, May 10, 2011 10:07 PM > To: Parthasarathi R (partr); Charles Eckel (eckelcu); Ram Mohan R > (rmohanr); siprec@ietf.org > Subject: RE: [siprec] RS Group / Recording Object issue from interim > meeting >=20 > This thread looks like it is heading in a direction that is acceptable > to me. Keeping RS in the model should not necessarily imply that it has > to be reflected in XML, if the SIP dialog itself is sufficient. >=20 > John (as individual) >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi R (partr) > > Sent: 10 May 2011 17:11 > > To: Charles Eckel (eckelcu); Ram Mohan R (rmohanr); siprec@ietf.org > > Subject: Re: [siprec] RS Group / Recording Object issue from > > interim meeting > > > > Hi Charles, > > > > I agree with you to add the text which helps to distinct RS from > > recording. > > > > Thanks > > Partha > > > > -----Original Message----- > > From: Charles Eckel (eckelcu) > > Sent: Tuesday, May 10, 2011 9:32 PM > > To: Parthasarathi R (partr); Ram Mohan R (rmohanr); 'siprec@ietf.org' > > Subject: RE: [siprec] RS Group / Recording Object issue from interim > > meeting > > > > Hi Partha, > > > > The problem for me was that I started thinking of the RS as being > > equivalent to a recording. If we leave the RS in the model, > > it would be > > good to clarify the distinction. > > > > Cheers, > > Charles > > > > > > > -----Original Message----- > > > From: Parthasarathi R (partr) > > > Sent: Tuesday, May 10, 2011 12:25 AM > > > To: Ram Mohan R (rmohanr); Charles Eckel (eckelcu); siprec@ietf.org > > > Subject: RE: [siprec] RS Group / Recording Object issue > > from interim > > > meeting > > > > > > Charles, > > > > > > Just adding to Ram mentioned, draft-jones-ipmc-session-id-01 > > > Session-UUID or draft-kaplan-dispatch- > > > session-id-03 Session-id or other proprietary unique-id may > > be used in > > > > > CS to make your proposed solution work. IMO, it is outside the > scope > > of SIPREC and I favor OPTION 2. > > > > > > The reason for having RS element in the model is to show the model > > > from SRS perspective and in case of metadata format, SIP Message > > > information (Dialog-id, Date header) shall be re-used instead of > > having separate RS specific XML elements. > > > > > > Thanks > > > Partha > > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > > Behalf Of Ram Mohan R (rmohanr) > > > Sent: Tuesday, May 10, 2011 11:50 AM > > > To: Charles Eckel (eckelcu); siprec@ietf.org > > > Subject: Re: [siprec] RS Group / Recording Object issue > > from interim > > > meeting > > > > > > As I mentioned in the meeting yesterday, CS Unique ID > > should suffice > > > to correlate disparate recordings and hence we don't need RS-Group > > element. > > > How SRC(s) share this CS Unique ID is something that is > > currently left > > to implementers(out of scope). > > > > > > so I favor Option2 > > > > > > Regards, > > > Ram > > > > > > > -----Original Message----- > > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > > > Behalf Of Charles Eckel (eckelcu) > > > > Sent: Tuesday, May 10, 2011 4:41 AM > > > > To: siprec@ietf.org > > > > Subject: [siprec] RS Group / Recording Object issue from interim > > > > meeting > > > > > > > > I am attempting to summarize the discussion we had around this > > > > issue, and provide what I understood to be the accepted proposal. > > > > First, let me settle on a single term. The term RS Group will be > > > > used to mean a collection of RS elements that comprise a single > > > > recording. For example, > > > > RS1 and RS2 may be two independent sessions that together form a > > > single > > > > recording. In such a case, the media streams associated > > with RS1 and > > > > RS2 > > > > are combined into a single recording. > > > > > > > > Question1: Do we need an RS Group element within the > > metadata model? > > > > Question2: If the answer to Q1 is no, do we need an RS element in > > > > the metadata model? > > > > > > > > Use Cases: > > > > t0: UA1 and UA2 establish CS1, and SRC1, which may be co-located > > > > with > > > > UA1 or UA2 or may be somewhere in between, decides to record CS1 > > > > t1: SRC1 establishes RS1 toward SRS1 for the purpose of > > starting a > > > > new recording. > > > > t2: At some point in time, RS1 is terminated for whatever reason > > (e.g. > > > > network issue, SRS failure, etc.) > > > > t3: SRC1 establishes RS2 toward SRS1 for the purpose of > > continuing > > > > the recording. > > > > > > > > Option1 (using new RS Group element): > > > > If there was a metadata element for an RS Group, RSG1, it > > could have > > > > > > been created containing RS1 at time t1, then referenced > > at time t3 > > > > to cause RS2 to be added to RSG1 rather than creating RSG2. > > > > > > > > Option2 (using globally unique CS ID): > > > > Alternatively, if SRC1 wants RS1 and RS2 to be considered part of > > > > the same recording, SRC1 could indicate in both RS1 and > > RS2 that is > > > > it CS1 that is being recorded. Since CS1 is globally unique, SRS1 > > > > could recognize this as being an attempt to continue the same > > recording. > > > > > > > > If SRC1 instead prefers to have two separate recordings, > > SRC1 could > > > > indicate in RS1 that it is CS1 that is being recorded, and in RS2 > > > > indicate that it is CS2 that is being recorded. CS1 and CS2 may > > > contain > > > > the same actual media, but by using different globally unique IDs > > > > within each RS, SRC1 can force them to be two independent > > recordings. > > > > > > > > In this case, there is no need for an RS Group element, > > nor is there > > > > > > a need for an RS element. > > > > > > > > I previously favored Option1. Following the discussion up to and > > > > including that in the interim meeting, I am okay with Option2. > > > > > > > > Cheers, > > > > Charles > > > > > > > > > > > > > > > > _______________________________________________ > > > > siprec mailing list > > > > siprec@ietf.org > > > > https://www.ietf.org/mailman/listinfo/siprec > > > _______________________________________________ > > > siprec mailing list > > > siprec@ietf.org > > > https://www.ietf.org/mailman/listinfo/siprec > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > > From eckelcu@cisco.com Tue May 10 10:39:28 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 756F9E08ED for ; Tue, 10 May 2011 10:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.367 X-Spam-Level: X-Spam-Status: No, score=-10.367 tagged_above=-999 required=5 tests=[AWL=0.232, 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 8kYr+PAC8WSm for ; Tue, 10 May 2011 10:39:27 -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 49C3DE08EE for ; Tue, 10 May 2011 10:39:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=8324; q=dns/txt; s=iport; t=1305049167; x=1306258767; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=9vN8Qcduj6m0l7YWG35DXi2QDvj2ZJcbidOlZ9tVva4=; b=Cvd3RE2eszvvYgOCawS53MyJq7//aVX9CxRQh6K58+HxAKK5odnh8rP7 81IOgxJctFyHdwq932uFwu4jXnOr5s/s0aBblyHZFZCq0Fpno2vj1w7Od LNwho+XPNV5Etay4jQI4PfoHYU68gGroVIqwmnK4IrDzVhKPwvzehQauR o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwBAF93yU2rRDoG/2dsb2JhbACXW44wd4hwoCKeRIYPBIZCjV6KTg X-IronPort-AV: E=Sophos;i="4.64,346,1301875200"; d="scan'208";a="695028598" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-6.cisco.com with ESMTP; 10 May 2011 17:39:26 +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 p4AHdRdL029150; Tue, 10 May 2011 17:39:27 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 May 2011 10:39: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: Tue, 10 May 2011 10:39:25 -0700 Message-ID: In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD06480C54@XMB-BGL-417.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] RS Group / Recording Object issue from interim meeting Thread-Index: AcwOnlUD796ZsvbMTUylbGle0/maUwAOn8yAAAGlS7AAEs9kUAAAhHRQAAC4X4AAAGUVEAAB8S1A References: <35BCE99A477D6A4986FB2216D8CF2CFD06480A28@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD06480C54@XMB-BGL-417.cisco.com> From: "Charles Eckel (eckelcu)" To: "Ram Mohan R (rmohanr)" , "Elwell, John" , "Parthasarathi R (partr)" , X-OriginalArrivalTime: 10 May 2011 17:39:26.0961 (UTC) FILETIME=[355AFE10:01CC0F39] Subject: Re: [siprec] RS Group / Recording Object issue from 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: Tue, 10 May 2011 17:39:28 -0000 The proposed text works better for me if you change both instances of "the" to "a" to remain consistent with the many to many relationship of CS to RS. Cheers, Charles > -----Original Message----- > From: Ram Mohan R (rmohanr) > Sent: Tuesday, May 10, 2011 9:47 AM > To: Elwell, John; Parthasarathi R (partr); Charles Eckel (eckelcu); siprec@ietf.org > Subject: RE: [siprec] RS Group / Recording Object issue from interim meeting >=20 > Hi John / Charles, >=20 > I will update the text in metadata model draft (draft-ietf-siprec-metadata-00) in the next revision to > reflect this. >=20 > Here is the text I suggest to be modified in Section 4.1 of draft. Please comment on this and > edit/refine the text: >=20 > Current text is > "A Recording Session element represents one instance of a Recording Session." >=20 > Proposed text is : > "A Recording Session element represents the SIP session created between an SRC and SRS for the purpose > of recording a Communication Session. The SIP RS dialog SHALL be mapped to this element and hence > there is no need for this element to be reflected in XML" >=20 > Regards, > Ram >=20 > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Tuesday, May 10, 2011 10:07 PM > > To: Parthasarathi R (partr); Charles Eckel (eckelcu); Ram Mohan R > > (rmohanr); siprec@ietf.org > > Subject: RE: [siprec] RS Group / Recording Object issue from interim > > meeting > > > > This thread looks like it is heading in a direction that is acceptable > > to me. Keeping RS in the model should not necessarily imply that it has > > to be reflected in XML, if the SIP dialog itself is sufficient. > > > > John (as individual) > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi R (partr) > > > Sent: 10 May 2011 17:11 > > > To: Charles Eckel (eckelcu); Ram Mohan R (rmohanr); siprec@ietf.org > > > Subject: Re: [siprec] RS Group / Recording Object issue from > > > interim meeting > > > > > > Hi Charles, > > > > > > I agree with you to add the text which helps to distinct RS from > > > recording. > > > > > > Thanks > > > Partha > > > > > > -----Original Message----- > > > From: Charles Eckel (eckelcu) > > > Sent: Tuesday, May 10, 2011 9:32 PM > > > To: Parthasarathi R (partr); Ram Mohan R (rmohanr); 'siprec@ietf.org' > > > Subject: RE: [siprec] RS Group / Recording Object issue from interim > > > meeting > > > > > > Hi Partha, > > > > > > The problem for me was that I started thinking of the RS as being > > > equivalent to a recording. If we leave the RS in the model, > > > it would be > > > good to clarify the distinction. > > > > > > Cheers, > > > Charles > > > > > > > > > > -----Original Message----- > > > > From: Parthasarathi R (partr) > > > > Sent: Tuesday, May 10, 2011 12:25 AM > > > > To: Ram Mohan R (rmohanr); Charles Eckel (eckelcu); siprec@ietf.org > > > > Subject: RE: [siprec] RS Group / Recording Object issue > > > from interim > > > > meeting > > > > > > > > Charles, > > > > > > > > Just adding to Ram mentioned, draft-jones-ipmc-session-id-01 > > > > Session-UUID or draft-kaplan-dispatch- > > > > session-id-03 Session-id or other proprietary unique-id may > > > be used in > > > > > > > CS to make your proposed solution work. IMO, it is outside the > > scope > > > of SIPREC and I favor OPTION 2. > > > > > > > > The reason for having RS element in the model is to show the model > > > > from SRS perspective and in case of metadata format, SIP Message > > > > information (Dialog-id, Date header) shall be re-used instead of > > > having separate RS specific XML elements. > > > > > > > > Thanks > > > > Partha > > > > > > > > -----Original Message----- > > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > > > Behalf Of Ram Mohan R (rmohanr) > > > > Sent: Tuesday, May 10, 2011 11:50 AM > > > > To: Charles Eckel (eckelcu); siprec@ietf.org > > > > Subject: Re: [siprec] RS Group / Recording Object issue > > > from interim > > > > meeting > > > > > > > > As I mentioned in the meeting yesterday, CS Unique ID > > > should suffice > > > > to correlate disparate recordings and hence we don't need RS-Group > > > element. > > > > How SRC(s) share this CS Unique ID is something that is > > > currently left > > > to implementers(out of scope). > > > > > > > > so I favor Option2 > > > > > > > > Regards, > > > > Ram > > > > > > > > > -----Original Message----- > > > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > > > > Behalf Of Charles Eckel (eckelcu) > > > > > Sent: Tuesday, May 10, 2011 4:41 AM > > > > > To: siprec@ietf.org > > > > > Subject: [siprec] RS Group / Recording Object issue from interim > > > > > meeting > > > > > > > > > > I am attempting to summarize the discussion we had around this > > > > > issue, and provide what I understood to be the accepted proposal. > > > > > First, let me settle on a single term. The term RS Group will be > > > > > used to mean a collection of RS elements that comprise a single > > > > > recording. For example, > > > > > RS1 and RS2 may be two independent sessions that together form a > > > > single > > > > > recording. In such a case, the media streams associated > > > with RS1 and > > > > > RS2 > > > > > are combined into a single recording. > > > > > > > > > > Question1: Do we need an RS Group element within the > > > metadata model? > > > > > Question2: If the answer to Q1 is no, do we need an RS element in > > > > > the metadata model? > > > > > > > > > > Use Cases: > > > > > t0: UA1 and UA2 establish CS1, and SRC1, which may be co-located > > > > > with > > > > > UA1 or UA2 or may be somewhere in between, decides to record CS1 > > > > > t1: SRC1 establishes RS1 toward SRS1 for the purpose of > > > starting a > > > > > new recording. > > > > > t2: At some point in time, RS1 is terminated for whatever reason > > > (e.g. > > > > > network issue, SRS failure, etc.) > > > > > t3: SRC1 establishes RS2 toward SRS1 for the purpose of > > > continuing > > > > > the recording. > > > > > > > > > > Option1 (using new RS Group element): > > > > > If there was a metadata element for an RS Group, RSG1, it > > > could have > > > > > > > > been created containing RS1 at time t1, then referenced > > > at time t3 > > > > > to cause RS2 to be added to RSG1 rather than creating RSG2. > > > > > > > > > > Option2 (using globally unique CS ID): > > > > > Alternatively, if SRC1 wants RS1 and RS2 to be considered part of > > > > > the same recording, SRC1 could indicate in both RS1 and > > > RS2 that is > > > > > it CS1 that is being recorded. Since CS1 is globally unique, SRS1 > > > > > could recognize this as being an attempt to continue the same > > > recording. > > > > > > > > > > If SRC1 instead prefers to have two separate recordings, > > > SRC1 could > > > > > indicate in RS1 that it is CS1 that is being recorded, and in RS2 > > > > > indicate that it is CS2 that is being recorded. CS1 and CS2 may > > > > contain > > > > > the same actual media, but by using different globally unique IDs > > > > > within each RS, SRC1 can force them to be two independent > > > recordings. > > > > > > > > > > In this case, there is no need for an RS Group element, > > > nor is there > > > > > > > > a need for an RS element. > > > > > > > > > > I previously favored Option1. Following the discussion up to and > > > > > including that in the interim meeting, I am okay with Option2. > > > > > > > > > > Cheers, > > > > > Charles > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > siprec mailing list > > > > > siprec@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > _______________________________________________ > > > > siprec mailing list > > > > siprec@ietf.org > > > > https://www.ietf.org/mailman/listinfo/siprec > > > _______________________________________________ > > > siprec mailing list > > > siprec@ietf.org > > > https://www.ietf.org/mailman/listinfo/siprec > > > From Leon.Portman@nice.com Tue May 10 10:52:55 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC9D3E06FB for ; Tue, 10 May 2011 10:52:55 -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.168, 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 v0gSJ1b9dYPw for ; Tue, 10 May 2011 10:52:54 -0700 (PDT) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id 36CFFE067C for ; Tue, 10 May 2011 10:52:53 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Tue, 10 May 2011 20:52:52 +0300 From: Leon Portman To: "Charles Eckel (eckelcu)" , "Ram Mohan R (rmohanr)" , "Elwell, John" , "Parthasarathi R (partr)" , "siprec@ietf.org" Date: Tue, 10 May 2011 20:52:48 +0300 Thread-Topic: [siprec] RS Group / Recording Object issue from interim meeting Thread-Index: AcwOnlUD796ZsvbMTUylbGle0/maUwAOn8yAAAGlS7AAEs9kUAAAhHRQAAC4X4AAAGUVEAAB8S1AAAB6WcA= Message-ID: <07465C1D981ABC41A344374066AE1A2C38AB848F1D@TLVMBX01.nice.com> References: <35BCE99A477D6A4986FB2216D8CF2CFD06480A28@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD06480C54@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 Subject: Re: [siprec] RS Group / Recording Object issue from 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: Tue, 10 May 2011 17:52:56 -0000 I agree with below. Just additional comment that the actual fact how record= ings are stored in the file system; one file or multiple chunks are impleme= ntation details of SRS. What is important that SRS will have all relevant i= nformation (like unique CS ID) to be able to find, display and of course pl= ayback all relevant RS pieces Leon -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Charles Eckel (eckelcu) Sent: Tuesday, May 10, 2011 8:39 PM To: Ram Mohan R (rmohanr); Elwell, John; Parthasarathi R (partr); siprec@ie= tf.org Subject: Re: [siprec] RS Group / Recording Object issue from interim meetin= g The proposed text works better for me if you change both instances of "the"= to "a" to remain consistent with the many to many relationship of CS to RS= . Cheers, Charles > -----Original Message----- > From: Ram Mohan R (rmohanr) > Sent: Tuesday, May 10, 2011 9:47 AM > To: Elwell, John; Parthasarathi R (partr); Charles Eckel (eckelcu); siprec@ietf.org > Subject: RE: [siprec] RS Group / Recording Object issue from interim meeting >=20 > Hi John / Charles, >=20 > I will update the text in metadata model draft (draft-ietf-siprec-metadata-00) in the next revision to > reflect this. >=20 > Here is the text I suggest to be modified in Section 4.1 of draft. Please comment on this and > edit/refine the text: >=20 > Current text is > "A Recording Session element represents one instance of a Recording Session." >=20 > Proposed text is : > "A Recording Session element represents the SIP session created between an SRC and SRS for the purpose > of recording a Communication Session. The SIP RS dialog SHALL be mapped to this element and hence > there is no need for this element to be reflected in XML" >=20 > Regards, > Ram >=20 > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Tuesday, May 10, 2011 10:07 PM > > To: Parthasarathi R (partr); Charles Eckel (eckelcu); Ram Mohan R=20 > > (rmohanr); siprec@ietf.org > > Subject: RE: [siprec] RS Group / Recording Object issue from interim=20 > > meeting > > > > This thread looks like it is heading in a direction that is acceptable > > to me. Keeping RS in the model should not necessarily imply that it has > > to be reflected in XML, if the SIP dialog itself is sufficient. > > > > John (as individual) > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi R (partr) > > > Sent: 10 May 2011 17:11 > > > To: Charles Eckel (eckelcu); Ram Mohan R (rmohanr); siprec@ietf.org > > > Subject: Re: [siprec] RS Group / Recording Object issue from=20 > > > interim meeting > > > > > > Hi Charles, > > > > > > I agree with you to add the text which helps to distinct RS from=20 > > > recording. > > > > > > Thanks > > > Partha > > > > > > -----Original Message----- > > > From: Charles Eckel (eckelcu) > > > Sent: Tuesday, May 10, 2011 9:32 PM > > > To: Parthasarathi R (partr); Ram Mohan R (rmohanr); 'siprec@ietf.org' > > > Subject: RE: [siprec] RS Group / Recording Object issue from interim > > > meeting > > > > > > Hi Partha, > > > > > > The problem for me was that I started thinking of the RS as being=20 > > > equivalent to a recording. If we leave the RS in the model, it=20 > > > would be good to clarify the distinction. > > > > > > Cheers, > > > Charles > > > > > > > > > > -----Original Message----- > > > > From: Parthasarathi R (partr) > > > > Sent: Tuesday, May 10, 2011 12:25 AM > > > > To: Ram Mohan R (rmohanr); Charles Eckel (eckelcu); siprec@ietf.org > > > > Subject: RE: [siprec] RS Group / Recording Object issue > > > from interim > > > > meeting > > > > > > > > Charles, > > > > > > > > Just adding to Ram mentioned, draft-jones-ipmc-session-id-01=20 > > > > Session-UUID or draft-kaplan-dispatch- > > > > session-id-03 Session-id or other proprietary unique-id may > > > be used in > > > > > > > CS to make your proposed solution work. IMO, it is outside the > > scope > > > of SIPREC and I favor OPTION 2. > > > > > > > > The reason for having RS element in the model is to show the model > > > > from SRS perspective and in case of metadata format, SIP Message=20 > > > > information (Dialog-id, Date header) shall be re-used instead of > > > having separate RS specific XML elements. > > > > > > > > Thanks > > > > Partha > > > > > > > > -----Original Message----- > > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > > > Behalf Of Ram Mohan R (rmohanr) > > > > Sent: Tuesday, May 10, 2011 11:50 AM > > > > To: Charles Eckel (eckelcu); siprec@ietf.org > > > > Subject: Re: [siprec] RS Group / Recording Object issue > > > from interim > > > > meeting > > > > > > > > As I mentioned in the meeting yesterday, CS Unique ID > > > should suffice > > > > to correlate disparate recordings and hence we don't need RS-Group > > > element. > > > > How SRC(s) share this CS Unique ID is something that is > > > currently left > > > to implementers(out of scope). > > > > > > > > so I favor Option2 > > > > > > > > Regards, > > > > Ram > > > > > > > > > -----Original Message----- > > > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > > > > Behalf Of Charles Eckel (eckelcu) > > > > > Sent: Tuesday, May 10, 2011 4:41 AM > > > > > To: siprec@ietf.org > > > > > Subject: [siprec] RS Group / Recording Object issue from interim > > > > > meeting > > > > > > > > > > I am attempting to summarize the discussion we had around this=20 > > > > > issue, and provide what I understood to be the accepted proposal. > > > > > First, let me settle on a single term. The term RS Group will be > > > > > used to mean a collection of RS elements that comprise a single > > > > > recording. For example, > > > > > RS1 and RS2 may be two independent sessions that together form a > > > > single > > > > > recording. In such a case, the media streams associated > > > with RS1 and > > > > > RS2 > > > > > are combined into a single recording. > > > > > > > > > > Question1: Do we need an RS Group element within the > > > metadata model? > > > > > Question2: If the answer to Q1 is no, do we need an RS element in > > > > > the metadata model? > > > > > > > > > > Use Cases: > > > > > t0: UA1 and UA2 establish CS1, and SRC1, which may be co-located > > > > > with > > > > > UA1 or UA2 or may be somewhere in between, decides to record CS1 > > > > > t1: SRC1 establishes RS1 toward SRS1 for the purpose of > > > starting a > > > > > new recording. > > > > > t2: At some point in time, RS1 is terminated for whatever reason > > > (e.g. > > > > > network issue, SRS failure, etc.) > > > > > t3: SRC1 establishes RS2 toward SRS1 for the purpose of > > > continuing > > > > > the recording. > > > > > > > > > > Option1 (using new RS Group element): > > > > > If there was a metadata element for an RS Group, RSG1, it > > > could have > > > > > > > > been created containing RS1 at time t1, then referenced > > > at time t3 > > > > > to cause RS2 to be added to RSG1 rather than creating RSG2. > > > > > > > > > > Option2 (using globally unique CS ID): > > > > > Alternatively, if SRC1 wants RS1 and RS2 to be considered part of > > > > > the same recording, SRC1 could indicate in both RS1 and > > > RS2 that is > > > > > it CS1 that is being recorded. Since CS1 is globally unique, SRS1 > > > > > could recognize this as being an attempt to continue the same > > > recording. > > > > > > > > > > If SRC1 instead prefers to have two separate recordings, > > > SRC1 could > > > > > indicate in RS1 that it is CS1 that is being recorded, and in RS2 > > > > > indicate that it is CS2 that is being recorded. CS1 and CS2 may > > > > contain > > > > > the same actual media, but by using different globally unique IDs > > > > > within each RS, SRC1 can force them to be two independent > > > recordings. > > > > > > > > > > In this case, there is no need for an RS Group element, > > > nor is there > > > > > > > > a need for an RS element. > > > > > > > > > > I previously favored Option1. Following the discussion up to and > > > > > including that in the interim meeting, I am okay with Option2. > > > > > > > > > > Cheers, > > > > > Charles > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > siprec mailing list > > > > > siprec@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > _______________________________________________ > > > > siprec mailing list > > > > siprec@ietf.org > > > > https://www.ietf.org/mailman/listinfo/siprec > > > _______________________________________________ > > > siprec mailing 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 May 10 10:53: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 66553E073D for ; Tue, 10 May 2011 10:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.162, 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 D8mA6lRJ1vFW for ; Tue, 10 May 2011 10:53:19 -0700 (PDT) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id DFB32E067C for ; Tue, 10 May 2011 10:53:18 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Tue, 10 May 2011 20:53:17 +0300 From: Leon Portman To: "Charles Eckel (eckelcu)" , "Paul Kyzivat (pkyzivat)" , "siprec@ietf.org" Date: Tue, 10 May 2011 20:53:14 +0300 Thread-Topic: [siprec] Multiple recordings of the same CS/CSG... Thread-Index: AcwOstC8OBE753XYSXagrL3WGZkVXAAd2GbwAAQ7r2A= Message-ID: <07465C1D981ABC41A344374066AE1A2C38AB848F1E@TLVMBX01.nice.com> References: <4DC896CA.6070802@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] Multiple recordings of the same CS/CSG... X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 10 May 2011 17:53:20 -0000 +1 Leon -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Charles Eckel (eckelcu) Sent: Tuesday, May 10, 2011 6:54 PM To: Paul Kyzivat (pkyzivat); siprec@ietf.org Subject: Re: [siprec] Multiple recordings of the same CS/CSG... I agree. > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat (pkyzivat) > Sent: Monday, May 09, 2011 6:37 PM > To: siprec@ietf.org > Subject: [siprec] Multiple recordings of the same CS/CSG... >=20 > During the call today we got into a discussion of the=20 > pros/cons/mechanisms for achieving multiple recordings of the same CS or > CSG. >=20 > I'm pretty sure this was initially posed as a potential requirement by=20 > Charles Eckel in: > http://www.ietf.org/mail-archive/web/siprec/current/msg01876.html >=20 > Paraphrasing, the argument is that two different participants in a CS,=20 > possibly with different SRCs, may both want to record the CS, and have=20 > control over *how* it is recorded. For instance, one may want to do its > own mixing of the media streams and send the mix to the SRS for=20 > recording. It might also transcode, affecting the fidelity of the=20 > recording. Another participant might want all the streams recorded=20 > independently so they may later be analyzed separately. >=20 > It isn't immediately apparent if this sort of operation is possible with > the current model. Superficially it seems it is not. >=20 > One question is whether this is something important to address. (If it=20 > happens to fall out without extra work then probably nobody will object, > but if its extra work, then its something we really need to decide.) >=20 > Its my assertion that from a practical perspective this sort of behavior > can be achieved with the model we have, as follows: >=20 > The mechanism currently on the table has each SRC assigning globally=20 > unique IDs for each CS, CSG, and various other things. This is still=20 > under debate, but whatever things don't end of having a globally unique > id will almost certainly be scoped within something that does. >=20 > Unless they go to some effort to coordinate, two SRCs involved with the > "same" CS will each assign their own unique id to it. When the SRC=20 > receives metadata, this CS will appear to it as two independent CSs. > Hence, *by default* there will be two independent recordings. >=20 > If two SRCs what something different from that, they can potentially=20 > achieve it by coordinating unique id assignments among themselves. I am > not proposing that we define a way to do that - at least for now it=20 > would be something proprietary between them. A "simple" example could be > a fault-tolerant pair of SRCs that coordinate so that if one fails the=20 > other can take over and continue the recording. Here the pair would be=20 > coordinating a lot of sip knowledge in addition to the uuids. >=20 > *If* some SRCs are coordinating their uuid assigments, and if there are > cases where they want to cause independent recordings to be made, then=20 > they can achieve that by simply *not* using the same uuid for a CS. Of=20 > course this opens up a whole can of worms about how they decide when=20 > they want to be part of the same recording and when not. But we don't=20 > need to get into that - it is their problem to solve. >=20 > AFAIK this ought to be sufficient for addressing Charle' problem. > Discussion welcome. >=20 > 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 May 10 23:56: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 51FE7E0766 for ; Tue, 10 May 2011 23:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ut+SDgbhegWX for ; Tue, 10 May 2011 23:56:40 -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 06299E066A for ; Tue, 10 May 2011 23:56:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=5252; q=dns/txt; s=iport; t=1305097000; x=1306306600; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=gvqkA5r839CMPiAEs01Fb2IclIG/y0ahbTjGzsSredc=; b=fbKqMWPgqpR7AnRv9GDjwW6gp9whZN8WzNj1ooRTZVS/ig2C2UolI0Lz 1DwMmWIA9XKjBpIOWbkC7OpQQOHYlQBtdzRqB2DUJNoEwX+cy+9VCmYHP GSEeRtoJxMFVhDU3SIFmV+nvTKyRPahtNkUuQ0JPw+uEuPkQysSBaxI+y 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8AAGMyyk2Q/khRgWdsb2JhbACXW44uFAEBFiYlqHCeD4YQBIZBjV+KOQ X-IronPort-AV: E=Sophos;i="4.64,350,1301875200"; d="scan'208";a="87843053" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 11 May 2011 06:56:39 +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 p4B6uK2q018610 for ; Wed, 11 May 2011 06:56:38 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, 11 May 2011 12:26: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, 11 May 2011 12:26:35 +0530 Message-ID: <1D062974A4845E4D8A343C65380492020561B298@XMB-BGL-414.cisco.com> In-Reply-To: <4DC91259.2030106@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Multiple recordings of the same CS/CSG... Thread-Index: AcwO/HQDXthoetj2TaekzcdGyoSrYAAn0v+g References: <4DC896CA.6070802@cisco.com> <1D062974A4845E4D8A343C65380492020561AF0F@XMB-BGL-414.cisco.com> <4DC91259.2030106@cisco.com> From: "Muthu ArulMozhi Perumal (mperumal)" To: "Paul Kyzivat (pkyzivat)" X-OriginalArrivalTime: 11 May 2011 06:56:37.0129 (UTC) FILETIME=[925B6F90:01CC0FA8] Cc: siprec@ietf.org Subject: Re: [siprec] Multiple recordings of the same CS/CSG... X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 06:56:41 -0000 That should work.. thanks, Muthu |-----Original Message----- |From: Paul Kyzivat (pkyzivat) |Sent: Tuesday, May 10, 2011 3:54 PM |To: Muthu ArulMozhi Perumal (mperumal) |Cc: siprec@ietf.org |Subject: Re: [siprec] Multiple recordings of the same CS/CSG... | |Muthu, | |If the SRCs *know* they will want to coordinate in this case there a |number of ways they could use the currently proposed mechanisms to |achieve that. | |For example, a uuid could be assigned as part of the predefined meeting |state. Then each SRC could use this uuid as a CSG id. Each connection to |the focus could be defined with a unique CS id within the common CSG id. | | Thanks, | Paul | |On 5/10/2011 1:17 AM, Muthu ArulMozhi Perumal (mperumal) wrote: |> This looks a pragmatic use-case and it seems at times it may need no |> coordination among the SRCs at all to come up with such a unique ID |> because it is reserved/distributed well ahead. Consider a meeting where |> participants join from different geographic regions and each region has |> an SRC performing mixing and recording of media streams generated by the |> participants from that region. The meeting has a meeting ID reserved in |> advance and each participant joins the meeting hosted at the SRC in that |> region. The SRS can use the meeting ID to correlate these disparate |> recordings. |> |> However, it looks it would be a real challenge for the SRS to be able to |> synchronously playback these disparate recording -- this doesn't look a |> trivial problem to solve. |> |> In essence, I agree we need a unique ID to address these use-cases. But, |> the system should try to minimize the number of unique IDs needed. |> |> Muthu |> |> |-----Original Message----- |> |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On |> Behalf Of Paul Kyzivat (pkyzivat) |> |Sent: Tuesday, May 10, 2011 7:07 AM |> |To: siprec@ietf.org |> |Subject: [siprec] Multiple recordings of the same CS/CSG... |> | |> |During the call today we got into a discussion of the |> |pros/cons/mechanisms for achieving multiple recordings of the same CS |> or |> |CSG. |> | |> |I'm pretty sure this was initially posed as a potential requirement by |> |Charles Eckel in: |> |http://www.ietf.org/mail-archive/web/siprec/current/msg01876.html |> | |> |Paraphrasing, the argument is that two different participants in a CS, |> |possibly with different SRCs, may both want to record the CS, and have |> |control over *how* it is recorded. For instance, one may want to do its |> |own mixing of the media streams and send the mix to the SRS for |> |recording. It might also transcode, affecting the fidelity of the |> |recording. Another participant might want all the streams recorded |> |independently so they may later be analyzed separately. |> | |> |It isn't immediately apparent if this sort of operation is possible |> with |> |the current model. Superficially it seems it is not. |> | |> |One question is whether this is something important to address. (If it |> |happens to fall out without extra work then probably nobody will |> object, |> |but if its extra work, then its something we really need to decide.) |> | |> |Its my assertion that from a practical perspective this sort of |> behavior |> |can be achieved with the model we have, as follows: |> | |> |The mechanism currently on the table has each SRC assigning globally |> |unique IDs for each CS, CSG, and various other things. This is still |> |under debate, but whatever things don't end of having a globally unique |> |id will almost certainly be scoped within something that does. |> | |> |Unless they go to some effort to coordinate, two SRCs involved with the |> |"same" CS will each assign their own unique id to it. When the SRC |> |receives metadata, this CS will appear to it as two independent CSs. |> |Hence, *by default* there will be two independent recordings. |> | |> |If two SRCs what something different from that, they can potentially |> |achieve it by coordinating unique id assignments among themselves. I am |> |not proposing that we define a way to do that - at least for now it |> |would be something proprietary between them. A "simple" example could |> be |> |a fault-tolerant pair of SRCs that coordinate so that if one fails the |> |other can take over and continue the recording. Here the pair would be |> |coordinating a lot of sip knowledge in addition to the uuids. |> | |> |*If* some SRCs are coordinating their uuid assigments, and if there are |> |cases where they want to cause independent recordings to be made, then |> |they can achieve that by simply *not* using the same uuid for a CS. Of |> |course this opens up a whole can of worms about how they decide when |> |they want to be part of the same recording and when not. But we don't |> |need to get into that - it is their problem to solve. |> | |> |AFAIK this ought to be sufficient for addressing Charle' problem. |> |Discussion welcome. |> | |> | Thanks, |> | Paul |> |_______________________________________________ |> |siprec mailing list |> |siprec@ietf.org |> |https://www.ietf.org/mailman/listinfo/siprec |> From rmohanr@cisco.com Wed May 11 00:22:05 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 78406E067B for ; Wed, 11 May 2011 00:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.74 X-Spam-Level: X-Spam-Status: No, score=-8.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 w+nZA6aMUrSF for ; Wed, 11 May 2011 00:22:03 -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 F2F0DE0665 for ; Wed, 11 May 2011 00:22:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=26045; q=dns/txt; s=iport; t=1305098522; x=1306308122; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=7KcU9gsj8zKgCo6CadTf6q3OeYyIGyJqAJbD5uq3RK0=; b=dY/rYk/56IfRgU5m8S9Prnrfz0yrXGW1VFNHt3Eslv7CeXNOOU14ybbP oroYUgZEXjaFLaZW9YeTi51XRL+oNYVBye16rraYKcJfN5/6p2O3bxJvJ W5+p6n9Q32uLTMaRuhN+yNmjjLz5v9epXhV1/PQLsfF48FEXVWldTrzG4 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8AAHI4yk2Q/khMgWdsb2JhbACXW44uFAEBFiYliHCff54QgwyDBASGQY1fijk X-IronPort-AV: E=Sophos;i="4.64,350,1301875200"; d="scan'208";a="87848725" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 11 May 2011 07:22:00 +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 p4B7LiaQ031923; Wed, 11 May 2011 07:22:00 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, 11 May 2011 12:51:54 +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, 11 May 2011 12:51:52 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD06480E2F@XMB-BGL-417.cisco.com> In-Reply-To: <07465C1D981ABC41A344374066AE1A2C38AB7A20DB@TLVMBX01.nice.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: AcwFuuvxdSy9/XTRSVq5DE/JiXPmDAAAgTPwAnuoqVA= 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> <07465C1D981ABC41A344374066 AE1A2C38 AB7A20DB@TLVMBX01.nice.com> From: "Ram Mohan R (rmohanr)" To: "Leon Portman" , "Paul Kyzivat (pkyzivat)" , "Henry Lum" X-OriginalArrivalTime: 11 May 2011 07:21:54.0779 (UTC) FILETIME=[1AF272B0:01CC0FAC] 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, 11 May 2011 07:22:05 -0000 Hello All, As per the discussions in last meeting and below mail thread it appears that we would need global ID to take care of all the cases. However there is a disagreement with some folks in having a unique ID. I would request people to respond on this mail thread and take this issue to closure. If no one has issues, we will go with globally Unique ID for MS block. Regards, Ram > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Leon Portman > Sent: Thursday, April 28, 2011 9:28 PM > To: Paul Kyzivat (pkyzivat); Henry Lum > 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 > I agree that we should have all IDs to be globally unique. >=20 > Leon >=20 > -----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: comments on draft-ram-siprec-metadata-04) >=20 >=20 >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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.) >=20 > Thanks, > Paul >=20 > > 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 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 May 11 06:32:02 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC45E067E for ; Wed, 11 May 2011 06:32: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, 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 3ezei4tldVcn for ; Wed, 11 May 2011 06:32:01 -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 6B7ADE0680 for ; Wed, 11 May 2011 06:31:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=42055; q=dns/txt; s=iport; t=1305120720; x=1306330320; h=mime-version:subject:date:message-id:from:to; bh=iki9qri0XnNZTa8IbMT6D3/+t4U/9pgfzqR+jhcTCm8=; b=js7ho3TkdMsyQ3opOHW02v2dgpcPbje9q2RSbED3JZivZF+2cyFk2hGr qsu8xn2dUWxSaztC5ElsKqCrxspSLFXzJHLDB/cp+ZMw9Ho6CBda3GNNw WPXi3VhU0gbu7fb1vgpvgJUiagfT8VhcOmjKl44xuyamkCSAYiY7cB1zO o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQEAOKOyk2Q/khMgWdsb2JhbACCZKMiFAEBFiYlqHmBHZ4ahhAEhkGNX4o5 X-IronPort-AV: E=Sophos;i="4.64,353,1301875200"; d="scan'208,217";a="29724359" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 11 May 2011 13:31:59 +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 p4BDVUbd005826 for ; Wed, 11 May 2011 13:31:57 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, 11 May 2011 19:01:54 +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_01CC0FDF.CB17B4F9" Date: Wed, 11 May 2011 19:01:52 +0530 Message-ID: <1D062974A4845E4D8A343C653804920205709785@XMB-BGL-414.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-ietf-siprec-metadata Thread-Index: AcwP38miTxO7jwEgQWSTdMC7tXiQPw== From: "Muthu ArulMozhi Perumal (mperumal)" To: X-OriginalArrivalTime: 11 May 2011 13:31:54.0718 (UTC) FILETIME=[CB244FE0:01CC0FDF] Subject: [siprec] Comments on draft-ietf-siprec-metadata X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 13:32:02 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC0FDF.CB17B4F9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 1) The rational for associating Media Streams with Participants looks obvious. However, the rational for associating them directly with CS is not so. There is no description in the draft on how the direct association of Media Streams with CS is going to be beneficial for the SRS when the same can be inferred from the indirect association of Media Streams with Participants and Participants with the CS. =20 2) 4.5. Media Stream o Codec params - represents codec parameters of the CS media o Media Stream Reference - In implementations this can reference to m-line =20 It is not clear what the motivations are for these attributes and how they are going to be beneficial for the SRS. =20 3) 5.4.1. Case 1 a) Shouldn't Participants D, E, F and G be attached to Participant B (which is also an SRC) instead of Media Stream B1? b) Shouldn't Media Stream A1 be associated with the CS? (provided there is rational in #1). =20 4) 5.4.2. Case 2 The first diagram shows Participant C receiving and mixing media streams from Participants B, D and E, whereas the diagram below shows Participant C receiving and mixing media streams from Participants D and E only. Also, it looks a bit convoluted with page breaks. =20 5) The draft isn't consistent with usage of 'Participant' and 'participant'. The former seems to indicate the Participant block/element, but they are used interchangeably as in: 4.3.2. Associations o Participant may be associated with zero or more CS's (It is possible, though unlikely, that there are participants who are not part of any CS). An 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 6) 4.3. Communication Session o Call Termination Reason - This represents the reason why a CS was terminated. The communication session MAY contain a Call. =20 If the SRC is a focus with many participants would each participant joining the conference be considered a call? If the intention is to indicate the CS termination reason, it seems better to call this attribute as just Termination Reason. =20 Nitpicks: =20 7) Section 3 (Metadata Model): For instance, the timing of changes may not explicitly conveyed from the SRC to the SRC, because the mechanism (yet to be defined) which conveys the metadata may implicitly provide the timing. (E.g. the time a change occurred by be assumed to be the same as the time when notification of the change is received by the SRS.) =20 s/SRC to the SRC/SRC to SRS/ s/by be assumed/may be assumed/ =20 8) 4.5. Media Stream A Media Stream block shall have properties of media as seen by SRC and sent to SRS. =20 s/shall have/SHALL have/ =20 Muthu ------_=_NextPart_001_01CC0FDF.CB17B4F9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

1) The rational for associating Media Streams with Participants looks obvious. However, the rational for associating them directly with CS is not so. = There is no description in the draft on how the direct association of Media = Streams with CS is going to be beneficial for the SRS when the same can be inferred = from the indirect association of Media Streams with Participants and Participants = with the CS.

 

2) = 4.5. Media Stream

   o  Codec params - represents codec parameters of the CS media

   o  Media Stream Reference - In implementations this can reference to

      = m-line

 

It is = not clear what the motivations are for these attributes and how they are = going to be beneficial for the SRS.

 

3) = 5.4.1. Case 1

a) = Shouldn't Participants D, E, F and G be attached to Participant B (which is also an SRC) instead of Media Stream B1?

b) = Shouldn't Media Stream A1 be associated with the CS? = (provided there is rational in #1).

 

4) = 5.4.2.  Case 2

The = first diagram shows Participant C receiving and mixing media streams from = Participants B, D and E, whereas the diagram below shows Participant C receiving and = mixing media streams from Participants D and E only. Also, it looks a bit = convoluted with page breaks.

 

5) The = draft isn't consistent with usage of 'Participant' and 'participant'. The = former seems to indicate the Participant block/element, but they are used = interchangeably as in:

4.3.2.  = Associations

   o  Participant may be associated = with zero or more CS's (It is

      = possible, though unlikely, that there are participants who are not

      part of = any CS).  An 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.

 

6) = 4.3.  Communication = Session

   o  Call Termination Reason - This represents the reason why a CS was

      = terminated.  The communication session MAY = contain a Call.

 

If the = SRC is a focus with many participants would each participant joining the conference be considered a call? If the = intention is to indicate the CS termination reason, it seems better to call this = attribute as just Termination Reason.

 

Nitpicks:

 

7) = Section 3 (Metadata Model):

For = instance, the timing of changes may not explicitly conveyed from the SRC to the SRC, because the mechanism (yet to be = defined) which conveys the metadata may implicitly provide the timing.  (E.g. the time a change = occurred by be assumed to be the same as the time when notification of the change is = received by the SRS.)

 

s/SRC to the SRC/SRC to SRS/

s/by = be assumed/may be assumed/

 

8) = 4.5. Media Stream

A = Media Stream block shall have properties of media as seen by SRC and sent to SRS.

 

s/shall have/SHALL have/

 

Muthu

------_=_NextPart_001_01CC0FDF.CB17B4F9-- From mperumal@cisco.com Wed May 11 06:48: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 9E120E071F for ; Wed, 11 May 2011 06:48:53 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdhFiEK4wNDb for ; Wed, 11 May 2011 06:48:51 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 70F9CE06C8 for ; Wed, 11 May 2011 06:48:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=27683; q=dns/txt; s=iport; t=1305121731; x=1306331331; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=y2V4ZILqa4hk7Z/FCpN0DdIhZUsKOag6UcqfUnPTEQg=; b=AlYXYezoe5d1ZuU+zgDeFE5BzKe3hoo5+0FbpVKAU9W4sCcmNQs5Yc1P qDg01sbiJdNaOdEDzuO5JligLY/AgYM2U7ZNWi74jGbSZmNGpB4qVFT+7 Sk0oQCPmprBx47P5pEGuwAIM4wzypR+Q7yDkrKRgjifMDMZtbCdHtf5zZ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8BAMySyk2rRDoJ/2dsb2JhbACXV44vd6oOnh6DDIMEBIZBjV+KOQ X-IronPort-AV: E=Sophos;i="4.64,353,1301875200"; d="scan'208";a="313256634" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 11 May 2011 13:48:50 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p4BDmmbg003346; Wed, 11 May 2011 13:48:49 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, 11 May 2011 19:18:47 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 May 2011 19:18:44 +0530 Message-ID: <1D062974A4845E4D8A343C653804920205709791@XMB-BGL-414.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD06480E2F@XMB-BGL-417.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: AcwFuuvxdSy9/XTRSVq5DE/JiXPmDAAAgTPwAnuoqVAADSe5cA== 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><07465C1D981ABC41A344374066 AE1A2C38 AB7A20DB@TL VMBX01.nice.com> <35BCE99A477D6A4986FB2216D8CF2CFD06480E2F@XMB-BGL-417.cisco.com> From: "Muthu ArulMozhi Perumal (mperumal)" To: "Ram Mohan R (rmohanr)" , "Leon Portman" , "Paul Kyzivat (pkyzivat)" , "Henry Lum" X-OriginalArrivalTime: 11 May 2011 13:48:47.0391 (UTC) FILETIME=[26BDF2F0:01CC0FE2] 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, 11 May 2011 13:48:53 -0000 If we consider MS as local to a Participant (as John was trying to argue) there seems to be no need for a unique ID for MS since it can be inferred from the Participant that can be uniquely identified. The mail thread describes a use-case where multicast MoH played to a number of participants and to the SRC is recorded. Can't the MoH source be considered a Participant here? Muthu |-----Original Message----- |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Ram Mohan R (rmohanr) |Sent: Wednesday, May 11, 2011 12:52 PM |To: Leon Portman; Paul Kyzivat (pkyzivat); Henry Lum |Cc: siprec@ietf.org |Subject: Re: [siprec] Does MS have life outside a particular CS? (was RE:comments on draft-ram-siprec- |metadata-04) | |Hello All, | |As per the discussions in last meeting and below mail thread it appears |that we would need global ID to take care of all the cases. However |there is a disagreement with some folks in having a unique ID. I would |request people to respond on this mail thread and take this issue to |closure. | |If no one has issues, we will go with globally Unique ID for MS block. | |Regards, |Ram | |> -----Original Message----- |> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On |> Behalf Of Leon Portman |> Sent: Thursday, April 28, 2011 9:28 PM |> To: Paul Kyzivat (pkyzivat); Henry Lum |> Cc: siprec@ietf.org |> Subject: Re: [siprec] Does MS have life outside a particular CS? (was |> RE: comments on draft-ram-siprec-metadata-04) |> |> 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: comments 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 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=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 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 Henry.Lum@alcatel-lucent.com Wed May 11 10:40: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 BC271E0871 for ; Wed, 11 May 2011 10:40:06 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OipUadtw5coE for ; Wed, 11 May 2011 10:40:05 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC1DE085D for ; Wed, 11 May 2011 10:40:05 -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 p4BHe3cp003265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 May 2011 12:40:04 -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 p4BHe2l2018776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 11 May 2011 12:40:03 -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 p4BHe1k3010151; Wed, 11 May 2011 10:40:01 -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, 11 May 2011 10:40:01 -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, 11 May 2011 10:39:59 -0700 Message-ID: <059AF07365DC474393A19A3AF187DF74070C2B3A@NAHALD.us.int.genesyslab.com> In-Reply-To: <07465C1D981ABC41A344374066AE1A2C38AB848F1D@TLVMBX01.nice.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] RS Group / Recording Object issue from interim meeting Thread-Index: AcwOnlUD796ZsvbMTUylbGle0/maUwAOn8yAAAGlS7AAEs9kUAAAhHRQAAC4X4AAAGUVEAAB8S1AAAB6WcAAMVgKoA== References: <35BCE99A477D6A4986FB2216D8CF2CFD06480A28@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD06480C54@XMB-BGL-417.cisco.com> <07465C1D981ABC41A344374066AE1A2C38AB848F1D@TLVMBX01.nice.com> From: "Henry Lum" To: "Leon Portman" , "Charles Eckel (eckelcu)" , "Ram Mohan R (rmohanr)" , "Elwell, John" , "Parthasarathi R (partr)" , X-OriginalArrivalTime: 11 May 2011 17:40:01.0323 (UTC) FILETIME=[743FF7B0:01CC1002] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: Re: [siprec] RS Group / Recording Object issue from 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, 11 May 2011 17:40:06 -0000 Agreed with below as well. An additional comment is that we may want to point out that one or more SRC may reference the same CS by referring to the same global unique ID. How the SRC figure out the same reference to the CS belongs to an external mechanism which is out of scope for this group. Likewise for the CSG, and I see that in section 4.1.2 (the last sentence) that indicates a CSG may only belong to a single SRC. We should clarify that a CSG may be referenced by one or more SRCs as long as they refer to the same unique identifier. Henry > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Leon Portman > Sent: Tuesday, May 10, 2011 1:53 PM > To: Charles Eckel (eckelcu); Ram Mohan R (rmohanr); Elwell, John; > Parthasarathi R (partr); siprec@ietf.org > Subject: Re: [siprec] RS Group / Recording Object issue from interim > meeting >=20 > I agree with below. Just additional comment that the actual fact how > recordings are stored in the file system; one file or multiple chunks > are implementation details of SRS. What is important that SRS will have > all relevant information (like unique CS ID) to be able to find, > display and of course playback all relevant RS pieces >=20 > Leon >=20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Charles Eckel (eckelcu) > Sent: Tuesday, May 10, 2011 8:39 PM > To: Ram Mohan R (rmohanr); Elwell, John; Parthasarathi R (partr); > siprec@ietf.org > Subject: Re: [siprec] RS Group / Recording Object issue from interim > meeting >=20 > The proposed text works better for me if you change both instances of > "the" to "a" to remain consistent with the many to many relationship of > CS to RS. >=20 > Cheers, > Charles >=20 > > -----Original Message----- > > From: Ram Mohan R (rmohanr) > > Sent: Tuesday, May 10, 2011 9:47 AM > > To: Elwell, John; Parthasarathi R (partr); Charles Eckel (eckelcu); > siprec@ietf.org > > Subject: RE: [siprec] RS Group / Recording Object issue from interim > meeting > > > > Hi John / Charles, > > > > I will update the text in metadata model draft > (draft-ietf-siprec-metadata-00) in the next revision to > > reflect this. > > > > Here is the text I suggest to be modified in Section 4.1 of draft. > Please comment on this and > > edit/refine the text: > > > > Current text is > > "A Recording Session element represents one instance of a Recording > Session." > > > > Proposed text is : > > "A Recording Session element represents the SIP session created > between an SRC and SRS for the purpose > > of recording a Communication Session. The SIP RS dialog SHALL be > mapped to this element and hence > > there is no need for this element to be reflected in XML" > > > > Regards, > > Ram > > > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > Sent: Tuesday, May 10, 2011 10:07 PM > > > To: Parthasarathi R (partr); Charles Eckel (eckelcu); Ram Mohan R > > > (rmohanr); siprec@ietf.org > > > Subject: RE: [siprec] RS Group / Recording Object issue from > interim > > > meeting > > > > > > This thread looks like it is heading in a direction that is > acceptable > > > to me. Keeping RS in the model should not necessarily imply that it > has > > > to be reflected in XML, if the SIP dialog itself is sufficient. > > > > > > John (as individual) > > > > > > > -----Original Message----- > > > > From: siprec-bounces@ietf.org > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi R > (partr) > > > > Sent: 10 May 2011 17:11 > > > > To: Charles Eckel (eckelcu); Ram Mohan R (rmohanr); > siprec@ietf.org > > > > Subject: Re: [siprec] RS Group / Recording Object issue from > > > > interim meeting > > > > > > > > Hi Charles, > > > > > > > > I agree with you to add the text which helps to distinct RS from > > > > recording. > > > > > > > > Thanks > > > > Partha > > > > > > > > -----Original Message----- > > > > From: Charles Eckel (eckelcu) > > > > Sent: Tuesday, May 10, 2011 9:32 PM > > > > To: Parthasarathi R (partr); Ram Mohan R (rmohanr); > 'siprec@ietf.org' > > > > Subject: RE: [siprec] RS Group / Recording Object issue from > interim > > > > meeting > > > > > > > > Hi Partha, > > > > > > > > The problem for me was that I started thinking of the RS as being > > > > equivalent to a recording. If we leave the RS in the model, it > > > > would be good to clarify the distinction. > > > > > > > > Cheers, > > > > Charles > > > > > > > > > > > > > -----Original Message----- > > > > > From: Parthasarathi R (partr) > > > > > Sent: Tuesday, May 10, 2011 12:25 AM > > > > > To: Ram Mohan R (rmohanr); Charles Eckel (eckelcu); > siprec@ietf.org > > > > > Subject: RE: [siprec] RS Group / Recording Object issue > > > > from interim > > > > > meeting > > > > > > > > > > Charles, > > > > > > > > > > Just adding to Ram mentioned, draft-jones-ipmc-session-id-01 > > > > > Session-UUID or draft-kaplan-dispatch- > > > > > session-id-03 Session-id or other proprietary unique-id may > > > > be used in > > > > > > > > > CS to make your proposed solution work. IMO, it is outside the > > > scope > > > > of SIPREC and I favor OPTION 2. > > > > > > > > > > The reason for having RS element in the model is to show the > model > > > > > from SRS perspective and in case of metadata format, SIP > Message > > > > > information (Dialog-id, Date header) shall be re-used instead > of > > > > having separate RS specific XML elements. > > > > > > > > > > Thanks > > > > > Partha > > > > > > > > > > -----Original Message----- > > > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] > On > > > > > Behalf Of Ram Mohan R (rmohanr) > > > > > Sent: Tuesday, May 10, 2011 11:50 AM > > > > > To: Charles Eckel (eckelcu); siprec@ietf.org > > > > > Subject: Re: [siprec] RS Group / Recording Object issue > > > > from interim > > > > > meeting > > > > > > > > > > As I mentioned in the meeting yesterday, CS Unique ID > > > > should suffice > > > > > to correlate disparate recordings and hence we don't need > RS-Group > > > > element. > > > > > How SRC(s) share this CS Unique ID is something that is > > > > currently left > > > > to implementers(out of scope). > > > > > > > > > > so I favor Option2 > > > > > > > > > > Regards, > > > > > Ram > > > > > > > > > > > -----Original Message----- > > > > > > From: siprec-bounces@ietf.org [mailto:siprec- > bounces@ietf.org] > On > > > > > > Behalf Of Charles Eckel (eckelcu) > > > > > > Sent: Tuesday, May 10, 2011 4:41 AM > > > > > > To: siprec@ietf.org > > > > > > Subject: [siprec] RS Group / Recording Object issue from > interim > > > > > > meeting > > > > > > > > > > > > I am attempting to summarize the discussion we had around > this > > > > > > issue, and provide what I understood to be the accepted > proposal. > > > > > > First, let me settle on a single term. The term RS Group will > be > > > > > > used to mean a collection of RS elements that comprise a > single > > > > > > recording. For example, > > > > > > RS1 and RS2 may be two independent sessions that together > form > a > > > > > single > > > > > > recording. In such a case, the media streams associated > > > > with RS1 and > > > > > > RS2 > > > > > > are combined into a single recording. > > > > > > > > > > > > Question1: Do we need an RS Group element within the > > > > metadata model? > > > > > > Question2: If the answer to Q1 is no, do we need an RS > element > in > > > > > > the metadata model? > > > > > > > > > > > > Use Cases: > > > > > > t0: UA1 and UA2 establish CS1, and SRC1, which may be > co-located > > > > > > with > > > > > > UA1 or UA2 or may be somewhere in between, decides to record > CS1 > > > > > > t1: SRC1 establishes RS1 toward SRS1 for the purpose of > > > > starting a > > > > > > new recording. > > > > > > t2: At some point in time, RS1 is terminated for whatever > reason > > > > (e.g. > > > > > > network issue, SRS failure, etc.) > > > > > > t3: SRC1 establishes RS2 toward SRS1 for the purpose of > > > > continuing > > > > > > the recording. > > > > > > > > > > > > Option1 (using new RS Group element): > > > > > > If there was a metadata element for an RS Group, RSG1, it > > > > could have > > > > > > > > > > been created containing RS1 at time t1, then referenced > > > > at time t3 > > > > > > to cause RS2 to be added to RSG1 rather than creating RSG2. > > > > > > > > > > > > Option2 (using globally unique CS ID): > > > > > > Alternatively, if SRC1 wants RS1 and RS2 to be considered > part > of > > > > > > the same recording, SRC1 could indicate in both RS1 and > > > > RS2 that is > > > > > > it CS1 that is being recorded. Since CS1 is globally unique, > SRS1 > > > > > > could recognize this as being an attempt to continue the same > > > > recording. > > > > > > > > > > > > If SRC1 instead prefers to have two separate recordings, > > > > SRC1 could > > > > > > indicate in RS1 that it is CS1 that is being recorded, and in > RS2 > > > > > > indicate that it is CS2 that is being recorded. CS1 and CS2 > may > > > > > contain > > > > > > the same actual media, but by using different globally unique > IDs > > > > > > within each RS, SRC1 can force them to be two independent > > > > recordings. > > > > > > > > > > > > In this case, there is no need for an RS Group element, > > > > nor is there > > > > > > > > > > a need for an RS element. > > > > > > > > > > > > I previously favored Option1. Following the discussion up to > and > > > > > > including that in the interim meeting, I am okay with > Option2. > > > > > > > > > > > > Cheers, > > > > > > Charles > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > siprec mailing list > > > > > > siprec@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > _______________________________________________ > > > > > siprec mailing list > > > > > siprec@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > _______________________________________________ > > > > siprec mailing list > > > > siprec@ietf.org > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > _______________________________________________ > siprec mailing 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 Henry.Lum@alcatel-lucent.com Wed May 11 10:43:36 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 166DAE0802 for ; Wed, 11 May 2011 10:43:36 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3sLRNBV2X6x for ; Wed, 11 May 2011 10:43:31 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 88444E06D5 for ; Wed, 11 May 2011 10:43:31 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p4BHhSSv018284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 May 2011 12:43:28 -0500 (CDT) Received: from relay-out2.dc (relay-out2.dc.genesyslab.com [172.22.68.188]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p4BHhQCx002520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 11 May 2011 12:43:27 -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 p4BHhMHI008428; Wed, 11 May 2011 10:43:25 -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, 11 May 2011 10:43:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 May 2011 10:43:22 -0700 Message-ID: <059AF07365DC474393A19A3AF187DF74070C2B40@NAHALD.us.int.genesyslab.com> In-Reply-To: <07465C1D981ABC41A344374066AE1A2C38AB848F1E@TLVMBX01.nice.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Multiple recordings of the same CS/CSG... Thread-Index: AcwOstC8OBE753XYSXagrL3WGZkVXAAd2GbwAAQ7r2AAMeV5QA== References: <4DC896CA.6070802@cisco.com> <07465C1D981ABC41A344374066AE1A2C38AB848F1E@TLVMBX01.nice.com> From: "Henry Lum" To: "Leon Portman" , "Charles Eckel (eckelcu)" , "Paul Kyzivat (pkyzivat)" , X-OriginalArrivalTime: 11 May 2011 17:43:23.0280 (UTC) FILETIME=[ECA02900:01CC1002] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: Re: [siprec] Multiple recordings of the same CS/CSG... X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 17:43:36 -0000 +1 As I alluded in the other thread that this is a matter between the SRCs to determine whether they want to reference the same CS using a common identifier as the "same recording". Henry > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Leon Portman > Sent: Tuesday, May 10, 2011 1:53 PM > To: Charles Eckel (eckelcu); Paul Kyzivat (pkyzivat); siprec@ietf.org > Subject: Re: [siprec] Multiple recordings of the same CS/CSG... >=20 > +1 >=20 > Leon >=20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Charles Eckel (eckelcu) > Sent: Tuesday, May 10, 2011 6:54 PM > To: Paul Kyzivat (pkyzivat); siprec@ietf.org > Subject: Re: [siprec] Multiple recordings of the same CS/CSG... >=20 > I agree. >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Paul Kyzivat (pkyzivat) > > Sent: Monday, May 09, 2011 6:37 PM > > To: siprec@ietf.org > > Subject: [siprec] Multiple recordings of the same CS/CSG... > > > > During the call today we got into a discussion of the > > pros/cons/mechanisms for achieving multiple recordings of the same CS > or > > CSG. > > > > I'm pretty sure this was initially posed as a potential requirement > by > > Charles Eckel in: > > http://www.ietf.org/mail-archive/web/siprec/current/msg01876.html > > > > Paraphrasing, the argument is that two different participants in a > CS, > > possibly with different SRCs, may both want to record the CS, and > have > > control over *how* it is recorded. For instance, one may want to do > its > > own mixing of the media streams and send the mix to the SRS for > > recording. It might also transcode, affecting the fidelity of the > > recording. Another participant might want all the streams recorded > > independently so they may later be analyzed separately. > > > > It isn't immediately apparent if this sort of operation is possible > with > > the current model. Superficially it seems it is not. > > > > One question is whether this is something important to address. (If > it > > happens to fall out without extra work then probably nobody will > object, > > but if its extra work, then its something we really need to decide.) > > > > Its my assertion that from a practical perspective this sort of > behavior > > can be achieved with the model we have, as follows: > > > > The mechanism currently on the table has each SRC assigning globally > > unique IDs for each CS, CSG, and various other things. This is still > > under debate, but whatever things don't end of having a globally > unique > > id will almost certainly be scoped within something that does. > > > > Unless they go to some effort to coordinate, two SRCs involved with > the > > "same" CS will each assign their own unique id to it. When the SRC > > receives metadata, this CS will appear to it as two independent CSs. > > Hence, *by default* there will be two independent recordings. > > > > If two SRCs what something different from that, they can potentially > > achieve it by coordinating unique id assignments among themselves. I > am > > not proposing that we define a way to do that - at least for now it > > would be something proprietary between them. A "simple" example could > be > > a fault-tolerant pair of SRCs that coordinate so that if one fails > the > > other can take over and continue the recording. Here the pair would > be > > coordinating a lot of sip knowledge in addition to the uuids. > > > > *If* some SRCs are coordinating their uuid assigments, and if there > are > > cases where they want to cause independent recordings to be made, > then > > they can achieve that by simply *not* using the same uuid for a CS. > Of > > course this opens up a whole can of worms about how they decide when > > they want to be part of the same recording and when not. But we don't > > need to get into that - it is their problem to solve. > > > > AFAIK this ought to be sufficient for addressing Charle' problem. > > Discussion welcome. > > > > 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 Henry.Lum@alcatel-lucent.com Wed May 11 11:00: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 374A4E089E for ; Wed, 11 May 2011 11:00:57 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2cllPWhbsjVp for ; Wed, 11 May 2011 11:00:54 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 7C60CE089B for ; Wed, 11 May 2011 11:00:54 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p4BI0oal002389 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 May 2011 13:00:50 -0500 (CDT) Received: from relay-out2.dc (relay-out2.dc.genesyslab.com [172.22.68.188]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p4BI0khU031914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 11 May 2011 13:00:50 -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 p4BI0kPI018822; Wed, 11 May 2011 11:00:46 -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, 11 May 2011 11:00:43 -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, 11 May 2011 11:00:41 -0700 Message-ID: <059AF07365DC474393A19A3AF187DF74070C2B4D@NAHALD.us.int.genesyslab.com> In-Reply-To: <1D062974A4845E4D8A343C653804920205709791@XMB-BGL-414.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: AcwFuuvxdSy9/XTRSVq5DE/JiXPmDAAAgTPwAnuoqVAADSe5cAAI259w 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><07465C1D981ABC41A344374066! ! AE1A2C 38 AB7A20DB@ TLVMBX01.nice.com> <35BCE99A477D6A4986FB2216D8CF2CFD06480E2F@XMB-BGL-417.cisco.com> <1D062974A4845E4D8A343C653804920205709791@XMB-BGL-414.cisco.com> From: "Henry Lum" To: "Muthu ArulMozhi Perumal (mperumal)" , "Ram Mohan R (rmohanr)" , "Leon Portman" , "Paul Kyzivat (pkyzivat)" X-OriginalArrivalTime: 11 May 2011 18:00:43.0578 (UTC) FILETIME=[58B109A0:01CC1005] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 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: Wed, 11 May 2011 18:00:57 -0000 I also don't see a need to use another unique ID for a media stream as the relationship can be inferred by participants and CS. As for things like MOH, I tend to agree that we need to have an automated participant to deliver media as a dialog to a use which is the other participant. Having an explicit relationship for dialogs like this helps us to visualize who the participant is interacting with during the lifetime of the CS (ie. how many times did the participant was put on hold?).=20 On the other hand, if we have a conference mixer that generates a mixed media stream to all the conference participants, then do we need a mixer participant that contributes to this mixed output? My initial reaction is no, meaning a mixer can be implied in the relationship whenever a media stream is sent to multiple participants, but we can also allow someone to explicitly model this with a mixer participant. Regards, Henry > -----Original Message----- > From: Muthu ArulMozhi Perumal (mperumal) [mailto:mperumal@cisco.com] > Sent: Wednesday, May 11, 2011 9:49 AM > To: Ram Mohan R (rmohanr); Leon Portman; Paul Kyzivat (pkyzivat); Henry > Lum > 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 > If we consider MS as local to a Participant (as John was trying to > argue) there seems to be no need for a unique ID for MS since it can be > inferred from the Participant that can be uniquely identified. >=20 > The mail thread describes a use-case where multicast MoH played to a > number of participants and to the SRC is recorded. Can't the MoH source > be considered a Participant here? >=20 > Muthu >=20 > |-----Original Message----- > |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Ram Mohan R (rmohanr) > |Sent: Wednesday, May 11, 2011 12:52 PM > |To: Leon Portman; Paul Kyzivat (pkyzivat); Henry Lum > |Cc: siprec@ietf.org > |Subject: Re: [siprec] Does MS have life outside a particular CS? (was > RE:comments on draft-ram-siprec- > |metadata-04) > | > |Hello All, > | > |As per the discussions in last meeting and below mail thread it > appears > |that we would need global ID to take care of all the cases. However > |there is a disagreement with some folks in having a unique ID. I would > |request people to respond on this mail thread and take this issue to > |closure. > | > |If no one has issues, we will go with globally Unique ID for MS block. > | > |Regards, > |Ram > | > |> -----Original Message----- > |> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > |> Behalf Of Leon Portman > |> Sent: Thursday, April 28, 2011 9:28 PM > |> To: Paul Kyzivat (pkyzivat); Henry Lum > |> Cc: siprec@ietf.org > |> Subject: Re: [siprec] Does MS have life outside a particular CS? > (was > |> RE: comments on draft-ram-siprec-metadata-04) > |> > |> 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: comments 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 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=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 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 =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 May 11 12:03:39 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2E88E0885 for ; Wed, 11 May 2011 12:03:38 -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 vMqIMUx1EKuv for ; Wed, 11 May 2011 12:03:38 -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 2983DE089C for ; Wed, 11 May 2011 12:02:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=689; q=dns/txt; s=iport; t=1305140536; x=1306350136; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=It3vRvfDvlC6zbxtJYS3eTXiTb0ibYS47r92WxnnPJ4=; b=NXT4vAveNnPdlZhSE19M9a4zkG2v6F7NtqWEPPZmchakrDnbdCt2HUWZ fdQCNI3O1WpWyqN3qeVpZ7UmOC/g+Sseejiw0R7ZvSBw0gticc8zHqkg/ m4sPZmwpenNEaBCjt3EdaMA1sMlet2bO8GmTLI/GCJ7e46oKFfMi8ERfa g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEFAE/cyk2Q/khLgWdsb2JhbACYEY1yFAEBFiYlqgmeMYYQBI9whCeKVg X-IronPort-AV: E=Sophos;i="4.64,354,1301875200"; d="scan'208";a="88008083" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 11 May 2011 19:02:15 +0000 Received: from [161.44.174.124] (dhcp-161-44-174-124.cisco.com [161.44.174.124]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p4BJ2EWF004502 for ; Wed, 11 May 2011 19:02:14 GMT Message-ID: <4DCADD36.2030301@cisco.com> Date: Wed, 11 May 2011 15:02:14 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: siprec@ietf.org References: <1D062974A4845E4D8A343C653804920205709785@XMB-BGL-414.cisco.com> In-Reply-To: <1D062974A4845E4D8A343C653804920205709785@XMB-BGL-414.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] Comments on draft-ietf-siprec-metadata X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 19:03:39 -0000 Muthu, On 5/11/2011 9:31 AM, Muthu ArulMozhi Perumal (mperumal) wrote: > 1) The rational for associating Media Streams with Participants looks > obvious. However, the rational for associating them directly with CS is > not so. There is no description in the draft on how the direct > association of Media Streams with CS is going to be beneficial for the > SRS when the same can be inferred from the indirect association of Media > Streams with Participants and Participants with the CS. They can't necessarily be inferred, because the same participant can be associated with multiple CSs and with multiple MSs without all the MSs being in all the CSs. Thanks, Paul From mperumal@cisco.com Wed May 11 17:40: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 DE34EE084F for ; Wed, 11 May 2011 17:40:03 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gxaMrOUe2MBp for ; Wed, 11 May 2011 17:40:01 -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 41778E0711 for ; Wed, 11 May 2011 17:40:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=33624; q=dns/txt; s=iport; t=1305160800; x=1306370400; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=lXhr6vRopInXqPFeg59B7jsnZxS2/1uQ4BzL1+J/GdQ=; b=OF3ZR+ao7hupZjTFFMTFvvkltGV4uVJZ7vIpgT3Rroslg5kk/Ggtwi+8 Xb1YSZuU8Mbvp2LBNCaGPJJEGq8F5p36rU19OakiwM//RNhS1KV0cBLEN iWfo9tLTkjadTug07XR11aHMKwm5V7XLlFAAPm6OVjTJskA1p3rtheaBL A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsUAAPsry02Q/khRgWdsb2JhbACXPY4zFAEBFiYliHCiL547gw2DBASGQo1hijw X-IronPort-AV: E=Sophos;i="4.64,355,1301875200"; d="scan'208";a="29805850" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 12 May 2011 00:39:58 +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 p4C0duKB003234; Thu, 12 May 2011 00:39:57 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, 12 May 2011 06:09:55 +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, 12 May 2011 06:09:48 +0530 Message-ID: <1D062974A4845E4D8A343C65380492020570987E@XMB-BGL-414.cisco.com> In-Reply-To: <059AF07365DC474393A19A3AF187DF74070C2B4D@NAHALD.us.int.genesyslab.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: AcwFuuvxdSy9/XTRSVq5DE/JiXPmDAAAgTPwAnuoqVAADSe5cAAI259wAA21w7A= 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><07465C1D981ABC41A344374066! ! AE1A 2C38 AB7A20D B@TLVMBX01.nice.com> <35BCE99A477D6A4986FB2216D8CF2CFD06480E2F@XMB-BGL-417.cisco.com> <1D062974A4845E4D8A343C653804920205709791@XMB-BGL-414.cisco.com> <059AF07365DC474393A19A3AF187DF74070C2B4D@NAHALD.us.int.genesyslab.com> From: "Muthu ArulMozhi Perumal (mperumal)" To: "Henry Lum" , "Ram Mohan R (rmohanr)" , "Leon Portman" , "Paul Kyzivat (pkyzivat)" X-OriginalArrivalTime: 12 May 2011 00:39:55.0406 (UTC) FILETIME=[1D17F2E0:01CC103D] 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, 12 May 2011 00:40:04 -0000 Henry, |On the other hand, if we have a conference mixer that generates a=20 |mixed media stream to all the conference participants, then do we |need a mixer participant that contributes to this mixed output? I think it depends if the mixer is SRC or not. If the mixer is SRC (case 2 in the metadata draft) we don't need a mixer participant. If the mixer is not (case 4 in the metadata draft) then we do -- this could be modeled by associating the conference participants with the mixer participant and by visualizing that the media streams generated by the conference participants contribute the combined media stream generated by the mixer participant (analogous to how RTP models a mixer). Muthu |-----Original Message----- |From: Henry Lum [mailto:Henry.Lum@alcatel-lucent.com] |Sent: Wednesday, May 11, 2011 11:31 PM |To: Muthu ArulMozhi Perumal (mperumal); Ram Mohan R (rmohanr); Leon Portman; Paul Kyzivat (pkyzivat) |Cc: siprec@ietf.org |Subject: RE: [siprec] Does MS have life outside a particular CS? (was RE:comments on draft-ram-siprec- |metadata-04) | |I also don't see a need to use another unique ID for a media stream as |the relationship can be inferred by participants and CS. | |As for things like MOH, I tend to agree that we need to have an |automated participant to deliver media as a dialog to a use which is the |other participant. Having an explicit relationship for dialogs like this |helps us to visualize who the participant is interacting with during the |lifetime of the CS (ie. how many times did the participant was put on |hold?). | |On the other hand, if we have a conference mixer that generates a mixed |media stream to all the conference participants, then do we need a mixer |participant that contributes to this mixed output? My initial reaction |is no, meaning a mixer can be implied in the relationship whenever a |media stream is sent to multiple participants, but we can also allow |someone to explicitly model this with a mixer participant. | |Regards, |Henry | |> -----Original Message----- |> From: Muthu ArulMozhi Perumal (mperumal) [mailto:mperumal@cisco.com] |> Sent: Wednesday, May 11, 2011 9:49 AM |> To: Ram Mohan R (rmohanr); Leon Portman; Paul Kyzivat (pkyzivat); |Henry |> Lum |> Cc: siprec@ietf.org |> Subject: RE: [siprec] Does MS have life outside a particular CS? (was |> RE:comments on draft-ram-siprec-metadata-04) |> |> If we consider MS as local to a Participant (as John was trying to |> argue) there seems to be no need for a unique ID for MS since it can |be |> inferred from the Participant that can be uniquely identified. |> |> The mail thread describes a use-case where multicast MoH played to a |> number of participants and to the SRC is recorded. Can't the MoH |source |> be considered a Participant here? |> |> Muthu |> |> |-----Original Message----- |> |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On |> Behalf Of Ram Mohan R (rmohanr) |> |Sent: Wednesday, May 11, 2011 12:52 PM |> |To: Leon Portman; Paul Kyzivat (pkyzivat); Henry Lum |> |Cc: siprec@ietf.org |> |Subject: Re: [siprec] Does MS have life outside a particular CS? (was |> RE:comments on draft-ram-siprec- |> |metadata-04) |> | |> |Hello All, |> | |> |As per the discussions in last meeting and below mail thread it |> appears |> |that we would need global ID to take care of all the cases. However |> |there is a disagreement with some folks in having a unique ID. I |would |> |request people to respond on this mail thread and take this issue to |> |closure. |> | |> |If no one has issues, we will go with globally Unique ID for MS |block. |> | |> |Regards, |> |Ram |> | |> |> -----Original Message----- |> |> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On |> |> Behalf Of Leon Portman |> |> Sent: Thursday, April 28, 2011 9:28 PM |> |> To: Paul Kyzivat (pkyzivat); Henry Lum |> |> Cc: siprec@ietf.org |> |> Subject: Re: [siprec] Does MS have life outside a particular CS? |> (was |> |> RE: comments on draft-ram-siprec-metadata-04) |> |> |> |> 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: comments 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 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=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 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 | | |----------------------------------------------------------------------- ------------------------------- |------------- |CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary |information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is |authorized. Any liability arising from any party acting, or refraining from acting, on any information |contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the |sender immediately, destroy the original transmission and its attachments and do not disclose the |contents to any other person, use it for any purpose, or store or copy the information in any medium. |Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities. | From john.elwell@siemens-enterprise.com Thu May 12 00:27: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 0A783E066A for ; Thu, 12 May 2011 00:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 1EZGpqo9mvT1 for ; Thu, 12 May 2011 00:27:04 -0700 (PDT) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfa.amsl.com (Postfix) with SMTP id E1E33E0669 for ; Thu, 12 May 2011 00:27:03 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1305185216!38860180!1 X-StarScan-Version: 6.2.16; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 30945 invoked from network); 12 May 2011 07:26:57 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-6.tower-27.messagelabs.com with SMTP; 12 May 2011 07:26:57 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 8671A1EB83E1; Thu, 12 May 2011 09:27:02 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 12 May 2011 09:27:02 +0200 From: "Elwell, John" To: "Ram Mohan R (rmohanr)" , "Parthasarathi R (partr)" , "Charles Eckel (eckelcu)" , "siprec@ietf.org" Date: Thu, 12 May 2011 09:27:00 +0200 Thread-Topic: [siprec] RS Group / Recording Object issue from interim meeting Thread-Index: AcwOnlUD796ZsvbMTUylbGle0/maUwAOn8yAAAGlS7AAEs9kUAAAhHRQAAC4X4AAAGUVEABPHvFg Message-ID: References: <35BCE99A477D6A4986FB2216D8CF2CFD06480A28@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD06480C54@XMB-BGL-417.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD06480C54@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] RS Group / Recording Object issue from interim meeting X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2011 07:27:06 -0000 =20 > -----Original Message----- > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com]=20 > Sent: 10 May 2011 17:47 > To: Elwell, John; Parthasarathi R (partr); Charles Eckel=20 > (eckelcu); siprec@ietf.org > Subject: RE: [siprec] RS Group / Recording Object issue from=20 > interim meeting >=20 > Hi John / Charles, >=20 > I will update the text in metadata model draft > (draft-ietf-siprec-metadata-00) in the next revision to reflect this. >=20 > Here is the text I suggest to be modified in Section 4.1 of draft. > Please comment on this and edit/refine the text: >=20 > Current text is=20 > "A Recording Session element represents one instance of a Recording > Session." >=20 > Proposed text is :=20 > "A Recording Session element represents the SIP session=20 > created between > an SRC and SRS for the purpose of recording a Communication=20 > Session. The > SIP RS dialog SHALL be mapped to this element and hence there=20 > is no need > for this element to be reflected in XML" [JRE] This will do as a placeholder, but may need some attention later. For= example, at present this is the sole mention of "XML" in the entire draft,= although that will change when we integrate the format stuff in due course= . Also we probably need a consistent strategy how we use RFC 2119 language = in connection with the model. I will start a separate thread on that, howev= er. John (as individual) >=20 > Regards, > Ram >=20 > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Tuesday, May 10, 2011 10:07 PM > > To: Parthasarathi R (partr); Charles Eckel (eckelcu); Ram Mohan R > > (rmohanr); siprec@ietf.org > > Subject: RE: [siprec] RS Group / Recording Object issue from interim > > meeting > >=20 > > This thread looks like it is heading in a direction that is=20 > acceptable > > to me. Keeping RS in the model should not necessarily imply that it > has > > to be reflected in XML, if the SIP dialog itself is sufficient. > >=20 > > John (as individual) > >=20 > > > -----Original Message----- > > > From: siprec-bounces@ietf.org > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi R > (partr) > > > Sent: 10 May 2011 17:11 > > > To: Charles Eckel (eckelcu); Ram Mohan R (rmohanr);=20 > siprec@ietf.org > > > Subject: Re: [siprec] RS Group / Recording Object issue from > > > interim meeting > > > > > > Hi Charles, > > > > > > I agree with you to add the text which helps to distinct RS from > > > recording. > > > > > > Thanks > > > Partha > > > > > > -----Original Message----- > > > From: Charles Eckel (eckelcu) > > > Sent: Tuesday, May 10, 2011 9:32 PM > > > To: Parthasarathi R (partr); Ram Mohan R (rmohanr); > 'siprec@ietf.org' > > > Subject: RE: [siprec] RS Group / Recording Object issue=20 > from interim > > > meeting > > > > > > Hi Partha, > > > > > > The problem for me was that I started thinking of the RS as being > > > equivalent to a recording. If we leave the RS in the model, > > > it would be > > > good to clarify the distinction. > > > > > > Cheers, > > > Charles > > > > > > > > > > -----Original Message----- > > > > From: Parthasarathi R (partr) > > > > Sent: Tuesday, May 10, 2011 12:25 AM > > > > To: Ram Mohan R (rmohanr); Charles Eckel (eckelcu); > siprec@ietf.org > > > > Subject: RE: [siprec] RS Group / Recording Object issue > > > from interim > > > > meeting > > > > > > > > Charles, > > > > > > > > Just adding to Ram mentioned, draft-jones-ipmc-session-id-01 > > > > Session-UUID or draft-kaplan-dispatch- > > > > session-id-03 Session-id or other proprietary unique-id may > > > be used in > > > > > > > CS to make your proposed solution work. IMO, it is outside the > > scope > > > of SIPREC and I favor OPTION 2. > > > > > > > > The reason for having RS element in the model is to=20 > show the model > > > > from SRS perspective and in case of metadata format, SIP Message > > > > information (Dialog-id, Date header) shall be re-used instead of > > > having separate RS specific XML elements. > > > > > > > > Thanks > > > > Partha > > > > > > > > -----Original Message----- > > > > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On > > > > Behalf Of Ram Mohan R (rmohanr) > > > > Sent: Tuesday, May 10, 2011 11:50 AM > > > > To: Charles Eckel (eckelcu); siprec@ietf.org > > > > Subject: Re: [siprec] RS Group / Recording Object issue > > > from interim > > > > meeting > > > > > > > > As I mentioned in the meeting yesterday, CS Unique ID > > > should suffice > > > > to correlate disparate recordings and hence we don't=20 > need RS-Group > > > element. > > > > How SRC(s) share this CS Unique ID is something that is > > > currently left > > > to implementers(out of scope). > > > > > > > > so I favor Option2 > > > > > > > > Regards, > > > > Ram > > > > > > > > > -----Original Message----- > > > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] > On > > > > > Behalf Of Charles Eckel (eckelcu) > > > > > Sent: Tuesday, May 10, 2011 4:41 AM > > > > > To: siprec@ietf.org > > > > > Subject: [siprec] RS Group / Recording Object issue=20 > from interim > > > > > meeting > > > > > > > > > > I am attempting to summarize the discussion we had around this > > > > > issue, and provide what I understood to be the accepted > proposal. > > > > > First, let me settle on a single term. The term RS=20 > Group will be > > > > > used to mean a collection of RS elements that=20 > comprise a single > > > > > recording. For example, > > > > > RS1 and RS2 may be two independent sessions that=20 > together form a > > > > single > > > > > recording. In such a case, the media streams associated > > > with RS1 and > > > > > RS2 > > > > > are combined into a single recording. > > > > > > > > > > Question1: Do we need an RS Group element within the > > > metadata model? > > > > > Question2: If the answer to Q1 is no, do we need an RS element > in > > > > > the metadata model? > > > > > > > > > > Use Cases: > > > > > t0: UA1 and UA2 establish CS1, and SRC1, which may be=20 > co-located > > > > > with > > > > > UA1 or UA2 or may be somewhere in between, decides to=20 > record CS1 > > > > > t1: SRC1 establishes RS1 toward SRS1 for the purpose of > > > starting a > > > > > new recording. > > > > > t2: At some point in time, RS1 is terminated for=20 > whatever reason > > > (e.g. > > > > > network issue, SRS failure, etc.) > > > > > t3: SRC1 establishes RS2 toward SRS1 for the purpose of > > > continuing > > > > > the recording. > > > > > > > > > > Option1 (using new RS Group element): > > > > > If there was a metadata element for an RS Group, RSG1, it > > > could have > > > > > > > > been created containing RS1 at time t1, then referenced > > > at time t3 > > > > > to cause RS2 to be added to RSG1 rather than creating RSG2. > > > > > > > > > > Option2 (using globally unique CS ID): > > > > > Alternatively, if SRC1 wants RS1 and RS2 to be considered part > of > > > > > the same recording, SRC1 could indicate in both RS1 and > > > RS2 that is > > > > > it CS1 that is being recorded. Since CS1 is globally unique, > SRS1 > > > > > could recognize this as being an attempt to continue the same > > > recording. > > > > > > > > > > If SRC1 instead prefers to have two separate recordings, > > > SRC1 could > > > > > indicate in RS1 that it is CS1 that is being recorded, and in > RS2 > > > > > indicate that it is CS2 that is being recorded. CS1=20 > and CS2 may > > > > contain > > > > > the same actual media, but by using different globally unique > IDs > > > > > within each RS, SRC1 can force them to be two independent > > > recordings. > > > > > > > > > > In this case, there is no need for an RS Group element, > > > nor is there > > > > > > > > a need for an RS element. > > > > > > > > > > I previously favored Option1. Following the=20 > discussion up to and > > > > > including that in the interim meeting, I am okay with Option2. > > > > > > > > > > Cheers, > > > > > Charles > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > siprec mailing list > > > > > siprec@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > _______________________________________________ > > > > siprec mailing list > > > > siprec@ietf.org > > > > https://www.ietf.org/mailman/listinfo/siprec > > > _______________________________________________ > > > siprec mailing list > > > siprec@ietf.org > > > https://www.ietf.org/mailman/listinfo/siprec > > > > = From john.elwell@siemens-enterprise.com Thu May 12 00:27: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 3F376E068B for ; Thu, 12 May 2011 00:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 d8bY32mO0xoT for ; Thu, 12 May 2011 00:27:42 -0700 (PDT) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfa.amsl.com (Postfix) with SMTP id 66F0DE066A for ; Thu, 12 May 2011 00:27:42 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1305185255!38860258!1 X-StarScan-Version: 6.2.16; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 32398 invoked from network); 12 May 2011 07:27:35 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-6.tower-27.messagelabs.com with SMTP; 12 May 2011 07:27:35 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 82D8F23F03E8 for ; Thu, 12 May 2011 09:27:41 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 12 May 2011 09:27:41 +0200 From: "Elwell, John" To: "siprec@ietf.org" Date: Thu, 12 May 2011 09:27:40 +0200 Thread-Topic: Use of RFC 2119 language in the metadata model Thread-Index: AcwQdhOQ6/kxuRXySmKl3XqMpU4g4Q== 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] Use of RFC 2119 language in the metadata model X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2011 07:27:43 -0000 Draft-ietf-metadata-00 makes extensive use of RFC 2119 language. At present= this is an Informational document (although that does not necessarily prev= ent the use of RFC 2119 language), but eventually we anticipate incorporati= ng the format material, and as a result the document would target a Propose= d Standard. The format stuff clearly has to be implemented by SRCs and SRSs= , so I would expect normative language around those aspects. However, to dr= aw a clear distinction between what has to be implemented and what is just = abstract we probably need to refrain from RFC 2119 language when just descr= ibing the abstract model. Views? John = From john.elwell@siemens-enterprise.com Thu May 12 00:28:25 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD132E066A for ; Thu, 12 May 2011 00:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 B5pnH5HrGSeX for ; Thu, 12 May 2011 00:28:22 -0700 (PDT) Received: from mail21.messagelabs.com (mail21.messagelabs.com [85.158.143.35]) by ietfa.amsl.com (Postfix) with SMTP id 031BBE0669 for ; Thu, 12 May 2011 00:28:20 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1305185295!45662986!1 X-StarScan-Version: 6.2.16; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 6816 invoked from network); 12 May 2011 07:28:15 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-8.tower-21.messagelabs.com with SMTP; 12 May 2011 07:28:15 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 86E8823F03E6; Thu, 12 May 2011 09:28:19 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 12 May 2011 09:28:19 +0200 From: "Elwell, John" To: "Muthu ArulMozhi Perumal (mperumal)" , "Ram Mohan R (rmohanr)" , Leon Portman , "Paul Kyzivat (pkyzivat)" , Henry Lum Date: Thu, 12 May 2011 09:28:18 +0200 Thread-Topic: [siprec] Does MS have life outside a particular CS? (was RE:comments on draft-ram-siprec-metadata-04) Thread-Index: AcwFuuvxdSy9/XTRSVq5DE/JiXPmDAAAgTPwAnuoqVAADSe5cAAkXwaA Message-ID: 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><07465C1D981ABC41A344374066 AE1A2C38 AB7A20DB@TL VMBX01.nice.com> <35BCE99A477D6A4986FB2216D8CF2CFD06480E2F@XMB-BGL-417.cisco.com> <1D062974A4845E4D8A343C653804920205709791@XMB-BGL-414.cisco.com> In-Reply-To: <1D062974A4845E4D8A343C653804920205709791@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] 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, 12 May 2011 07:28:25 -0000 I don't recall arguing that MS should be local to a Participant. In http://www.ietf.org/mail-archive/web/siprec/current/msg01888.html I argued MS should be local to a CS. My reasoning is as follows. Consider a conference call that has 3 media streams - audio, main video and= presentation video. Those streams will remain in existence throughout the = call, but participants will come and go. For example, the conference could = start with participants A, B and C. Then D and E could join, then A could l= eave, and so on, so you could even end up with just D, E and F in the call = at the end, but they could still be using those three media streams - audio= , main video and presentation video. So there is no single Participant that= a media stream can be anchored to for the entire call - the stream instead= has to be anchored to the CS. Also, the presentation stream can have a num= ber of different Participants transmitting to it, but only one at a time, g= overned by floor control. So I had argued that an MS should be local to a Participant. At that time, = I had assumed an MS was modelling a media stream on the CS, but the thread = then went in the direction of pointing out that really it models a media st= ream on the RS. For example, the audio stream in the above example might be= sent mixed (contributions from all participants) using a single m-line in = the RS, or might be sent unmixed using multiple m-lines in the RS. Some peo= ple were arguing that in the first case this would be modelled as one MS an= d in the second case it would be modelled as multiple MSs. I am not sure we= really resolved that (personally I was more comfortable with modelling an = MS as relating to a CS media stream. Anyway, however MS is modelled, it doesn't seem feasible to make it local t= o a Participant, but it may be feasible to make it local to a CS. But a further issue was raised on the thread. If I use the same RS m-line t= o represent a medium from a number of CSs in series, is this the same MS or= are they different MSs? If they are the same MS, it means the MS object do= es have a life outside a CS. But then I would argue it only needs an ID loc= al to the RS. If the RS object is uniquely identified by the SIP dialog ide= ntifier, the MS object would be sufficiently identified by the SDP m-line o= n that dialog. So I am afraid that before we can resolve the question of unique or local M= S identifiers, we first need to clarify what the MS object is and what its = lifetime is. John (as individual) > -----Original Message----- > From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On Behalf Of Muthu ArulMozhi > Perumal (mperumal) > Sent: 11 May 2011 14:49 > To: Ram Mohan R (rmohanr); Leon Portman; Paul Kyzivat > (pkyzivat); Henry Lum > Cc: siprec@ietf.org > Subject: Re: [siprec] Does MS have life outside a particular > CS? (was RE:comments on draft-ram-siprec-metadata-04) > > If we consider MS as local to a Participant (as John was trying to > argue) there seems to be no need for a unique ID for MS since > it can be > inferred from the Participant that can be uniquely identified. > > The mail thread describes a use-case where multicast MoH played to a > number of participants and to the SRC is recorded. Can't the > MoH source > be considered a Participant here? > > Muthu > > |-----Original Message----- > |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Ram Mohan R (rmohanr) > |Sent: Wednesday, May 11, 2011 12:52 PM > |To: Leon Portman; Paul Kyzivat (pkyzivat); Henry Lum > |Cc: siprec@ietf.org > |Subject: Re: [siprec] Does MS have life outside a particular CS? (was > RE:comments on draft-ram-siprec- > |metadata-04) > | > |Hello All, > | > |As per the discussions in last meeting and below mail thread > it appears > |that we would need global ID to take care of all the cases. However > |there is a disagreement with some folks in having a unique > ID. I would > |request people to respond on this mail thread and take this issue to > |closure. > | > |If no one has issues, we will go with globally Unique ID for > MS block. > | > |Regards, > |Ram > | > |> -----Original Message----- > |> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > |> Behalf Of Leon Portman > |> Sent: Thursday, April 28, 2011 9:28 PM > |> To: Paul Kyzivat (pkyzivat); Henry Lum > |> Cc: siprec@ietf.org > |> Subject: Re: [siprec] Does MS have life outside a > particular CS? (was > |> RE: comments on draft-ram-siprec-metadata-04) > |> > |> 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: comments 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 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=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 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 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From partr@cisco.com Sun May 15 21:06: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 583CAE071B for ; Sun, 15 May 2011 21:06:41 -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=[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 6QAQo5ujgM4N for ; Sun, 15 May 2011 21:06: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 86E8BE06C4 for ; Sun, 15 May 2011 21:06:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=50615; q=dns/txt; s=iport; t=1305518797; x=1306728397; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=C+Rbhw8WOPbinYbPqBo0o0Q0HsOEkNjG4SLN47zyTHU=; b=AK7WHBxRaQNxVRGDKNwe18OE3/KmJufaNQRyofmg8Qj8EOMItshj3Xng zWTMhDXjFUtNUsO/HAVJQi0Y5p3wF86TWsop+hAtbsAhelL5HT5IKAxEp mOS1/WMqmIJDQf/UCqi77PrgYb5rYLffsBz5Zq8RKW2q3+R0uvTKYCOQD 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtYAAEai0E2Q/khMgWdsb2JhbACCZJRnjkcUAQEWJiWoSJ0NhhkEhk6Ne4pF X-IronPort-AV: E=Sophos;i="4.64,372,1301875200"; d="scan'208,217";a="88631839" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 16 May 2011 04:06: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 p4G46YWf009454 for ; Mon, 16 May 2011 04:06: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, 16 May 2011 09:36: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_01CC137E.A4B1FC36" Date: Mon, 16 May 2011 09:36:26 +0530 Message-ID: In-Reply-To: <1D062974A4845E4D8A343C653804920205709785@XMB-BGL-414.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Comments on draft-ietf-siprec-metadata Thread-Index: AcwP38miTxO7jwEgQWSTdMC7tXiQPwDmB7cg References: <1D062974A4845E4D8A343C653804920205709785@XMB-BGL-414.cisco.com> From: "Parthasarathi R (partr)" To: "Muthu ArulMozhi Perumal (mperumal)" , X-OriginalArrivalTime: 16 May 2011 04:06:33.0770 (UTC) FILETIME=[A4BF28A0:01CC137E] Subject: Re: [siprec] Comments on draft-ietf-siprec-metadata X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 16 May 2011 04:06:41 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC137E.A4B1FC36 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Muthu, =20 Thanks for your comments in Metadata. Please read inline. =20 Thanks Partha ________________________________ From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Muthu ArulMozhi Perumal (mperumal) Sent: Wednesday, May 11, 2011 7:02 PM To: siprec@ietf.org Subject: [siprec] Comments on draft-ietf-siprec-metadata 1) The rational for associating Media Streams with Participants looks obvious. However, the rational for associating them directly with CS is not so. There is no description in the draft on how the direct association of Media Streams with CS is going to be beneficial for the SRS when the same can be inferred from the indirect association of Media Streams with Participants and Participants with the CS. =20 2) 4.5. Media Stream o Codec params - represents codec parameters of the CS media=20 This issue is tracked as http://trac.tools.ietf.org/wg/siprec/trac/ticket/71. The intent of the Codec params is to use RS SDP but it is still open issue =20 o Media Stream Reference - In implementations this can reference to m-line =20 This attribute is label attribute reference from Metadata XML =20 It is not clear what the motivations are for these attributes and how they are going to be beneficial for the SRS. =20 3) 5.4.1. Case 1 a) Shouldn't Participants D, E, F and G be attached to Participant B (which is also an SRC) instead of Media Stream B1? Figure needs to be updated as per the current closure of all participant are under CS. The current figure is as per the earlier understanding of participant are directly under RS instead of CS =20 b) Shouldn't Media Stream A1 be associated with the CS? (provided there is rational in #1).=20 Linkage is missing which will be added in the next revision =20 =20 4) 5.4.2. Case 2 The first diagram shows Participant C receiving and mixing media streams from Participants B, D and E, whereas the diagram below shows Participant C receiving and mixing media streams from Participants D and E only. Also, it looks a bit convoluted with page breaks. =20 5) The draft isn't consistent with usage of 'Participant' and 'participant'. =20 =20 Participant is represented as a metadata block always. I'm not very clear on your concern The former seems to indicate the Participant block/element, but they are used interchangeably as in: 4.3.2. Associations o Participant may be associated with zero or more CS's (It is possible, though unlikely, that there are participants who are not part of any CS). An 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 6) 4.3. Communication Session o Call Termination Reason - This represents the reason why a CS was terminated. The communication session MAY contain a Call.=20 =20 If the SRC is a focus with many participants would each participant joining the conference be considered a call? If the intention is to indicate the CS termination reason, it seems better to call this attribute as just Termination Reason.=20 This shall be changed in the next revision =20 =20 Nitpicks: =20 7) Section 3 (Metadata Model): For instance, the timing of changes may not explicitly conveyed from the SRC to the SRC, because the mechanism (yet to be defined) which conveys the metadata may implicitly provide the timing. (E.g. the time a change occurred by be assumed to be the same as the time when notification of the change is received by the SRS.) =20 s/SRC to the SRC/SRC to SRS/ s/by be assumed/may be assumed/ =20 8) 4.5. Media Stream A Media Stream block shall have properties of media as seen by SRC and sent to SRS. =20 s/shall have/SHALL have/=20 Normative language has to revisited in the next revision =20 =20 Muthu ------_=_NextPart_001_01CC137E.A4B1FC36 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Muthu,
 
Thanks for your comments in Metadata. Please read=20 inline.
 
Thanks
Partha

From: siprec-bounces@ietf.org=20 [mailto:siprec-bounces@ietf.org] On Behalf Of Muthu ArulMozhi = Perumal=20 (mperumal)
Sent: Wednesday, May 11, 2011 7:02 PM
To: = siprec@ietf.org
Subject: [siprec] Comments on=20 draft-ietf-siprec-metadata

1)=20 The rational for associating Media Streams with Participants looks = obvious.=20 However, the rational for associating them directly with CS is not so. = There is=20 no description in the draft on how the direct association of Media = Streams with=20 CS is going to be beneficial for the SRS when the same can be inferred = from the=20 indirect association of Media Streams with Participants and Participants = with=20 the CS.

 

2)=20 4.5. Media Stream

   o  Codec params -=20 represents codec parameters of the CS media 

<Partha> This=20 issue is tracked as http://trac.= tools.ietf.org/wg/siprec/trac/ticket/71. The=20 intent of the Codec params is to use RS SDP but it is still open issue=20 </Partha>

 

   o  Media Stream Reference - In=20 implementations this can reference to

      = m-line  

<Partha> This attribute is label = attribute=20 reference from Metadata XML = </Partha>

 

It=20 is not clear what the motivations are for these attributes and how they = are=20 going to be beneficial for the SRS.

 

3)=20 5.4.1. Case 1

a)=20 Shouldn't Participants D, E, F and G be attached to Participant B (which = is also=20 an SRC) instead of Media Stream B1?

<Partha> Figure=20 needs to be updated as per the current closure of all participant are = under=20 CS. The current figure is as per the earlier understanding of = participant=20 are directly under RS instead of CS = </Partha>

 

b)=20 Shouldn't Media Stream A1 be associated with = the CS?=20 (provided there is rational in #1). 

<Partha> =20 Linkage is missing which will be added in the next revision=20 </Partha> 

 

4)=20 5.4.2.  Case = 2

The = first diagram shows Participant C receiving and mixing media streams = from=20 Participants B, D and E, whereas the diagram below shows Participant C = receiving=20 and mixing media streams from Participants D and E only. Also, it looks = a bit=20 convoluted with page breaks.

 

5)=20 The draft isn't consistent with usage of 'Participant' and=20 'participant'.  

 

<Partha> = Participant is=20 represented as a metadata block always. I'm not very clear on your = concern=20 </Partha>

 The former seems to indicate the = Participant block/element, but they are used interchangeably as=20 in:

4.3.2.  = Associations

   o  Participant may be associated = with zero=20 or more CS's (It is

      = possible, though=20 unlikely, that there are participants who are not

      part = of any=20 CS).  An example of such a = case is=20 participants in a

      = premixed media=20 stream.  The SRC may have knowledge of = such

      = Participants,=20 yet not have any signaling relationship with them.

      This = might arise=20 if one participant in CS is a conf focus.

 

6)=20 4.3.  Communication=20 Session

   o  Call Termination Reason - This = represents the reason why a CS was

      = terminated.  The communication session MAY = contain a=20 Call. 

 

If=20 the SRC is a focus with many participants = would each=20 participant joining the conference be considered a call? If the = intention is to=20 indicate the CS termination reason, it seems better to call this = attribute as=20 just Termination Reason. 

<Partha> This=20 shall be changed in the next revision=20 </Partha>  

 

Nitpicks:

 

7)=20 Section 3 (Metadata Model):

For = instance, the timing of changes may not explicitly conveyed from the = SRC to the SRC, = because the=20 mechanism (yet to be defined) which conveys the metadata may implicitly = provide=20 the timing.  (E.g. the = time a change=20 occurred by be assumed to be the same as the time when notification of = the=20 change is received by the SRS.)

 

s/SRC to the SRC/SRC to SRS/

s/by=20 be assumed/may be assumed/

 

8)=20 4.5. Media Stream

A=20 Media Stream block shall have properties of media as seen by SRC and sent to SRS.

 

s/shall=20 have/SHALL have/ 

<Partha> Normative=20 language has to revisited in the next revision=20 </Partha> 

 

Muthu

------_=_NextPart_001_01CC137E.A4B1FC36-- From rmohanr@cisco.com Mon May 16 03:20:34 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE8BE06F7 for ; Mon, 16 May 2011 03:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.669 X-Spam-Level: X-Spam-Status: No, score=-9.669 tagged_above=-999 required=5 tests=[AWL=0.929, 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 mTcmAwvay6SR for ; Mon, 16 May 2011 03:20:33 -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 6548AE069A for ; Mon, 16 May 2011 03:20:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=12764; q=dns/txt; s=iport; t=1305541232; x=1306750832; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=+8lXY9G8b9JT0GxC2GOYMByYTTvtoAx8wPMnYeZ/EjI=; b=ZGE1trrVSsOEQXVHDRUAtUFgCEaGvRvC5XK2rRp5exdfsXtS6nQN0LIv Ub8tjxm3C8oUclqHTFbAe7SBuKxA5lq4Fwp9EDzFe7SK97nDg+Rxs7ow9 dAal353cR/OGnvF2REhr+2lQbIEpPespl9f+socI6KTuQsRi61+ODEgh5 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq4AAPf50E2Q/khLgWdsb2JhbACXS45IFAEBFiYliHCgDZ09hhkEhk6Ne4pF X-IronPort-AV: E=Sophos;i="4.64,373,1301875200"; d="scan'208";a="30415624" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 16 May 2011 10:20:30 +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 p4GAKQDG018163; Mon, 16 May 2011 10:20:30 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, 16 May 2011 15:50: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: Mon, 16 May 2011 15:50:18 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD06599C71@XMB-BGL-417.cisco.com> In-Reply-To: <059AF07365DC474393A19A3AF187DF74070C2B3A@NAHALD.us.int.genesyslab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] RS Group / Recording Object issue from interim meeting Thread-Index: AcwOnlUD796ZsvbMTUylbGle0/maUwAOn8yAAAGlS7AAEs9kUAAAhHRQAAC4X4AAAGUVEAAB8S1AAAB6WcAAMVgKoADsoENg References: <35BCE99A477D6A4986FB2216D8CF2CFD06480A28@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD06480C54@XMB-BGL-417.cisco.com> <07465C1D981ABC41A344374066AE1A2C38AB848F1D@TLVMBX01.nice.com> <059AF07365DC474393A19A3AF187DF74070C2B3A@NAHALD.us.int.genesyslab.com> From: "Ram Mohan R (rmohanr)" To: "Henry Lum" , "Leon Portman" , "Charles Eckel (eckelcu)" , "Elwell, John" , "Parthasarathi R (partr)" , X-OriginalArrivalTime: 16 May 2011 10:20:20.0706 (UTC) FILETIME=[DC3E0420:01CC13B2] Subject: Re: [siprec] RS Group / Recording Object issue from 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: Mon, 16 May 2011 10:20:34 -0000 Henry, Thanks for these comments. I will incorporate them in the next version of the draft. Ram > -----Original Message----- > From: Henry Lum [mailto:Henry.Lum@alcatel-lucent.com] > Sent: Wednesday, May 11, 2011 11:10 PM > To: Leon Portman; Charles Eckel (eckelcu); Ram Mohan R (rmohanr); > Elwell, John; Parthasarathi R (partr); siprec@ietf.org > Subject: RE: [siprec] RS Group / Recording Object issue from interim > meeting >=20 > Agreed with below as well. >=20 > An additional comment is that we may want to point out that one or more > SRC may reference the same CS by referring to the same global unique > ID. > How the SRC figure out the same reference to the CS belongs to an > external mechanism which is out of scope for this group. >=20 > Likewise for the CSG, and I see that in section 4.1.2 (the last > sentence) that indicates a CSG may only belong to a single SRC. We > should clarify that a CSG may be referenced by one or more SRCs as long > as they refer to the same unique identifier. >=20 > Henry >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Leon Portman > > Sent: Tuesday, May 10, 2011 1:53 PM > > To: Charles Eckel (eckelcu); Ram Mohan R (rmohanr); Elwell, John; > > Parthasarathi R (partr); siprec@ietf.org > > Subject: Re: [siprec] RS Group / Recording Object issue from interim > > meeting > > > > I agree with below. Just additional comment that the actual fact how > > recordings are stored in the file system; one file or multiple chunks > > are implementation details of SRS. What is important that SRS will > have > > all relevant information (like unique CS ID) to be able to find, > > display and of course playback all relevant RS pieces > > > > Leon > > > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Charles Eckel (eckelcu) > > Sent: Tuesday, May 10, 2011 8:39 PM > > To: Ram Mohan R (rmohanr); Elwell, John; Parthasarathi R (partr); > > siprec@ietf.org > > Subject: Re: [siprec] RS Group / Recording Object issue from interim > > meeting > > > > The proposed text works better for me if you change both instances of > > "the" to "a" to remain consistent with the many to many relationship > of > > CS to RS. > > > > Cheers, > > Charles > > > > > -----Original Message----- > > > From: Ram Mohan R (rmohanr) > > > Sent: Tuesday, May 10, 2011 9:47 AM > > > To: Elwell, John; Parthasarathi R (partr); Charles Eckel (eckelcu); > > siprec@ietf.org > > > Subject: RE: [siprec] RS Group / Recording Object issue from > interim > > meeting > > > > > > Hi John / Charles, > > > > > > I will update the text in metadata model draft > > (draft-ietf-siprec-metadata-00) in the next revision to > > > reflect this. > > > > > > Here is the text I suggest to be modified in Section 4.1 of draft. > > Please comment on this and > > > edit/refine the text: > > > > > > Current text is > > > "A Recording Session element represents one instance of a Recording > > Session." > > > > > > Proposed text is : > > > "A Recording Session element represents the SIP session created > > between an SRC and SRS for the purpose > > > of recording a Communication Session. The SIP RS dialog SHALL be > > mapped to this element and hence > > > there is no need for this element to be reflected in XML" > > > > > > Regards, > > > Ram > > > > > > > -----Original Message----- > > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > Sent: Tuesday, May 10, 2011 10:07 PM > > > > To: Parthasarathi R (partr); Charles Eckel (eckelcu); Ram Mohan R > > > > (rmohanr); siprec@ietf.org > > > > Subject: RE: [siprec] RS Group / Recording Object issue from > > interim > > > > meeting > > > > > > > > This thread looks like it is heading in a direction that is > > acceptable > > > > to me. Keeping RS in the model should not necessarily imply that > it > > has > > > > to be reflected in XML, if the SIP dialog itself is sufficient. > > > > > > > > John (as individual) > > > > > > > > > -----Original Message----- > > > > > From: siprec-bounces@ietf.org > > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi R > > (partr) > > > > > Sent: 10 May 2011 17:11 > > > > > To: Charles Eckel (eckelcu); Ram Mohan R (rmohanr); > > siprec@ietf.org > > > > > Subject: Re: [siprec] RS Group / Recording Object issue from > > > > > interim meeting > > > > > > > > > > Hi Charles, > > > > > > > > > > I agree with you to add the text which helps to distinct RS > from > > > > > recording. > > > > > > > > > > Thanks > > > > > Partha > > > > > > > > > > -----Original Message----- > > > > > From: Charles Eckel (eckelcu) > > > > > Sent: Tuesday, May 10, 2011 9:32 PM > > > > > To: Parthasarathi R (partr); Ram Mohan R (rmohanr); > > 'siprec@ietf.org' > > > > > Subject: RE: [siprec] RS Group / Recording Object issue from > > interim > > > > > meeting > > > > > > > > > > Hi Partha, > > > > > > > > > > The problem for me was that I started thinking of the RS as > being > > > > > equivalent to a recording. If we leave the RS in the model, it > > > > > would be good to clarify the distinction. > > > > > > > > > > Cheers, > > > > > Charles > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Parthasarathi R (partr) > > > > > > Sent: Tuesday, May 10, 2011 12:25 AM > > > > > > To: Ram Mohan R (rmohanr); Charles Eckel (eckelcu); > > siprec@ietf.org > > > > > > Subject: RE: [siprec] RS Group / Recording Object issue > > > > > from interim > > > > > > meeting > > > > > > > > > > > > Charles, > > > > > > > > > > > > Just adding to Ram mentioned, draft-jones-ipmc-session-id-01 > > > > > > Session-UUID or draft-kaplan-dispatch- > > > > > > session-id-03 Session-id or other proprietary unique-id may > > > > > be used in > > > > > > > > > > > CS to make your proposed solution work. IMO, it is outside > the > > > > scope > > > > > of SIPREC and I favor OPTION 2. > > > > > > > > > > > > The reason for having RS element in the model is to show the > > model > > > > > > from SRS perspective and in case of metadata format, SIP > > Message > > > > > > information (Dialog-id, Date header) shall be re-used instead > > of > > > > > having separate RS specific XML elements. > > > > > > > > > > > > Thanks > > > > > > Partha > > > > > > > > > > > > -----Original Message----- > > > > > > From: siprec-bounces@ietf.org [mailto:siprec- > bounces@ietf.org] > > On > > > > > > Behalf Of Ram Mohan R (rmohanr) > > > > > > Sent: Tuesday, May 10, 2011 11:50 AM > > > > > > To: Charles Eckel (eckelcu); siprec@ietf.org > > > > > > Subject: Re: [siprec] RS Group / Recording Object issue > > > > > from interim > > > > > > meeting > > > > > > > > > > > > As I mentioned in the meeting yesterday, CS Unique ID > > > > > should suffice > > > > > > to correlate disparate recordings and hence we don't need > > RS-Group > > > > > element. > > > > > > How SRC(s) share this CS Unique ID is something that is > > > > > currently left > > > > > to implementers(out of scope). > > > > > > > > > > > > so I favor Option2 > > > > > > > > > > > > Regards, > > > > > > Ram > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: siprec-bounces@ietf.org [mailto:siprec- > > bounces@ietf.org] > > On > > > > > > > Behalf Of Charles Eckel (eckelcu) > > > > > > > Sent: Tuesday, May 10, 2011 4:41 AM > > > > > > > To: siprec@ietf.org > > > > > > > Subject: [siprec] RS Group / Recording Object issue from > > interim > > > > > > > meeting > > > > > > > > > > > > > > I am attempting to summarize the discussion we had around > > this > > > > > > > issue, and provide what I understood to be the accepted > > proposal. > > > > > > > First, let me settle on a single term. The term RS Group > will > > be > > > > > > > used to mean a collection of RS elements that comprise a > > single > > > > > > > recording. For example, > > > > > > > RS1 and RS2 may be two independent sessions that together > > form > > a > > > > > > single > > > > > > > recording. In such a case, the media streams associated > > > > > with RS1 and > > > > > > > RS2 > > > > > > > are combined into a single recording. > > > > > > > > > > > > > > Question1: Do we need an RS Group element within the > > > > > metadata model? > > > > > > > Question2: If the answer to Q1 is no, do we need an RS > > element > > in > > > > > > > the metadata model? > > > > > > > > > > > > > > Use Cases: > > > > > > > t0: UA1 and UA2 establish CS1, and SRC1, which may be > > co-located > > > > > > > with > > > > > > > UA1 or UA2 or may be somewhere in between, decides to > record > > CS1 > > > > > > > t1: SRC1 establishes RS1 toward SRS1 for the purpose of > > > > > starting a > > > > > > > new recording. > > > > > > > t2: At some point in time, RS1 is terminated for whatever > > reason > > > > > (e.g. > > > > > > > network issue, SRS failure, etc.) > > > > > > > t3: SRC1 establishes RS2 toward SRS1 for the purpose of > > > > > continuing > > > > > > > the recording. > > > > > > > > > > > > > > Option1 (using new RS Group element): > > > > > > > If there was a metadata element for an RS Group, RSG1, it > > > > > could have > > > > > > > > > > > > been created containing RS1 at time t1, then referenced > > > > > at time t3 > > > > > > > to cause RS2 to be added to RSG1 rather than creating RSG2. > > > > > > > > > > > > > > Option2 (using globally unique CS ID): > > > > > > > Alternatively, if SRC1 wants RS1 and RS2 to be considered > > part > > of > > > > > > > the same recording, SRC1 could indicate in both RS1 and > > > > > RS2 that is > > > > > > > it CS1 that is being recorded. Since CS1 is globally > unique, > > SRS1 > > > > > > > could recognize this as being an attempt to continue the > same > > > > > recording. > > > > > > > > > > > > > > If SRC1 instead prefers to have two separate recordings, > > > > > SRC1 could > > > > > > > indicate in RS1 that it is CS1 that is being recorded, and > in > > RS2 > > > > > > > indicate that it is CS2 that is being recorded. CS1 and CS2 > > may > > > > > > contain > > > > > > > the same actual media, but by using different globally > unique > > IDs > > > > > > > within each RS, SRC1 can force them to be two independent > > > > > recordings. > > > > > > > > > > > > > > In this case, there is no need for an RS Group element, > > > > > nor is there > > > > > > > > > > > > a need for an RS element. > > > > > > > > > > > > > > I previously favored Option1. Following the discussion up > to > > and > > > > > > > including that in the interim meeting, I am okay with > > Option2. > > > > > > > > > > > > > > Cheers, > > > > > > > Charles > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > siprec mailing list > > > > > > > siprec@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > _______________________________________________ > > > > > > siprec mailing list > > > > > > siprec@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > _______________________________________________ > > > > > siprec mailing list > > > > > siprec@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > _______________________________________________ > > siprec mailing 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 > ----------------------------------------------------------------------- > -------------------------------------------- > 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 From john.elwell@siemens-enterprise.com Wed May 18 01:17:42 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 C2FA5E0714 for ; Wed, 18 May 2011 01:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.507 X-Spam-Level: X-Spam-Status: No, score=-106.507 tagged_above=-999 required=5 tests=[AWL=0.092, 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 0X2XvRUD9rcO for ; Wed, 18 May 2011 01:17:41 -0700 (PDT) Received: from mail182.messagelabs.com (mail182.messagelabs.com [85.158.139.83]) by ietfa.amsl.com (Postfix) with SMTP id 4B735E069E for ; Wed, 18 May 2011 01:17:41 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1305706660!7322145!1 X-StarScan-Version: 6.2.16; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 29165 invoked from network); 18 May 2011 08:17:40 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-5.tower-182.messagelabs.com with SMTP; 18 May 2011 08:17:40 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 288581EB83D3; Wed, 18 May 2011 10:17: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, 18 May 2011 10:17:40 +0200 From: "Elwell, John" To: "siprec@ietf.org" , "'Gonzalo.Camarillo@ericsson.com'" Date: Wed, 18 May 2011 10:17:38 +0200 Thread-Topic: Poll for dates for next interim virtual meeting Thread-Index: AcwO55V9NupxN2VvQmuzKsE7oYixHwGSroFQ Message-ID: Keywords: SIPREC Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Poll for dates for next interim virtual 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, 18 May 2011 08:17:42 -0000 The poll is now closed. Two slots seemed to work for most people, but as th= e later date was getting uncomfortably close to IETF#81, I picked the earli= er one. The next interim virtual meeting will be on Thursday 2011-06-23 from 13.00-= 15.00 GMT - see here for local times: http://www.timeanddate.com/worldclock/fixedtime.html?msg=3DSIPREC+interim&i= so=3D20110623T13&ah=3D2 John > -----Original Message----- > From: Elwell, John=20 > Sent: 10 May 2011 08:55 > To: siprec@ietf.org > Subject: Poll for dates for next interim virtual meeting >=20 > As agreed yesterday, I have initiated a poll for dates in=20 > late June for another call, to focus on the protocol (which=20 > we didn't get done yesterday) and perhaps some specific=20 > issues we fail to resolve on the list in the meantime. We can=20 > cancel if no longer needed. >=20 > Here is the link - please respond by 2011-05-17. > http://doodle.com/dpu5w4w73uk49mb8 >=20 > John > = From john.elwell@siemens-enterprise.com Wed May 18 02:02: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 8222CE07C6 for ; Wed, 18 May 2011 02:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.219 X-Spam-Level: X-Spam-Status: No, score=-106.219 tagged_above=-999 required=5 tests=[AWL=-0.220, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, 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 dDzdCJAMpjJW for ; Wed, 18 May 2011 02:02:52 -0700 (PDT) Received: from mail21.messagelabs.com (mail21.messagelabs.com [85.158.143.35]) by ietfa.amsl.com (Postfix) with SMTP id D2C58E0714 for ; Wed, 18 May 2011 02:02:51 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-9.tower-21.messagelabs.com!1305709344!40662071!1 X-StarScan-Version: 6.2.16; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 30149 invoked from network); 18 May 2011 09:02:24 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-9.tower-21.messagelabs.com with SMTP; 18 May 2011 09:02:24 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 79F1E23F03E6 for ; Wed, 18 May 2011 11:02: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, 18 May 2011 11:02:50 +0200 From: "Elwell, John" To: "siprec@ietf.org" Date: Wed, 18 May 2011 11:02:49 +0200 Thread-Topic: Final minutes of May interim Thread-Index: AcwVOlyIcw1ttcTlQgiVK73JFIclow== 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] Final minutes of May interim X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 09:02:53 -0000 (The only change was correction of presenter's name for metadata model) ##################################################################### Minutes of the SIPREC WG Interim Virtual Meeting 2011-05-09, 14.00-16.00 GMT/UTC =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Meeting chaired by Brian Rosen and John Elwell. Participants: Brian Rosen, John Elwell, Ken Rehor, Leon Portman, Henry Lum,= Ram Mohan, Andy Hutton, Paul Kyzivat, Parthasarathi, Dan Romascanu, Charle= s Eckel, Mary Barnes, Arul Muthu Minutes produced by John Elwell based on notes from Andy Hutton. Jabber log: None of the meeting participants were on Jabber. Recording: Owing to misoperation, the meeting was not recorded. Meeting started at 14.05. Topic - Administrivia (chairs) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D Slides: http://kenrehor.com/ietf/siprec/IETF80.1/Chairs.pdf No changes to published agenda. Topic - Architecture (Andy Hutton) draft-ietf-siprec-architecture-02 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D Draft: https://datatracker.ietf.org/doc/draft-ietf-siprec-architecture/ Slides: http://kenrehor.com/ietf/siprec/IETF80.1/201105_SIPREC_Interim_Draf= t-ietf-siprec-architecture-Status.pdf Slides 4/5 - There was a discussion on SRC Decomposition and Partha's comme= nt that the figures in the document should show the SRC split into two sepa= rate UA's one on the CS side and one on the RS side. Andy stated that he di= d not fully understand the need for showing such a decomposition but maybe = further study of the RTP Model might indicate a reason why this might be ne= eded. No other views were expressed and it was agreed that Andy would keep = the discussion going on the list to get consensus. Topic - RTP Model (Charles Eckel) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D Slides: http://kenrehor.com/ietf/siprec/IETF80.1/RTP%20model.pdf Charles had sent out on the list some proposed text on the RTP model (incor= porating text from Andy Hutton merged with earlier text from himself). The = text was targeted at incorporation into the architecture draft. Arul pointed out that the RTP translator model did not allow the SRC to add= any value in terms of synchronising streams, therefore the model might nee= d augmenting (in the area of RTCP handling) or considered not applicable. The text certainly needs more discussion to gain WG consensus before incorp= oration in the architecture draft, and therefore Charles kindly agreed to p= ut it into a separate individual draft (with the help of others as necessar= y) for further discussion. Also, when this is available, the chairs will tr= y to get some involvement of experts in AVTCORE and try to avoid clashes wi= th AVTxxx meetings in Quebec City, so that experts can attend if needed. Topic - Metadata model(Ram Mohan) draft-ietf-siprec-metadata-00 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Draft: https://datatracker.ietf.org/doc/draft-ietf-siprec-metadata/ Slides: http://kenrehor.com/ietf/siprec/IETF80.1/SIPREC%20Metamodel%20-%20V= irtual%20Interim-May09_2011.pdf Slide 6 - On the open issue concerning any additional direct associates wit= h the RS block, there were no proposals for additions. Slide 7 - There was considerable discussion on the need for a Recording Ses= sion object. Paul Kyzivat doubted that we really need to refer to an RS obj= ect from elsewhere, and if not, why model an RS in metadata? Henry asked wh= ether we have a requirement for pausing a whole RS, as opposed to media str= eams, since this might be justification for an RS object. Although the meet= ing was tending towards considering pause of the entire RS as not needed, m= ore discussion is required on the need for this and on the consequences for= the model if it is needed. Notwithstanding the pause issue, can we move forward without an RS object a= nd without any other object representing a Recording or Recording Group (an= object we had previously but discarded)? Charles pointed out two cases: wh= en two SRCs need to create separate recordings of the same CS; and when som= ething goes wrong during recording of a CS and the SRC wants to initiate a = new RS to continue recording the same CS. Although the unique CS object ide= ntifier is sufficient for either case, it is not sufficient to distinguish = the two cases. The meeting was probably tending towards not needing an RS object (or any o= ther object representing a recording or group of recordings), but more list= discussion is needed. Charles kindly agreed to start a new thread and list= his summary of the situation and his views. There was agreement that the attributes of an RS are not needed (there had = been email discussion stating why not). There was insufficient time to review the remaining issues in the slides. Topic - Metadata format(Parthasarasi R) draft-ram-siprec-metadata-format-01 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Draft: https://datatracker.ietf.org/doc/draft-ram-siprec-metadata-format/ Slides: http://kenrehor.com/ietf/siprec/IETF80.1/SIPREC%20Metamodel%20Forma= t-Interim-May9-2011.pdf Slide 5, open issue 1 - There was no disagreement on allowing a many-to-man= y relationship between RS and CS objects. Slide 6, open issue 2 - Skipped, as this relates to the ongoing discussion = on the model. Slide 7, open issue 3 - There was no disagreement that both CSG and CS obje= cts should have globally unique IDs. Slide 8, open issue 4 - The issue of whether a Media Stream (MS) object nee= ds a globally unique ID seems to depend on whether a single MS can have a l= ifetime outside the context of a single CS. Needs further list discussion. Slide 9, open issue 5 - Although some thought it would be sufficient for a = Participant object to be unique within the context of a CS or CSG, Charles = was concerned we may need a means of identifying the same Participant in se= veral CSs, e.g., over a call transfer. Charles noted that the general concept of globally unique identifiers and r= amifications for back-end storage had arisen at the Prague meeting, but tho= se with concerns on that occasion were not present on this occasion. Paul s= uggested that the use of globally unique identifiers on the SIPREC interfac= e does not necessarily prevent the SRS finding other solutions for back-end= storage or retrieval. More list discussion needed. Slide 10, open Issue 6 - There was only time for limited discussion. This i= s not really an XML extensibility issue. There was insufficient time to review the remaining issues in the slides. Topic - Protocol (Henry Lum) draft-portman-siprec-protocol-04 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Draft: https://datatracker.ietf.org/doc/draft-portman-siprec-protocol/ Slides: http://kenrehor.com/ietf/siprec/IETF80.1/SIPREC%20Protocol%20-%20Vi= rtual%20Interim%20-%2020110509.pdf There was no time for this topic. Wrap-up =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D In view of failing to finish the agenda, it was suggested we have another i= nterim virtual meeting during the second half of June. This should cover th= e protocol as well as some specific topics that are still open following li= st discussion. However, the aim should be to try to resolve as much as poss= ible on the list during the next few weeks. The chairs will try to arrange = a second interim virtual meeting, which can be cancelled if not needed. The meeting was closed at 16.05. From partr@cisco.com Wed May 18 10:49: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 90473E06C8 for ; Wed, 18 May 2011 10:49:03 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BSA9HQl8NQ5H for ; Wed, 18 May 2011 10:49:00 -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 40BF6E06B3 for ; Wed, 18 May 2011 10:48:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=33830; q=dns/txt; s=iport; t=1305740939; x=1306950539; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=44g/WcmXImdh+CDP4AXyyoNAwgSyO2G3gKO67nFbBk8=; b=iH+RwgRRaJh27Tre59+lS3B8yycq6LpAPWmqRs/RiCyTK+vABcNLTetS QpCwYnaY5FYzTLT7PT5ox6Qhfjw/kacEWkwspJhfGaNIKeaDrqOwZ/66C J7evG8dwEqpKnYtPdttV8kk/g7ZLjiHtcMHyYHSBKXfF/jnTxEqiHT1kG 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwAAHgF1E1Io8UT/2dsb2JhbACXT45Nd6hjngKDDQEGgwUEhk6Ne4pFNA X-IronPort-AV: E=Sophos;i="4.65,232,1304294400"; d="scan'208";a="89273308" Received: from bgl-core-4.cisco.com ([72.163.197.19]) by ams-iport-1.cisco.com with ESMTP; 18 May 2011 17:48:56 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p4IHmtTb009873; Wed, 18 May 2011 17:48:55 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, 18 May 2011 23:18:55 +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, 18 May 2011 23:18:50 +0530 Message-ID: In-Reply-To: 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: AcwFuuvxdSy9/XTRSVq5DE/JiXPmDAAAgTPwAnuoqVAADSe5cAAkXwaAAUQXHCA= 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><07465C1D981ABC41A344374066A E1A2C38 AB7A20DB@TL VMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD06480E2F@XMB-BGL-417.cisco.com><1D062974A4845E4D8A343C653804920205709791@XMB-BGL-414.cisco.com> From: "Parthasarathi R (partr)" To: "Elwell, John" , "Muthu Arul Mozhi Perumal (mperumal)" , "Ram Mohan R (rmohanr)" , "Leon Portman" , "Paul Kyzivat (pkyzivat)" , "Henry Lum" X-OriginalArrivalTime: 18 May 2011 17:48:55.0275 (UTC) FILETIME=[DB66D3B0:01CC1583] 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, 18 May 2011 17:49:03 -0000 John, Your below mail is a good summary for the decision happened so far. MS lifetime depends upon the relation between RS & CS in a given deployment. My understanding w.r.t RS & CS relationship for MS lifetime is as follows: One RS - One CS: MS lifetime is within the scope of single RS or single CS=20 One RS - Many CS: MS lifetime is within the scope of single RS=20 Many RS - One CS: MS lifetime is within the scope of single CS Many RS - Many CS: MS lifetime is within the scope of Multiple RS or Multiple CS.=20 As Many RS- Many CS mechanism is adopted, there is a need for global unique id for MS. Thanks Partha -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John Sent: Thursday, May 12, 2011 12:58 PM To: Muthu ArulMozhi Perumal (mperumal); Ram Mohan R (rmohanr); Leon Portman; Paul Kyzivat (pkyzivat); Henry Lum Cc: siprec@ietf.org Subject: Re: [siprec] Does MS have life outside a particular CS?(was RE:comments on draft-ram-siprec-metadata-04) I don't recall arguing that MS should be local to a Participant. In http://www.ietf.org/mail-archive/web/siprec/current/msg01888.html I argued MS should be local to a CS. My reasoning is as follows. Consider a conference call that has 3 media streams - audio, main video and presentation video. Those streams will remain in existence throughout the call, but participants will come and go. For example, the conference could start with participants A, B and C. Then D and E could join, then A could leave, and so on, so you could even end up with just D, E and F in the call at the end, but they could still be using those three media streams - audio, main video and presentation video. So there is no single Participant that a media stream can be anchored to for the entire call - the stream instead has to be anchored to the CS. Also, the presentation stream can have a number of different Participants transmitting to it, but only one at a time, governed by floor control. So I had argued that an MS should be local to a Participant. At that time, I had assumed an MS was modelling a media stream on the CS, but the thread then went in the direction of pointing out that really it models a media stream on the RS. For example, the audio stream in the above example might be sent mixed (contributions from all participants) using a single m-line in the RS, or might be sent unmixed using multiple m-lines in the RS. Some people were arguing that in the first case this would be modelled as one MS and in the second case it would be modelled as multiple MSs. I am not sure we really resolved that (personally I was more comfortable with modelling an MS as relating to a CS media stream. Anyway, however MS is modelled, it doesn't seem feasible to make it local to a Participant, but it may be feasible to make it local to a CS. But a further issue was raised on the thread. If I use the same RS m-line to represent a medium from a number of CSs in series, is this the same MS or are they different MSs? If they are the same MS, it means the MS object does have a life outside a CS. But then I would argue it only needs an ID local to the RS. If the RS object is uniquely identified by the SIP dialog identifier, the MS object would be sufficiently identified by the SDP m-line on that dialog. So I am afraid that before we can resolve the question of unique or local MS identifiers, we first need to clarify what the MS object is and what its lifetime is. John (as individual) > -----Original Message----- > From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On Behalf Of Muthu ArulMozhi Perumal=20 > (mperumal) > Sent: 11 May 2011 14:49 > To: Ram Mohan R (rmohanr); Leon Portman; Paul Kyzivat (pkyzivat);=20 > Henry Lum > Cc: siprec@ietf.org > Subject: Re: [siprec] Does MS have life outside a particular CS? (was=20 > RE:comments on draft-ram-siprec-metadata-04) > > If we consider MS as local to a Participant (as John was trying to > argue) there seems to be no need for a unique ID for MS since it can=20 > be inferred from the Participant that can be uniquely identified. > > The mail thread describes a use-case where multicast MoH played to a=20 > number of participants and to the SRC is recorded. Can't the MoH=20 > source be considered a Participant here? > > Muthu > > |-----Original Message----- > |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Ram Mohan R (rmohanr) > |Sent: Wednesday, May 11, 2011 12:52 PM > |To: Leon Portman; Paul Kyzivat (pkyzivat); Henry Lum > |Cc: siprec@ietf.org > |Subject: Re: [siprec] Does MS have life outside a particular CS? (was > RE:comments on draft-ram-siprec- > |metadata-04) > | > |Hello All, > | > |As per the discussions in last meeting and below mail thread > it appears > |that we would need global ID to take care of all the cases. However=20 > |there is a disagreement with some folks in having a unique > ID. I would > |request people to respond on this mail thread and take this issue to=20 > |closure. > | > |If no one has issues, we will go with globally Unique ID for > MS block. > | > |Regards, > |Ram > | > |> -----Original Message----- > |> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > |> Behalf Of Leon Portman > |> Sent: Thursday, April 28, 2011 9:28 PM > |> To: Paul Kyzivat (pkyzivat); Henry Lum > |> Cc: siprec@ietf.org > |> Subject: Re: [siprec] Does MS have life outside a > particular CS? (was > |> RE: comments on draft-ram-siprec-metadata-04) > |> > |> 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=20 > |> 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: comments 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=20 > |> > 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=20 > |> 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=20 > |> 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=20 > |> 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=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=20 > |> >>>>>>> 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=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 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. > |> >>> > |> >>> > |> > > |> > > |> > > |--------------------------------------------------------------------- > |> - > |> > --------------------------------------------- > |> > CONFIDENTIALITY NOTICE: This e-mail and any files attached may > |> contain confidential and proprietary information of Alcatel-Lucent=20 > |> 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=20 > |> 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 > _______________________________________________ > siprec mailing 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 May 18 11:54:37 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F267DE06B0 for ; Wed, 18 May 2011 11:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.511 X-Spam-Level: X-Spam-Status: No, score=-106.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 qsYOIey+P8tk for ; Wed, 18 May 2011 11:54:34 -0700 (PDT) Received: from mail174.messagelabs.com (mail174.messagelabs.com [85.158.138.51]) by ietfa.amsl.com (Postfix) with SMTP id 23DE1E06B1 for ; Wed, 18 May 2011 11:54:32 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-5.tower-174.messagelabs.com!1305744871!18800099!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 21439 invoked from network); 18 May 2011 18:54:31 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-5.tower-174.messagelabs.com with SMTP; 18 May 2011 18:54:31 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 8A9D123F03E8; Wed, 18 May 2011 20:54:31 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 18 May 2011 20:54:31 +0200 From: "Elwell, John" To: "Parthasarathi R (partr)" , "Muthu Arul Mozhi Perumal (mperumal)" , "Ram Mohan R (rmohanr)" , Leon Portman , "Paul Kyzivat (pkyzivat)" , Henry Lum Date: Wed, 18 May 2011 20:54:30 +0200 Thread-Topic: [siprec] Does MS have life outside a particular CS?(was RE:comments on draft-ram-siprec-metadata-04) Thread-Index: AcwFuuvxdSy9/XTRSVq5DE/JiXPmDAAAgTPwAnuoqVAADSe5cAAkXwaAAUQXHCAAAoVIAA== Message-ID: 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><07465C1D981ABC41A344374066A E1A2C38 AB7A20DB@TL VMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD06480E2F@XMB-BGL-417.cisco.com><1D062974A4845E4D8A343C653804920205709791@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] 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, 18 May 2011 18:54:37 -0000 > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > Sent: 18 May 2011 18:49 > To: Elwell, John; Muthu Arul Mozhi Perumal (mperumal); Ram > Mohan R (rmohanr); Leon Portman; Paul Kyzivat (pkyzivat); Henry Lum > Cc: siprec@ietf.org > Subject: RE: [siprec] Does MS have life outside a particular > CS?(was RE:comments on draft-ram-siprec-metadata-04) > > John, > > Your below mail is a good summary for the decision happened so far. MS > lifetime depends upon the relation between RS & CS in a given > deployment. My understanding w.r.t RS & CS relationship for > MS lifetime > is as follows: > > One RS - One CS: MS lifetime is within the scope of single RS > or single > CS > > One RS - Many CS: MS lifetime is within the scope of single RS > > Many RS - One CS: MS lifetime is within the scope of single CS [JRE] I don't follow your reasoning with the above two bullets. I think thi= s gives MS an inconsistent meaning, in that an MS sometimes maps to one RS = and multiple CS, and in other situations an MS maps to one CS and multiple = RSs. I would have great difficulty understanding what a MS really is. Up to= now we have discussed a MS having a lifetime only in the context of a CS a= nd at other times we have discussed a MS having a lifetime only in the cont= ext of an RS (in this case a 1:1 mapping to an m-line in the SDP). > > Many RS - Many CS: MS lifetime is within the scope of Multiple RS or > Multiple CS. [JRE] In this case, what is the defining character of an MS, making it the = same MS even though it spans many CSs and many RSs? I can't really grasp th= e concept. John (as individual) > > As Many RS- Many CS mechanism is adopted, there is a need for global > unique id for MS. > > Thanks > Partha > > > -----Original Message----- > From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On Behalf > Of Elwell, John > Sent: Thursday, May 12, 2011 12:58 PM > To: Muthu ArulMozhi Perumal (mperumal); Ram Mohan R (rmohanr); Leon > Portman; Paul Kyzivat (pkyzivat); Henry Lum > Cc: siprec@ietf.org > Subject: Re: [siprec] Does MS have life outside a particular CS?(was > RE:comments on draft-ram-siprec-metadata-04) > > I don't recall arguing that MS should be local to a Participant. In > http://www.ietf.org/mail-archive/web/siprec/current/msg01888.html > I argued MS should be local to a CS. My reasoning is as follows. > > Consider a conference call that has 3 media streams - audio, > main video > and presentation video. Those streams will remain in existence > throughout the call, but participants will come and go. For > example, the > conference could start with participants A, B and C. Then D > and E could > join, then A could leave, and so on, so you could even end up > with just > D, E and F in the call at the end, but they could still be using those > three media streams - audio, main video and presentation > video. So there > is no single Participant that a media stream can be anchored > to for the > entire call - the stream instead has to be anchored to the > CS. Also, the > presentation stream can have a number of different Participants > transmitting to it, but only one at a time, governed by floor control. > > So I had argued that an MS should be local to a Participant. At that > time, I had assumed an MS was modelling a media stream on the CS, but > the thread then went in the direction of pointing out that really it > models a media stream on the RS. For example, the audio stream in the > above example might be sent mixed (contributions from all > participants) > using a single m-line in the RS, or might be sent unmixed > using multiple > m-lines in the RS. Some people were arguing that in the first > case this > would be modelled as one MS and in the second case it would > be modelled > as multiple MSs. I am not sure we really resolved that > (personally I was > more comfortable with modelling an MS as relating to a CS > media stream. > > Anyway, however MS is modelled, it doesn't seem feasible to make it > local to a Participant, but it may be feasible to make it > local to a CS. > > But a further issue was raised on the thread. If I use the same RS > m-line to represent a medium from a number of CSs in series, > is this the > same MS or are they different MSs? If they are the same MS, > it means the > MS object does have a life outside a CS. But then I would > argue it only > needs an ID local to the RS. If the RS object is uniquely > identified by > the SIP dialog identifier, the MS object would be sufficiently > identified by the SDP m-line on that dialog. > > So I am afraid that before we can resolve the question of unique or > local MS identifiers, we first need to clarify what the MS > object is and > what its lifetime is. > > John (as individual) > > > > -----Original Message----- > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf Of Muthu > ArulMozhi Perumal > > (mperumal) > > Sent: 11 May 2011 14:49 > > To: Ram Mohan R (rmohanr); Leon Portman; Paul Kyzivat (pkyzivat); > > Henry Lum > > Cc: siprec@ietf.org > > Subject: Re: [siprec] Does MS have life outside a > particular CS? (was > > RE:comments on draft-ram-siprec-metadata-04) > > > > If we consider MS as local to a Participant (as John was trying to > > argue) there seems to be no need for a unique ID for MS > since it can > > be inferred from the Participant that can be uniquely identified. > > > > The mail thread describes a use-case where multicast MoH > played to a > > number of participants and to the SRC is recorded. Can't the MoH > > source be considered a Participant here? > > > > Muthu > > > > |-----Original Message----- > > |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Ram Mohan R (rmohanr) > > |Sent: Wednesday, May 11, 2011 12:52 PM > > |To: Leon Portman; Paul Kyzivat (pkyzivat); Henry Lum > > |Cc: siprec@ietf.org > > |Subject: Re: [siprec] Does MS have life outside a > particular CS? (was > > RE:comments on draft-ram-siprec- > > |metadata-04) > > | > > |Hello All, > > | > > |As per the discussions in last meeting and below mail thread > > it appears > > |that we would need global ID to take care of all the > cases. However > > |there is a disagreement with some folks in having a unique > > ID. I would > > |request people to respond on this mail thread and take > this issue to > > |closure. > > | > > |If no one has issues, we will go with globally Unique ID for > > MS block. > > | > > |Regards, > > |Ram > > | > > |> -----Original Message----- > > |> From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On > > |> Behalf Of Leon Portman > > |> Sent: Thursday, April 28, 2011 9:28 PM > > |> To: Paul Kyzivat (pkyzivat); Henry Lum > > |> Cc: siprec@ietf.org > > |> Subject: Re: [siprec] Does MS have life outside a > > particular CS? (was > > |> RE: comments on draft-ram-siprec-metadata-04) > > |> > > |> 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: comments 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 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=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 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 > > _______________________________________________ > > siprec mailing 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 May 19 10:01:18 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94A65E0706 for ; Thu, 19 May 2011 10:01:18 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2PbXcSo+mSpH for ; Thu, 19 May 2011 10:01:15 -0700 (PDT) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id 89767E081A for ; Thu, 19 May 2011 10:01:13 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.15]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Thu, 19 May 2011 20:01:11 +0300 From: Leon Portman To: "Elwell, John" , "Parthasarathi R (partr)" , "Muthu Arul Mozhi Perumal (mperumal)" , "Ram Mohan R (rmohanr)" , "Paul Kyzivat (pkyzivat)" , Henry Lum Date: Thu, 19 May 2011 20:01:09 +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/JiXPmDAAAgTPwAnuoqVAADSe5cAAkXwaAAUQXHCAAAoVIAAAuh9Yw Message-ID: <07465C1D981ABC41A344374066AE1A2C38AC1D3CFC@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><07465C1D981ABC41A344374066A E1A2C38 AB7A20DB@TL VMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD06480E2F@XMB-BGL-417.cisco.com><1D062974A4845E4D8A343C653804920205709791@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] 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, 19 May 2011 17:01:18 -0000 I agree with John. From my point of view MS represent CS media, And it can = be mapped to zero or more RS m-line via metadata labels. Leon -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] Sent: Wednesday, May 18, 2011 9:55 PM To: Parthasarathi R (partr); Muthu Arul Mozhi Perumal (mperumal); Ram Mohan= R (rmohanr); Leon Portman; Paul Kyzivat (pkyzivat); Henry Lum Cc: siprec@ietf.org Subject: RE: [siprec] Does MS have life outside a particular CS?(was RE:com= ments on draft-ram-siprec-metadata-04) > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > Sent: 18 May 2011 18:49 > To: Elwell, John; Muthu Arul Mozhi Perumal (mperumal); Ram Mohan R > (rmohanr); Leon Portman; Paul Kyzivat (pkyzivat); Henry Lum > Cc: siprec@ietf.org > Subject: RE: [siprec] Does MS have life outside a particular CS?(was > RE:comments on draft-ram-siprec-metadata-04) > > John, > > Your below mail is a good summary for the decision happened so far. MS > lifetime depends upon the relation between RS & CS in a given > deployment. My understanding w.r.t RS & CS relationship for MS > lifetime is as follows: > > One RS - One CS: MS lifetime is within the scope of single RS or > single CS > > One RS - Many CS: MS lifetime is within the scope of single RS > > Many RS - One CS: MS lifetime is within the scope of single CS [JRE] I don't follow your reasoning with the above two bullets. I think thi= s gives MS an inconsistent meaning, in that an MS sometimes maps to one RS = and multiple CS, and in other situations an MS maps to one CS and multiple = RSs. I would have great difficulty understanding what a MS really is. Up to= now we have discussed a MS having a lifetime only in the context of a CS a= nd at other times we have discussed a MS having a lifetime only in the cont= ext of an RS (in this case a 1:1 mapping to an m-line in the SDP). > > Many RS - Many CS: MS lifetime is within the scope of Multiple RS or > Multiple CS. [JRE] In this case, what is the defining character of an MS, making it the = same MS even though it spans many CSs and many RSs? I can't really grasp th= e concept. John (as individual) > > As Many RS- Many CS mechanism is adopted, there is a need for global > unique id for MS. > > Thanks > Partha > > > -----Original Message----- > From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > Sent: Thursday, May 12, 2011 12:58 PM > To: Muthu ArulMozhi Perumal (mperumal); Ram Mohan R (rmohanr); Leon > Portman; Paul Kyzivat (pkyzivat); Henry Lum > Cc: siprec@ietf.org > Subject: Re: [siprec] Does MS have life outside a particular CS?(was > RE:comments on draft-ram-siprec-metadata-04) > > I don't recall arguing that MS should be local to a Participant. In > http://www.ietf.org/mail-archive/web/siprec/current/msg01888.html > I argued MS should be local to a CS. My reasoning is as follows. > > Consider a conference call that has 3 media streams - audio, main > video and presentation video. Those streams will remain in existence > throughout the call, but participants will come and go. For example, > the conference could start with participants A, B and C. Then D and E > could join, then A could leave, and so on, so you could even end up > with just D, E and F in the call at the end, but they could still be > using those three media streams - audio, main video and presentation > video. So there is no single Participant that a media stream can be > anchored to for the entire call - the stream instead has to be > anchored to the CS. Also, the presentation stream can have a number of > different Participants transmitting to it, but only one at a time, > governed by floor control. > > So I had argued that an MS should be local to a Participant. At that > time, I had assumed an MS was modelling a media stream on the CS, but > the thread then went in the direction of pointing out that really it > models a media stream on the RS. For example, the audio stream in the > above example might be sent mixed (contributions from all > participants) > using a single m-line in the RS, or might be sent unmixed using > multiple m-lines in the RS. Some people were arguing that in the first > case this would be modelled as one MS and in the second case it would > be modelled as multiple MSs. I am not sure we really resolved that > (personally I was more comfortable with modelling an MS as relating to > a CS media stream. > > Anyway, however MS is modelled, it doesn't seem feasible to make it > local to a Participant, but it may be feasible to make it local to a > CS. > > But a further issue was raised on the thread. If I use the same RS > m-line to represent a medium from a number of CSs in series, is this > the same MS or are they different MSs? If they are the same MS, it > means the MS object does have a life outside a CS. But then I would > argue it only needs an ID local to the RS. If the RS object is > uniquely identified by the SIP dialog identifier, the MS object would > be sufficiently identified by the SDP m-line on that dialog. > > So I am afraid that before we can resolve the question of unique or > local MS identifiers, we first need to clarify what the MS object is > and what its lifetime is. > > John (as individual) > > > > -----Original Message----- > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf Of Muthu > ArulMozhi Perumal > > (mperumal) > > Sent: 11 May 2011 14:49 > > To: Ram Mohan R (rmohanr); Leon Portman; Paul Kyzivat (pkyzivat); > > Henry Lum > > Cc: siprec@ietf.org > > Subject: Re: [siprec] Does MS have life outside a > particular CS? (was > > RE:comments on draft-ram-siprec-metadata-04) > > > > If we consider MS as local to a Participant (as John was trying to > > argue) there seems to be no need for a unique ID for MS > since it can > > be inferred from the Participant that can be uniquely identified. > > > > The mail thread describes a use-case where multicast MoH > played to a > > number of participants and to the SRC is recorded. Can't the MoH > > source be considered a Participant here? > > > > Muthu > > > > |-----Original Message----- > > |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Ram Mohan R (rmohanr) > > |Sent: Wednesday, May 11, 2011 12:52 PM > > |To: Leon Portman; Paul Kyzivat (pkyzivat); Henry Lum > > |Cc: siprec@ietf.org > > |Subject: Re: [siprec] Does MS have life outside a > particular CS? (was > > RE:comments on draft-ram-siprec- > > |metadata-04) > > | > > |Hello All, > > | > > |As per the discussions in last meeting and below mail thread > > it appears > > |that we would need global ID to take care of all the > cases. However > > |there is a disagreement with some folks in having a unique > > ID. I would > > |request people to respond on this mail thread and take > this issue to > > |closure. > > | > > |If no one has issues, we will go with globally Unique ID for > > MS block. > > | > > |Regards, > > |Ram > > | > > |> -----Original Message----- > > |> From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On > > |> Behalf Of Leon Portman > > |> Sent: Thursday, April 28, 2011 9:28 PM > > |> To: Paul Kyzivat (pkyzivat); Henry Lum > > |> Cc: siprec@ietf.org > > |> Subject: Re: [siprec] Does MS have life outside a > > particular CS? (was > > |> RE: comments on draft-ram-siprec-metadata-04) > > |> > > |> 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: comments 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 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=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 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 > > _______________________________________________ > > siprec mailing 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 May 19 11:39:37 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD81E0742 for ; Thu, 19 May 2011 11:39:37 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uVwHvIr-j9ih for ; Thu, 19 May 2011 11:39:34 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 7F3AFE069C for ; Thu, 19 May 2011 11:39:34 -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 p4JIdVSv017043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 May 2011 13:39:32 -0500 (CDT) Received: from relay-out1.dc.genesyslab.com (relay-out1.dc.genesyslab.com [172.22.68.187]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p4JIdTXZ018649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 19 May 2011 13:39:31 -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 p4JIdSnC003833; Thu, 19 May 2011 11:39:28 -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, 19 May 2011 11:39:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 19 May 2011 11:39:25 -0700 Message-ID: <059AF07365DC474393A19A3AF187DF740716E063@NAHALD.us.int.genesyslab.com> In-Reply-To: <07465C1D981ABC41A344374066AE1A2C38AC1D3CFC@TLVMBX01.nice.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Does MS have life outside a particular CS?(wasRE:comments on draft-ram-siprec-metadata-04) Thread-Index: AcwFuuvxdSy9/XTRSVq5DE/JiXPmDAAAgTPwAnuoqVAADSe5cAAkXwaAAUQXHCAAAoVIAAAuh9YwAAJ9VWA= 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><07465C1D981ABC41A344374066! A E1A2C38 AB7A20DB@T L VMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD06480E2F@XMB-BGL-417.cisco.com><1D062974A4845E4D8A343C653804920205709791@XMB-BGL-414.cisco.com> <07465C1D981ABC41A344374066AE1A2C38AC1D3CFC@TLVMBX01.nice.com> From: "Henry Lum" To: "Leon Portman" , "Elwell, John" , "Parthasarathi R (partr)" , "Muthu Arul Mozhi Perumal (mperumal)" , "Ram Mohan R (rmohanr)" , "Paul Kyzivat (pkyzivat)" X-OriginalArrivalTime: 19 May 2011 18:39:28.0936 (UTC) FILETIME=[16048280:01CC1654] 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] Does MS have life outside a particular CS?(wasRE: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, 19 May 2011 18:39:37 -0000 I agree with John that a recording session transports recorded streams and are already described in the SIP session so there is no need to model recorded streams in the metadata model. MS in the metadata model, on the other hand, explains a media stream that is part a CS, and the recorded streams in the RS just refer to which MS in the model is actually being recorded. When we record unmixed streams as a single m-line in the RS, I think we should model as multiple MS in the metadata model but all the MS would refer to the same label in the recorded stream.=20 When we relate a MS directly to a CS, I think it implicitly means that a CS owns some sort of media sources that generates media. In other words, CS owns some automated participants as media sources but we don't explicitly model them. I am okay with this definition since the SRC can choose to model this either way - meaning if there is need to show what the CS is doing to the media sources then the SRC can model a participant that generates the media to explain what it is. These implicit participants should terminate whenever the MS terminates or the CS terminates. Henry > -----Original Message----- > From: Leon Portman [mailto:Leon.Portman@nice.com] > Sent: Thursday, May 19, 2011 1:01 PM > To: Elwell, John; Parthasarathi R (partr); Muthu Arul Mozhi Perumal > (mperumal); Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat); Henry Lum > Cc: siprec@ietf.org > Subject: RE: [siprec] Does MS have life outside a particular > CS?(wasRE:comments on draft-ram-siprec-metadata-04) >=20 > I agree with John. From my point of view MS represent CS media, And it > can be mapped to zero or more RS m-line via metadata labels. >=20 > Leon >=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Wednesday, May 18, 2011 9:55 PM > To: Parthasarathi R (partr); Muthu Arul Mozhi Perumal (mperumal); Ram > Mohan R (rmohanr); Leon Portman; Paul Kyzivat (pkyzivat); Henry Lum > 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 >=20 >=20 > > -----Original Message----- > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > Sent: 18 May 2011 18:49 > > To: Elwell, John; Muthu Arul Mozhi Perumal (mperumal); Ram Mohan R > > (rmohanr); Leon Portman; Paul Kyzivat (pkyzivat); Henry Lum > > Cc: siprec@ietf.org > > Subject: RE: [siprec] Does MS have life outside a particular CS?(was > > RE:comments on draft-ram-siprec-metadata-04) > > > > John, > > > > Your below mail is a good summary for the decision happened so far. > MS > > lifetime depends upon the relation between RS & CS in a given > > deployment. My understanding w.r.t RS & CS relationship for MS > > lifetime is as follows: > > > > One RS - One CS: MS lifetime is within the scope of single RS or > > single CS > > > > One RS - Many CS: MS lifetime is within the scope of single RS > > > > Many RS - One CS: MS lifetime is within the scope of single CS > [JRE] I don't follow your reasoning with the above two bullets. I think > this gives MS an inconsistent meaning, in that an MS sometimes maps to > one RS and multiple CS, and in other situations an MS maps to one CS > and multiple RSs. I would have great difficulty understanding what a MS > really is. Up to now we have discussed a MS having a lifetime only in > the context of a CS and at other times we have discussed a MS having a > lifetime only in the context of an RS (in this case a 1:1 mapping to an > m-line in the SDP). >=20 > > > > Many RS - Many CS: MS lifetime is within the scope of Multiple RS or > > Multiple CS. > [JRE] In this case, what is the defining character of an MS, making it > the same MS even though it spans many CSs and many RSs? I can't really > grasp the concept. >=20 > John (as individual) >=20 >=20 > > > > As Many RS- Many CS mechanism is adopted, there is a need for global > > unique id for MS. > > > > Thanks > > Partha > > > > > > -----Original Message----- > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > > Sent: Thursday, May 12, 2011 12:58 PM > > To: Muthu ArulMozhi Perumal (mperumal); Ram Mohan R (rmohanr); Leon > > Portman; Paul Kyzivat (pkyzivat); Henry Lum > > Cc: siprec@ietf.org > > Subject: Re: [siprec] Does MS have life outside a particular CS?(was > > RE:comments on draft-ram-siprec-metadata-04) > > > > I don't recall arguing that MS should be local to a Participant. In > > http://www.ietf.org/mail-archive/web/siprec/current/msg01888.html > > I argued MS should be local to a CS. My reasoning is as follows. > > > > Consider a conference call that has 3 media streams - audio, main > > video and presentation video. Those streams will remain in existence > > throughout the call, but participants will come and go. For example, > > the conference could start with participants A, B and C. Then D and E > > could join, then A could leave, and so on, so you could even end up > > with just D, E and F in the call at the end, but they could still be > > using those three media streams - audio, main video and presentation > > video. So there is no single Participant that a media stream can be > > anchored to for the entire call - the stream instead has to be > > anchored to the CS. Also, the presentation stream can have a number > of > > different Participants transmitting to it, but only one at a time, > > governed by floor control. > > > > So I had argued that an MS should be local to a Participant. At that > > time, I had assumed an MS was modelling a media stream on the CS, but > > the thread then went in the direction of pointing out that really it > > models a media stream on the RS. For example, the audio stream in the > > above example might be sent mixed (contributions from all > > participants) > > using a single m-line in the RS, or might be sent unmixed using > > multiple m-lines in the RS. Some people were arguing that in the > first > > case this would be modelled as one MS and in the second case it would > > be modelled as multiple MSs. I am not sure we really resolved that > > (personally I was more comfortable with modelling an MS as relating > to > > a CS media stream. > > > > Anyway, however MS is modelled, it doesn't seem feasible to make it > > local to a Participant, but it may be feasible to make it local to a > > CS. > > > > But a further issue was raised on the thread. If I use the same RS > > m-line to represent a medium from a number of CSs in series, is this > > the same MS or are they different MSs? If they are the same MS, it > > means the MS object does have a life outside a CS. But then I would > > argue it only needs an ID local to the RS. If the RS object is > > uniquely identified by the SIP dialog identifier, the MS object would > > be sufficiently identified by the SDP m-line on that dialog. > > > > So I am afraid that before we can resolve the question of unique or > > local MS identifiers, we first need to clarify what the MS object is > > and what its lifetime is. > > > > John (as individual) > > > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Muthu > > ArulMozhi Perumal > > > (mperumal) > > > Sent: 11 May 2011 14:49 > > > To: Ram Mohan R (rmohanr); Leon Portman; Paul Kyzivat (pkyzivat); > > > Henry Lum > > > Cc: siprec@ietf.org > > > Subject: Re: [siprec] Does MS have life outside a > > particular CS? (was > > > RE:comments on draft-ram-siprec-metadata-04) > > > > > > If we consider MS as local to a Participant (as John was trying to > > > argue) there seems to be no need for a unique ID for MS > > since it can > > > be inferred from the Participant that can be uniquely identified. > > > > > > The mail thread describes a use-case where multicast MoH > > played to a > > > number of participants and to the SRC is recorded. Can't the MoH > > > source be considered a Participant here? > > > > > > Muthu > > > > > > |-----Original Message----- > > > |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > > Behalf Of Ram Mohan R (rmohanr) > > > |Sent: Wednesday, May 11, 2011 12:52 PM > > > |To: Leon Portman; Paul Kyzivat (pkyzivat); Henry Lum > > > |Cc: siprec@ietf.org > > > |Subject: Re: [siprec] Does MS have life outside a > > particular CS? (was > > > RE:comments on draft-ram-siprec- > > > |metadata-04) > > > | > > > |Hello All, > > > | > > > |As per the discussions in last meeting and below mail thread > > > it appears > > > |that we would need global ID to take care of all the > > cases. However > > > |there is a disagreement with some folks in having a unique > > > ID. I would > > > |request people to respond on this mail thread and take > > this issue to > > > |closure. > > > | > > > |If no one has issues, we will go with globally Unique ID for > > > MS block. > > > | > > > |Regards, > > > |Ram > > > | > > > |> -----Original Message----- > > > |> From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On > > > |> Behalf Of Leon Portman > > > |> Sent: Thursday, April 28, 2011 9:28 PM > > > |> To: Paul Kyzivat (pkyzivat); Henry Lum > > > |> Cc: siprec@ietf.org > > > |> Subject: Re: [siprec] Does MS have life outside a > > > particular CS? (was > > > |> RE: comments on draft-ram-siprec-metadata-04) > > > |> > > > |> 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: comments 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 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=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 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 > > > _______________________________________________ > > > siprec mailing 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 May 20 00:10:48 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 3CF40E06D4 for ; Fri, 20 May 2011 00:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.524 X-Spam-Level: X-Spam-Status: No, score=-106.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 Zormqh8QLQ8V for ; Fri, 20 May 2011 00:10:47 -0700 (PDT) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfa.amsl.com (Postfix) with SMTP id CFAB8E0686 for ; Fri, 20 May 2011 00:10:46 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1305875441!34683499!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 20429 invoked from network); 20 May 2011 07:10:41 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-15.tower-27.messagelabs.com with SMTP; 20 May 2011 07:10:41 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 8827023F03E6; Fri, 20 May 2011 09:10:45 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 20 May 2011 09:10:45 +0200 From: "Elwell, John" To: Henry Lum , Leon Portman , "Parthasarathi R (partr)" , "Muthu Arul Mozhi Perumal (mperumal)" , "Ram Mohan R (rmohanr)" , "Paul Kyzivat (pkyzivat)" Date: Fri, 20 May 2011 09:10:44 +0200 Thread-Topic: [siprec] Does MS have life outside a particular CS?(wasRE:comments on draft-ram-siprec-metadata-04) Thread-Index: AcwFuuvxdSy9/XTRSVq5DE/JiXPmDAAAgTPwAnuoqVAADSe5cAAkXwaAAUQXHCAAAoVIAAAuh9YwAAJ9VWAAGP/KIA== Message-ID: 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><07465C1D981ABC41A344374066! A E1A2C38 AB7A20DB@T L VMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD06480E2F@XMB-BGL-417.cisco.com><1D062974A4845E4D8A343C653804920205709791@XMB-BGL-414.cisco.com> <07465C1D981ABC41A344374066AE1A2C38AC1D3CFC@TLVMBX01.nice.com> <059AF07365DC474393A19A3AF187DF740716E063@NAHALD.us.int.genesyslab.com> In-Reply-To: <059AF07365DC474393A19A3AF187DF740716E063@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: 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?(wasRE: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: Fri, 20 May 2011 07:10:48 -0000 =20 > -----Original Message----- > From: Henry Lum [mailto:Henry.Lum@alcatel-lucent.com]=20 > Sent: 19 May 2011 19:39 > To: Leon Portman; Elwell, John; Parthasarathi R (partr);=20 > Muthu Arul Mozhi Perumal (mperumal); Ram Mohan R (rmohanr);=20 > Paul Kyzivat (pkyzivat) > Cc: siprec@ietf.org > Subject: RE: [siprec] Does MS have life outside a particular=20 > CS?(wasRE:comments on draft-ram-siprec-metadata-04) >=20 > I agree with John that a recording session transports recorded streams > and are already described in the SIP session so there is no need to > model recorded streams in the metadata model. MS in the=20 > metadata model, > on the other hand, explains a media stream that is part a CS, and the > recorded streams in the RS just refer to which MS in the model is > actually being recorded. When we record unmixed streams as a single > m-line in the RS, I think we should model as multiple MS in=20 > the metadata > model but all the MS would refer to the same label in the recorded > stream.=20 [JRE] Not sure. That might be one way of doing it. So an MS would represent= contribution to a medium (e.g., audio, main video) from a single Participa= nt. So for a simple 2-party audio-only call there would be two MS objects, = one for Participant 1 and one for Participant 2. This might work, I had not= thought of it that way. Certainly it doesn't align with the current metada= ta model, but of course that can be changed. One problem that would need to= be addressed - how to tie together different MS objects that all relate to= the same medium (e.g., audio, main video, presentation video). Perhaps the= y would all share the same "content" attribute. Another way of looking at it is that an MS models a single medium in the CS= , e.g., audio, main video, presentation video. The linkage between an MS ob= ject and a Participant object would then point to an m-line in the SDP. To = give some examples: 1. The SRC sees only mixed streams and doesn't distinguish the participants= . In other words, everything is hidden behind a focus/mixer - it just sees = the conference as a single Participant. In this case it would be modelled a= s a single MS with a single Participant. The linkage between the sole Parti= cipant and the MS would point to the m-line. 2. The SRC sees mixed streams but can identify different contributing parti= cipants. In this case it would be modelled as a single MS with multiple Par= ticipants. Each linkage between a Participant and the MS would point to the= same m-line. 3. The SRC sees unmixed streams from different contributing participants, b= ut mixes them itself to send to the SRS as a single mixed stream. Modelling= is similar to case 2. 4. The SRC sees unmixed streams from different contributing participants an= d sends them unmixed as different RTP sessions to the SRS. In this case it = would be modelled as a single MS with multiple Participants. Each linkage b= etween a Participant and the MS would point to a different m-line. 5. The SRC sees unmixed streams from different contributing participants an= d sends them unmixed using different SSRC values in a single RTP session to= the SRS. In this case it would be modelled as a single MS with multiple Pa= rticipants. Each linkage between a Participant and the MS would point to th= e same m-line. There would also need to be a mechanism for tying a linkage = to a particular SSRC value. >=20 > When we relate a MS directly to a CS, I think it implicitly=20 > means that a > CS owns some sort of media sources that generates media. In=20 > other words, > CS owns some automated participants as media sources but we don't > explicitly model them. I am okay with this definition since=20 > the SRC can > choose to model this either way - meaning if there is need to=20 > show what > the CS is doing to the media sources then the SRC can model a > participant that generates the media to explain what it is. These > implicit participants should terminate whenever the MS=20 > terminates or the > CS terminates. [JRE] Sounds reasonable. John >=20 > Henry >=20 From john.elwell@siemens-enterprise.com Fri May 20 00:11:02 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81AADE06E6 for ; Fri, 20 May 2011 00:11:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.528 X-Spam-Level: X-Spam-Status: No, score=-106.528 tagged_above=-999 required=5 tests=[AWL=0.071, 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 LR3GfATT6kSj for ; Fri, 20 May 2011 00:11:00 -0700 (PDT) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfa.amsl.com (Postfix) with SMTP id 858D1E0686 for ; Fri, 20 May 2011 00:10:59 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1305875450!34554464!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 21025 invoked from network); 20 May 2011 07:10:50 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-7.tower-27.messagelabs.com with SMTP; 20 May 2011 07:10:50 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 8944123F03E8 for ; Fri, 20 May 2011 09:10:58 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 20 May 2011 09:10:58 +0200 From: "Elwell, John" To: "siprec@ietf.org" Date: Fri, 20 May 2011 09:10:57 +0200 Thread-Topic: Modelling current speaker video. Thread-Index: AcwWvRDi3OHocljLR1WwjWOdaj5Yaw== 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] Modelling current speaker video. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 20 May 2011 07:11:02 -0000 This may already be covered, but how do we envisage modelling the following= ? There are n participants, all participating in 3 media: audio, main video= and current speaker video. Audio and main video are mixed/combined by the = mixer. But with current speaker video, the mixer switches between different= sources, according to voice activity detection. At any one time, only one = Participant is contributing to that MS, but switching is dynamic, much fast= er than we would envisage doing metadata updates. I guess the simple soluti= on would be to model it as all Participants are contributing to that MS, ev= en though at any instant there will be only one contributor. John (as individual) From pkyzivat@cisco.com Fri May 20 05:39:05 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 30F8FE07A1 for ; Fri, 20 May 2011 05:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.224 X-Spam-Level: X-Spam-Status: No, score=-110.224 tagged_above=-999 required=5 tests=[AWL=0.375, 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 8a9IIoq1CRbJ for ; Fri, 20 May 2011 05:39:04 -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 629BBE07A0 for ; Fri, 20 May 2011 05:39:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=873; q=dns/txt; s=iport; t=1305895144; x=1307104744; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=w0tD4ZgfnMJAlUuzeNpJ+4QSveCt0ZUDjBZui7qbi6c=; b=ZXlZFsugBJ2mYSdCm0ocxXUbFf/u1Ogbe4+C/eu1hikhy/qhA7x1hdJ3 3C87m1PJ1lt2JF+FWRE7YXkdwsBrJF+PIvN/V7FtHG33BU1u05TQUAVsq rsoILXcifm/E/sRZR/fULT5xhF7B0frrLSCS6rFXyQHS2II/YMvZzbIXm o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au4GAMlf1k2rRDoJ/2dsb2JhbACYHo1+d6YGnguGGQSQEYQvimI X-IronPort-AV: E=Sophos;i="4.65,242,1304294400"; d="scan'208";a="361062928" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-2.cisco.com with ESMTP; 20 May 2011 12:39:04 +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 p4KCd3Zu009164 for ; Fri, 20 May 2011 12:39:03 GMT Message-ID: <4DD660E7.5080808@cisco.com> Date: Fri, 20 May 2011 08:39:03 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 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] Modelling current speaker video. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 20 May 2011 12:39:05 -0000 On 5/20/2011 3:10 AM, Elwell, John wrote: > This may already be covered, but how do we envisage modelling the following? There are n participants, all participating in 3 media: audio, main video and current speaker video. Audio and main video are mixed/combined by the mixer. But with current speaker video, the mixer switches between different sources, according to voice activity detection. At any one time, only one Participant is contributing to that MS, but switching is dynamic, much faster than we would envisage doing metadata updates. I guess the simple solution would be to model it as all Participants are contributing to that MS, even though at any instant there will be only one contributor. I think I agree. *If* the SRC can signal the participant changes then it is free to do so, If not, doing as you say seems appropriate. Thanks, Paul From john.elwell@siemens-enterprise.com Fri May 20 08:50: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 4517BE0769 for ; Fri, 20 May 2011 08:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.849 X-Spam-Level: X-Spam-Status: No, score=-105.849 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_110=0.6, J_CHICKENPOX_16=0.6, 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 2mT+n77fxuYf for ; Fri, 20 May 2011 08:50:40 -0700 (PDT) Received: from mail182.messagelabs.com (mail182.messagelabs.com [85.158.139.83]) by ietfa.amsl.com (Postfix) with SMTP id 3DB7BE0739 for ; Fri, 20 May 2011 08:50:39 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-13.tower-182.messagelabs.com!1305906638!7371059!1 X-StarScan-Version: 6.2.16; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 21102 invoked from network); 20 May 2011 15:50:38 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-13.tower-182.messagelabs.com with SMTP; 20 May 2011 15:50:38 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id F036323F03E6 for ; Fri, 20 May 2011 17:50:37 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 20 May 2011 17:50:38 +0200 From: "Elwell, John" To: "siprec@ietf.org" Date: Fri, 20 May 2011 17:50:36 +0200 Thread-Topic: Comments on extensions for recordiing-aware UAs Thread-Index: AcwXBajeHOKb6yBvTzyswT3jMMHhyA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] Comments on extensions for recordiing-aware UAs X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 20 May 2011 15:50:41 -0000 1. In section 6.2 of draft-portman-siprec-protocol-04, there is a record-aw= are option tag. It states: "When a user agent inserts a Supported header field with the option tag record-aware, the UAS may provide recording indications through the media level SDP. The UAS may also at the same time provide recording indications through traditional means such as playing a tone inband." This seems to imply that the use of "traditional means" might not be necess= ary if the UA sends this option tag in Supported. The problem is, the a=3Dr= ecord attribute in 6.1 only conveys the fat that a medium is being recorded= and might not convey the full semantics that an announcement might convey.= Therefore it might be dangerous to skip the "traditional means". Perhaps w= e need some different or additional wording, and perhaps something in the S= ecurity Considerations section. 2. In section 6.3, for a=3Drecordpref, I think we need an additional value = "nopreference", which should also be the default value. John (as individual)= From wwwrun@ietfa.amsl.com Fri May 20 10:12:48 2011 Return-Path: X-Original-To: siprec@ietf.org Delivered-To: siprec@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id 859D1E067F; Fri, 20 May 2011 10:12:48 -0700 (PDT) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110520171248.859D1E067F@ietfa.amsl.com> Date: Fri, 20 May 2011 10:12:48 -0700 (PDT) Cc: siprec@ietf.org Subject: [siprec] SIPREC WG Virtual Interim Meeting June 23, 2011 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2011 17:12:48 -0000 The SIPREC WG will hold an interim virtual meetings on: 2011-06-23, 13.00-15.00 GMT Agenda and details will be announced on the SIPREC mailing list in due course. From eckelcu@cisco.com Sun May 22 09:07:38 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC7CE0684 for ; Sun, 22 May 2011 09:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.549 X-Spam-Level: X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 4xvda6IzCYBE for ; Sun, 22 May 2011 09:07:37 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3ADBFE0682 for ; Sun, 22 May 2011 09:07:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=5979; q=dns/txt; s=iport; t=1306080457; x=1307290057; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=buLCF/XfiqeORAtW54X6I0beTewzxcu/A3Ff6PvFsYw=; b=XmDoNm1sCSn8bZmgrP4oy5qSkewxm2DuSUXrVremlB6X6FTYbda7maaq xo5KmnW1tsy4+YzJ9NO70blpNH3ekM0Y0kMphoOfUvQ+i/vw+I/qPzhbt mXUPUcjcF5Z52hnU7lYzhYx38bO5YAuCdcwfEmD7rD+S4GrMPFZDfmkai g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjABAM8z2U2rRDoH/2dsb2JhbACXZI47eIhwnW2cRYMUgwUEhlCNeYpd X-IronPort-AV: E=Sophos;i="4.65,252,1304294400"; d="scan'208";a="321096087" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-3.cisco.com with ESMTP; 22 May 2011 16:07:36 +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 p4MG7aAM029481; Sun, 22 May 2011 16:07:36 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); Sun, 22 May 2011 09:07:36 -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, 22 May 2011 09:07:36 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Does MS have life outside a particular CS?(wasRE:comments on draft-ram-siprec-metadata-04) Thread-Index: AcwFuuvxdSy9/XTRSVq5DE/JiXPmDAAAgTPwAnuoqVAADSe5cAAkXwaAAUQXHCAAAoVIAAAuh9YwAAJ9VWAAGP/KIABZ8/ZQ 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><07465C1D981ABC41A344374066! A E1A2C3 8 AB7A20DB @T LVMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD06480E2F@XMB-BGL-417.cisco.com><1D062974A4845E4D8A343C653804920205709791@XMB-BGL-414.cisco.com><07465C1D981ABC41A344374066AE1A2C38AC1D3CFC@TLVMBX01.nice.com><059AF07365DC474393A19A3AF187DF740716E063@NAHALD.us.int.genesyslab.com> From: "Charles Eckel (eckelcu)" To: "Elwell, John" , "Henry Lum" , "Leon Portman" , "Parthasarathi R (partr)" , "Muthu Arul Mozhi Perumal (mperumal)" , "Ram Mohan R (rmohanr)" , "Paul Kyzivat (pkyzivat)" X-OriginalArrivalTime: 22 May 2011 16:07:36.0930 (UTC) FILETIME=[5E13FC20:01CC189A] Cc: siprec@ietf.org Subject: Re: [siprec] Does MS have life outside a particular CS?(wasRE: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: Sun, 22 May 2011 16:07:38 -0000 Hi John, I viewed this a bit differently. Please see inline. > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > Sent: Friday, May 20, 2011 12:11 AM > To: Henry Lum; Leon Portman; Parthasarathi R (partr); Muthu Arul Mozhi Perumal (mperumal); Ram Mohan R > (rmohanr); Paul Kyzivat (pkyzivat) > Cc: siprec@ietf.org > Subject: Re: [siprec] Does MS have life outside a particular CS?(wasRE:comments on draft-ram-siprec- > metadata-04) >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Henry Lum [mailto:Henry.Lum@alcatel-lucent.com] > > Sent: 19 May 2011 19:39 > > To: Leon Portman; Elwell, John; Parthasarathi R (partr); > > Muthu Arul Mozhi Perumal (mperumal); Ram Mohan R (rmohanr); > > Paul Kyzivat (pkyzivat) > > Cc: siprec@ietf.org > > Subject: RE: [siprec] Does MS have life outside a particular > > CS?(wasRE:comments on draft-ram-siprec-metadata-04) > > > > I agree with John that a recording session transports recorded streams > > and are already described in the SIP session so there is no need to > > model recorded streams in the metadata model. MS in the > > metadata model, > > on the other hand, explains a media stream that is part a CS, and the > > recorded streams in the RS just refer to which MS in the model is > > actually being recorded. When we record unmixed streams as a single > > m-line in the RS, I think we should model as multiple MS in > > the metadata > > model but all the MS would refer to the same label in the recorded > > stream. > [JRE] Not sure. That might be one way of doing it. So an MS would represent contribution to a medium > (e.g., audio, main video) from a single Participant. So for a simple 2-party audio-only call there > would be two MS objects, one for Participant 1 and one for Participant 2. This might work, I had not > thought of it that way. This is consistent with my thinking on the matter. Certainly it doesn't align with the current metadata model, but of course that > can be changed. One problem that would need to be addressed - how to tie together different MS objects > that all relate to the same medium (e.g., audio, main video, presentation video). Perhaps they would > all share the same "content" attribute. >=20 > Another way of looking at it is that an MS models a single medium in the CS, e.g., audio, main video, > presentation video. The linkage between an MS object and a Participant object would then point to an > m-line in the SDP. To give some examples: >=20 > 1. The SRC sees only mixed streams and doesn't distinguish the participants. In other words, > everything is hidden behind a focus/mixer - it just sees the conference as a single Participant. In > this case it would be modelled as a single MS with a single Participant. The linkage between the sole > Participant and the MS would point to the m-line. Sounds good. > 2. The SRC sees mixed streams but can identify different contributing participants. In this case it > would be modelled as a single MS with multiple Participants. Each linkage between a Participant and > the MS would point to the same m-line. SRC could send mixed stream to SRS, in which case there would be a single m-line in the RS. SSRC for RTP stream would probably be that of the SRC, and CSRC would indicate participants. Alternatively, the SRC could separate them out into multiple streams, either represented as a single RS m-line with different SSRC for each participant, or a different m-line for each participant. =20 > 3. The SRC sees unmixed streams from different contributing participants, but mixes them itself to > send to the SRS as a single mixed stream. Modelling is similar to case 2. SRC could send mixed stream to SRS, in which case there would be a single m-line in the RS. SSRC for RTP stream would probably be that of the SRC, and CSRC would indicate participants. > 4. The SRC sees unmixed streams from different contributing participants and sends them unmixed as > different RTP sessions to the SRS. In this case it would be modelled as a single MS with multiple > Participants. Each linkage between a Participant and the MS would point to a different m-line.=20 =20 I was expecting this to be modeled as multiple different MS. The SRC would send them as multiple streams, either represented as a single RS m-line with different SSRC for each participant, or a different m-line for each participant. > 5. The SRC sees unmixed streams from different contributing participants and sends them unmixed using > different SSRC values in a single RTP session to the SRS. In this case it would be modelled as a > single MS with multiple Participants. Each linkage between a Participant and the MS would point to the > same m-line. There would also need to be a mechanism for tying a linkage to a particular SSRC value. That would be the most lightweight and efficient way, but the SRC could alter it and represent it differently to the RS, if desired. Cheers, Charles >=20 > > > > When we relate a MS directly to a CS, I think it implicitly > > means that a > > CS owns some sort of media sources that generates media. In > > other words, > > CS owns some automated participants as media sources but we don't > > explicitly model them. I am okay with this definition since > > the SRC can > > choose to model this either way - meaning if there is need to > > show what > > the CS is doing to the media sources then the SRC can model a > > participant that generates the media to explain what it is. These > > implicit participants should terminate whenever the MS > > terminates or the > > CS terminates. > [JRE] Sounds reasonable. >=20 > John >=20 > > > > Henry > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From eckelcu@cisco.com Sun May 22 09:07: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 6AAD9E0684 for ; Sun, 22 May 2011 09:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.556 X-Spam-Level: X-Spam-Status: No, score=-10.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 pUHxkk+lmOdS for ; Sun, 22 May 2011 09:07:44 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id A7420E0682 for ; Sun, 22 May 2011 09:07:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=1531; q=dns/txt; s=iport; t=1306080464; x=1307290064; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=H7ZFL8wbY13tnmz6ogDLNySrEtojauZJAjdHJi4S7mE=; b=JmQGHrV6OMEpSs/LELamGRGY/As1KpUUF6dY4dJPlvY+2vOkVXZEak7c JVniDyqJfeVAQL+YGcpqX9n+rZx/gomTHVCn9ecJxuBeujnAtcRC8siu6 nhI2Vy23lkfkRrF0d2tGecAstUQwugQ4L7Gh2H90QyM6bJqdVZlSoaEFN 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjABAM8z2U2rRDoG/2dsb2JhbACXZI47eIhwnW2cRYYZBIZQjXmKXQ X-IronPort-AV: E=Sophos;i="4.65,252,1304294400"; d="scan'208";a="321096125" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-3.cisco.com with ESMTP; 22 May 2011 16:07:44 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4MG7iTV014513 for ; Sun, 22 May 2011 16:07:44 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); Sun, 22 May 2011 09:07:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 22 May 2011 09:07:44 -0700 Message-ID: In-Reply-To: <4DD660E7.5080808@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Modelling current speaker video. Thread-Index: AcwW6uz04+QVPo+HSOG/f97RautU6wBMwh3g References: <4DD660E7.5080808@cisco.com> From: "Charles Eckel (eckelcu)" To: "Paul Kyzivat (pkyzivat)" , X-OriginalArrivalTime: 22 May 2011 16:07:44.0387 (UTC) FILETIME=[6285D530:01CC189A] Subject: Re: [siprec] Modelling current speaker video. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2011 16:07:45 -0000 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat (pkyzivat) > Sent: Friday, May 20, 2011 5:39 AM > To: siprec@ietf.org > Subject: Re: [siprec] Modelling current speaker video. >=20 >=20 >=20 > On 5/20/2011 3:10 AM, Elwell, John wrote: > > This may already be covered, but how do we envisage modelling the following? There are n > participants, all participating in 3 media: audio, main video and current speaker video. Audio and > main video are mixed/combined by the mixer. But with current speaker video, the mixer switches between > different sources, according to voice activity detection. At any one time, only one Participant is > contributing to that MS, but switching is dynamic, much faster than we would envisage doing metadata > updates. I guess the simple solution would be to model it as all Participants are contributing to that > MS, even though at any instant there will be only one contributor. >=20 > I think I agree. >=20 > *If* the SRC can signal the participant changes then it is free to do > so, If not, doing as you say seems appropriate. This is where I think SSRC or CSRC would be a good way to indicate the participant responsible for the stream. Either one may be appropriate depending on the exact scenario. Cheers, Charles >=20 > Thanks, > Paul > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From partr@cisco.com Sun May 22 15:34:36 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F4E2E06BD for ; Sun, 22 May 2011 15:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.547 X-Spam-Level: X-Spam-Status: No, score=-9.547 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, 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 YcrRQBcvA-Ee for ; Sun, 22 May 2011 15:34:33 -0700 (PDT) Received: from ams-iport-2.cisco.com (unknown [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id CA15EE0651 for ; Sun, 22 May 2011 15:34:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=44963; q=dns/txt; s=iport; t=1306103671; x=1307313271; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=QbY88XjGd9xgY2B42DVEPopZHP6VrPys4/PimwRltMI=; b=Y/KGHPIyd9WiqKOMIY9a+MFYN3f4+i6QinbGBHjQ21v9RR86QkETTCRe GFrJbQCGZBpns0cd5WIv4rJQHpSmLrbJE4ylPDnv4zyCjlhURdGMBTeUU Equ6yQWw+HTcZBoDIM/Z64WH/nA545LutaXWV3HjPzB209Pz9LQCHvhsY o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwBABqO2U1Io8US/2dsb2JhbACXZI47eIhwnWKcRoMNAQaDBQSGTo17ikU0 X-IronPort-AV: E=Sophos;i="4.65,253,1304294400"; d="scan'208";a="31647713" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-2.cisco.com with ESMTP; 22 May 2011 22:34:28 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p4MMYSk8029850; Sun, 22 May 2011 22:34:28 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, 23 May 2011 04:04: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: Mon, 23 May 2011 04:04:24 +0530 Message-ID: In-Reply-To: <059AF07365DC474393A19A3AF187DF740716E063@NAHALD.us.int.genesyslab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Does MS have life outside a particular CS?(wasRE:comments on draft-ram-siprec-metadata-04) Thread-Index: AcwFuuvxdSy9/XTRSVq5DE/JiXPmDAAAgTPwAnuoqVAADSe5cAAkXwaAAUQXHCAAAoVIAAAuh9YwAAJ9VWAAnluXAA== 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><07465C1D981ABC41A344374066! A E1A2C 38 AB7A20DB @TL VMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD06480E2F@XMB-BGL-417.cisco.com><1D062974A4845E4D8A343C653804920205709791@XMB-BGL-414.cisco.com> <07465C1D981ABC41A344374066AE1A2C38AC1D3CFC@TLVMBX01.nice.com> <059AF07365DC474393A19A3AF187DF740716E063@NAHALD.us.int.genesyslab.com> From: "Parthasarathi R (partr)" To: "Henry Lum" , "Leon Portman" , "Elwell, John" , "Muthu Arul Mozhi Perumal (mperumal)" , "Ram Mohan R (rmohanr)" , "Paul Kyzivat (pkyzivat)" X-OriginalArrivalTime: 22 May 2011 22:34:27.0723 (UTC) FILETIME=[68C9EDB0:01CC18D0] Cc: siprec@ietf.org Subject: Re: [siprec] Does MS have life outside a particular CS?(wasRE: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: Sun, 22 May 2011 22:34:36 -0000 Hi all, Please read inline. Thanks Partha -----Original Message----- From: Henry Lum [mailto:Henry.Lum@alcatel-lucent.com]=20 Sent: Friday, May 20, 2011 12:09 AM To: Leon Portman; Elwell, John; Parthasarathi R (partr); Muthu Arul Mozhi Perumal (mperumal); Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) Cc: siprec@ietf.org Subject: RE: [siprec] Does MS have life outside a particular CS?(wasRE:comments on draft-ram-siprec-metadata-04) I agree with John that a recording session transports recorded streams and are already described in the SIP session so there is no need to model recorded streams in the metadata model.=20 Intention of Metadata model is not to directly map with metadata format. Metadata model shows how SRS view the metadata. Metadata may be received as part of RS dialog or RS SDP or new (Metadata) XML. The reason for model is to view the metadata as a whole from SRS point of view and not defining the exact 1:1 mapping on the format.=20 I agree that RS SDP shall be used as some of the metadata attributes like codec parameters. Start & stop time has to defined in Metadata XML ("stream") as it is not possible to provide this CS media information using RS SDP. Media stream reference ("label") attribute in MS provide the linkage between RS SDP and other MS attributes. MS in the metadata model, on the other hand, explains a media stream that is part a CS, and the recorded streams in the RS just refer to which MS in the model is actually being recorded. When we record unmixed streams as a single m-line in the RS, I think we should model as multiple MS in the metadata model but all the MS would refer to the same label in the recorded stream.=20 I'll respond to this question in the extended mail thread by John & Charles When we relate a MS directly to a CS, I think it implicitly means that a CS owns some sort of media sources that generates media. =20 The discussion makes me to think once again about "CS -- Participant -- Media stream" relation rather than having the current form of "CS -- Participant, CS--Media stream and Participant--Media stream". The originally model has only CS-participant-Media stream but it was changed to handle the cases wherein Media stream is not part of any CS participants but part of CS. Now, we agreed upon not to have any participant without CS and model has to be upgraded for MS accordingly. IMO, It shall be changed back to CS--Participant--Media stream. Please let me know your opinion here. In other words, CS owns some automated participants as media sources but we don't explicitly model them. I am okay with this definition since the SRC can choose to model this either way - meaning if there is need to show what the CS is doing to the media sources then the SRC can model a participant that generates the media to explain what it is. These implicit participants should terminate whenever the MS terminates or the CS terminates. Henry > -----Original Message----- > From: Leon Portman [mailto:Leon.Portman@nice.com] > Sent: Thursday, May 19, 2011 1:01 PM > To: Elwell, John; Parthasarathi R (partr); Muthu Arul Mozhi Perumal=20 > (mperumal); Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat); Henry Lum > Cc: siprec@ietf.org > Subject: RE: [siprec] Does MS have life outside a particular=20 > CS?(wasRE:comments on draft-ram-siprec-metadata-04) >=20 > I agree with John. From my point of view MS represent CS media, And it > can be mapped to zero or more RS m-line via metadata labels. IMO, MS represent participant media (which span across multiple CS in case of CSG) if we provide direct relationship with participant. MS will map to one RS m-line via metadata labels. >=20 > Leon >=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Wednesday, May 18, 2011 9:55 PM > To: Parthasarathi R (partr); Muthu Arul Mozhi Perumal (mperumal); Ram=20 > Mohan R (rmohanr); Leon Portman; Paul Kyzivat (pkyzivat); Henry Lum > Cc: siprec@ietf.org > Subject: RE: [siprec] Does MS have life outside a particular CS?(was=20 > RE:comments on draft-ram-siprec-metadata-04) >=20 >=20 >=20 > > -----Original Message----- > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > Sent: 18 May 2011 18:49 > > To: Elwell, John; Muthu Arul Mozhi Perumal (mperumal); Ram Mohan R=20 > > (rmohanr); Leon Portman; Paul Kyzivat (pkyzivat); Henry Lum > > Cc: siprec@ietf.org > > Subject: RE: [siprec] Does MS have life outside a particular CS?(was > > RE:comments on draft-ram-siprec-metadata-04) > > > > John, > > > > Your below mail is a good summary for the decision happened so far. > MS > > lifetime depends upon the relation between RS & CS in a given=20 > > deployment. My understanding w.r.t RS & CS relationship for MS=20 > > lifetime is as follows: > > > > One RS - One CS: MS lifetime is within the scope of single RS or=20 > > single CS > > > > One RS - Many CS: MS lifetime is within the scope of single RS > > > > Many RS - One CS: MS lifetime is within the scope of single CS > [JRE] I don't follow your reasoning with the above two bullets. I think > this gives MS an inconsistent meaning, in that an MS sometimes maps to > one RS and multiple CS, and in other situations an MS maps to one CS=20 > and multiple RSs. I would have great difficulty understanding what a MS > really is.=20 In case of un-mixed stream, MS is directly associated with a particular participant which span across multiple CS within CSG. In case of mixed stream, multiple participants are linked to MS, participant shall added/removed within MS, MS shall span across CS and associated with CSG. Up to now we have discussed a MS having a lifetime only in=20 > the context of a CS and at other times we have discussed a MS having a > lifetime only in the context of an RS (in this case a 1:1 mapping to an > m-line in the SDP). All the time, MS lifetime is within single CSG. >=20 > > > > Many RS - Many CS: MS lifetime is within the scope of Multiple RS or > > Multiple CS. > [JRE] In this case, what is the defining character of an MS, making it > the same MS even though it spans many CSs and many RSs? I can't really > grasp the concept. >=20 > John (as individual) >=20 >=20 > > > > As Many RS- Many CS mechanism is adopted, there is a need for global > > unique id for MS. > > > > Thanks > > Partha > > > > > > -----Original Message----- > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > > Sent: Thursday, May 12, 2011 12:58 PM > > To: Muthu ArulMozhi Perumal (mperumal); Ram Mohan R (rmohanr); Leon=20 > > Portman; Paul Kyzivat (pkyzivat); Henry Lum > > Cc: siprec@ietf.org > > Subject: Re: [siprec] Does MS have life outside a particular CS?(was > > RE:comments on draft-ram-siprec-metadata-04) > > > > I don't recall arguing that MS should be local to a Participant. In=20 > > http://www.ietf.org/mail-archive/web/siprec/current/msg01888.html > > I argued MS should be local to a CS. My reasoning is as follows. > > > > Consider a conference call that has 3 media streams - audio, main=20 > > video and presentation video. Those streams will remain in existence > > throughout the call, but participants will come and go. For example, > > the conference could start with participants A, B and C. Then D and E > > could join, then A could leave, and so on, so you could even end up=20 > > with just D, E and F in the call at the end, but they could still be > > using those three media streams - audio, main video and presentation > > video. So there is no single Participant that a media stream can be=20 > > anchored to for the entire call - the stream instead has to be=20 > > anchored to the CS. Also, the presentation stream can have a number > of > > different Participants transmitting to it, but only one at a time,=20 > > governed by floor control. > > > > So I had argued that an MS should be local to a Participant. At that > > time, I had assumed an MS was modelling a media stream on the CS, but > > the thread then went in the direction of pointing out that really it > > models a media stream on the RS. For example, the audio stream in the > > above example might be sent mixed (contributions from all > > participants) > > using a single m-line in the RS, or might be sent unmixed using=20 > > multiple m-lines in the RS. Some people were arguing that in the > first > > case this would be modelled as one MS and in the second case it would > > be modelled as multiple MSs. I am not sure we really resolved that=20 > > (personally I was more comfortable with modelling an MS as relating > to > > a CS media stream. > > > > Anyway, however MS is modelled, it doesn't seem feasible to make it=20 > > local to a Participant, but it may be feasible to make it local to a > > CS. > > > > But a further issue was raised on the thread. If I use the same RS=20 > > m-line to represent a medium from a number of CSs in series, is this > > the same MS or are they different MSs? If they are the same MS, it=20 > > means the MS object does have a life outside a CS. But then I would=20 > > argue it only needs an ID local to the RS. If the RS object is=20 > > uniquely identified by the SIP dialog identifier, the MS object would > > be sufficiently identified by the SDP m-line on that dialog. > > > > So I am afraid that before we can resolve the question of unique or=20 > > local MS identifiers, we first need to clarify what the MS object is > > and what its lifetime is. > > > > John (as individual) > > > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Muthu > > ArulMozhi Perumal > > > (mperumal) > > > Sent: 11 May 2011 14:49 > > > To: Ram Mohan R (rmohanr); Leon Portman; Paul Kyzivat (pkyzivat);=20 > > > Henry Lum > > > Cc: siprec@ietf.org > > > Subject: Re: [siprec] Does MS have life outside a > > particular CS? (was > > > RE:comments on draft-ram-siprec-metadata-04) > > > > > > If we consider MS as local to a Participant (as John was trying to > > > argue) there seems to be no need for a unique ID for MS > > since it can > > > be inferred from the Participant that can be uniquely identified. > > > > > > The mail thread describes a use-case where multicast MoH > > played to a > > > number of participants and to the SRC is recorded. Can't the MoH=20 > > > source be considered a Participant here? > > > > > > Muthu > > > > > > |-----Original Message----- > > > |From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > > Behalf Of Ram Mohan R (rmohanr) > > > |Sent: Wednesday, May 11, 2011 12:52 PM > > > |To: Leon Portman; Paul Kyzivat (pkyzivat); Henry Lum > > > |Cc: siprec@ietf.org > > > |Subject: Re: [siprec] Does MS have life outside a > > particular CS? (was > > > RE:comments on draft-ram-siprec- > > > |metadata-04) > > > | > > > |Hello All, > > > | > > > |As per the discussions in last meeting and below mail thread > > > it appears > > > |that we would need global ID to take care of all the > > cases. However > > > |there is a disagreement with some folks in having a unique > > > ID. I would > > > |request people to respond on this mail thread and take > > this issue to > > > |closure. > > > | > > > |If no one has issues, we will go with globally Unique ID for > > > MS block. > > > | > > > |Regards, > > > |Ram > > > | > > > |> -----Original Message----- > > > |> From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On > > > |> Behalf Of Leon Portman > > > |> Sent: Thursday, April 28, 2011 9:28 PM > > > |> To: Paul Kyzivat (pkyzivat); Henry Lum > > > |> Cc: siprec@ietf.org > > > |> Subject: Re: [siprec] Does MS have life outside a > > > particular CS? (was > > > |> RE: comments on draft-ram-siprec-metadata-04) > > > |> > > > |> 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: comments 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 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=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=20 > > > |> >> 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=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 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 > > > _______________________________________________ > > > siprec mailing 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 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 From partr@cisco.com Sun May 22 16:14:02 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEE0FE06A6 for ; Sun, 22 May 2011 16:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.396 X-Spam-Level: X-Spam-Status: No, score=-9.396 tagged_above=-999 required=5 tests=[AWL=-0.902, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, 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 rl+3lbNmd1Xt for ; Sun, 22 May 2011 16:14:01 -0700 (PDT) Received: from ams-iport-2.cisco.com (unknown [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id EDFC2E0651 for ; Sun, 22 May 2011 16:14:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=8142; q=dns/txt; s=iport; t=1306106041; x=1307315641; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=MhqLowcgGtTWYZBPqgq8hv6j3m1wvo5Ae4JRbHXVZxI=; b=NDDc1N2kNCKfc0MnoNWdUyWbxhAsMQxCzU90JqldydHfncd/iragbe64 FrCUztxbVHRFGFGCyZjj9V1cSx2Cr/OnZSnmmSmBpabutlggoSBKK+vml s+aXXuLL2ay7ZrvpafyGKOOcVvkmOjigpVJYaeqcsyfTn28j8AqvtpusT k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwBAMOX2U1Io8US/2dsb2JhbACXZI47eIhwnVacR4MUgwUEhk6Ne4pF X-IronPort-AV: E=Sophos;i="4.65,253,1304294400"; d="scan'208";a="31649970" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-2.cisco.com with ESMTP; 22 May 2011 23:13:58 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p4MNDwwa003339; Sun, 22 May 2011 23:13:58 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, 23 May 2011 04:43: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: Mon, 23 May 2011 04:43:57 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Does MS have life outside a particular CS?(wasRE:comments on draft-ram-siprec-metadata-04) Thread-Index: AcwFuuvxdSy9/XTRSVq5DE/JiXPmDAAAgTPwAnuoqVAADSe5cAAkXwaAAUQXHCAAAoVIAAAuh9YwAAJ9VWAAGP/KIABZ8/ZQAC1UwlA= 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><07465C1D981ABC41A344374066! A E1A2C3 8 AB7A20DB @T LVMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD06480E2F@XMB-BGL-417.cisco.com><1D062974A4845E4D8A343C653804920205709791@XMB-BGL-414.cisco.com><07465C1D981ABC41A344374066AE1A2C38AC1D3CFC@TLVMBX01.nice.com><059AF07365DC474393A19A3AF187DF740716E063@NAHALD.us.int.genesyslab.com> From: "Parthasarathi R (partr)" To: "Charles Eckel (eckelcu)" , "Elwell, John" , "Henry Lum" , "Leon Portman" , "Muthu Arul Mozhi Perumal (mperumal)" , "Ram Mohan R (rmohanr)" , "Paul Kyzivat (pkyzivat)" X-OriginalArrivalTime: 22 May 2011 23:13:57.0780 (UTC) FILETIME=[ED73ED40:01CC18D5] Cc: siprec@ietf.org Subject: Re: [siprec] Does MS have life outside a particular CS?(wasRE: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: Sun, 22 May 2011 23:14:02 -0000 Hi all, Please read inline. Thanks Partha=20 -----Original Message----- From: Charles Eckel (eckelcu)=20 Sent: Sunday, May 22, 2011 9:38 PM To: Elwell, John; Henry Lum; Leon Portman; Parthasarathi R (partr); Muthu Arul Mozhi Perumal (mperumal); Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) Cc: siprec@ietf.org Subject: RE: [siprec] Does MS have life outside a particular CS?(wasRE:comments on draft-ram-siprec-metadata-04) Hi John, I viewed this a bit differently. Please see inline. > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > Behalf Of Elwell, John > Sent: Friday, May 20, 2011 12:11 AM > To: Henry Lum; Leon Portman; Parthasarathi R (partr); Muthu Arul Mozhi > Perumal (mperumal); Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > Cc: siprec@ietf.org > Subject: Re: [siprec] Does MS have life outside a particular=20 > CS?(wasRE:comments on draft-ram-siprec- > metadata-04) >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Henry Lum [mailto:Henry.Lum@alcatel-lucent.com] > > Sent: 19 May 2011 19:39 > > To: Leon Portman; Elwell, John; Parthasarathi R (partr); Muthu Arul=20 > > Mozhi Perumal (mperumal); Ram Mohan R (rmohanr); Paul Kyzivat=20 > > (pkyzivat) > > Cc: siprec@ietf.org > > Subject: RE: [siprec] Does MS have life outside a particular=20 > > CS?(wasRE:comments on draft-ram-siprec-metadata-04) > > > > I agree with John that a recording session transports recorded=20 > > streams and are already described in the SIP session so there is no=20 > > need to model recorded streams in the metadata model. MS in the=20 > > metadata model, on the other hand, explains a media stream that is=20 > > part a CS, and the recorded streams in the RS just refer to which MS > > in the model is actually being recorded. When we record unmixed=20 > > streams as a single m-line in the RS, I think we should model as=20 > > multiple MS in the metadata model but all the MS would refer to the=20 > > same label in the recorded stream. > [JRE] Not sure. That might be one way of doing it. So an MS would=20 > represent contribution to a medium (e.g., audio, main video) from a=20 > single Participant. So for a simple 2-party audio-only call there=20 > would be two MS objects, one for Participant 1 and one for Participant 2. This might work, I had not thought of it that way. Participant linkage with MS does the same. Label attribute (media stream attribute) is one of the attribute in MS and not the only attribute. In case of format, element in participant meets this requirement. This is consistent with my thinking on the matter. Certainly it doesn't align with the current metadata model, but of course that > can be changed. One problem that would need to be addressed - how to=20 > tie together different MS objects that all relate to the same medium=20 > (e.g., audio, main video, presentation video). Perhaps they would all share the same "content" attribute. Please clarify more. I'm not getting the exact point here. >=20 > Another way of looking at it is that an MS models a single medium in=20 > the CS, e.g., audio, main video, presentation video. The linkage=20 > between an MS object and a Participant object would then point to an m-line in the SDP. participant shall link m-line in the SDP through MS rather than direct link. It provides better abstraction. In case of only direct relationship with MS and participant to m-line using label attribute and no linkage between MS and participant, the deriving linkage between MS to participant will be tough in few scenarios. Also, Linkage between participant and MS is redundant in case linkage exists between participant and MS To give some examples: >=20 > 1. The SRC sees only mixed streams and doesn't distinguish the=20 > participants. In other words, everything is hidden behind a=20 > focus/mixer - it just sees the conference as a single Participant. In=20 > this case it would be modelled as a single MS with a single Participant. The linkage between the sole Participant and the MS would point to the m-line. Sounds good. > 2. The SRC sees mixed streams but can identify different contributing=20 > participants. In this case it would be modelled as a single MS with=20 > multiple Participants. Each linkage between a Participant and the MS would point to the same m-line. In both examples, Even though same number of linkage, the relationship with participant and MS needs more search with this proposal. This could be modeled in a better way SRC could send mixed stream to SRS, in which case there would be a single m-line in the RS. SSRC for RTP stream would probably be that of the SRC, and CSRC would indicate participants. Alternatively, the SRC could separate them out into multiple streams, either represented as a single RS m-line with different SSRC for each participant, or a different m-line for each participant. =20 your alternative example looks similar to unmixed streams. Please correct me if I'm wrong > 3. The SRC sees unmixed streams from different contributing=20 > participants, but mixes them itself to send to the SRS as a single mixed stream. Modelling is similar to case 2. SRC could send mixed stream to SRS, in which case there would be a single m-line in the RS. SSRC for RTP stream would probably be that of the SRC, and CSRC would indicate participants. In case of mixed stream, exact participant who contributes to the specific timeframe is not well known. Participant information in metadata will help to understand the list of contributing sources. There is no specific requirement to look into CSRC. Please clarify in case I'm missing something. > 4. The SRC sees unmixed streams from different contributing=20 > participants and sends them unmixed as different RTP sessions to the=20 > SRS. In this case it would be modelled as a single MS with multiple Participants. Each linkage between a Participant and the MS would point to a different m-line. =20 I was expecting this to be modeled as multiple different MS. The SRC would send them as multiple streams, either represented as a single RS m-line with different SSRC for each participant, or a different m-line for each participant. Agree with Charles. I'm seeing them as different MS > 5. The SRC sees unmixed streams from different contributing=20 > participants and sends them unmixed using different SSRC values in a=20 > single RTP session to the SRS. In this case it would be modelled as a=20 > single MS with multiple Participants. Each linkage between a Participant and the MS would point to the same m-line. There would also need to be a mechanism for tying a linkage to a particular SSRC value. In all the example, there is duplicate linkage with m-line and participant. The missing point is the linkage between participant and MS. That would be the most lightweight and efficient way, but the SRC could alter it and represent it differently to the RS, if desired. Cheers, Charles >=20 > > > > When we relate a MS directly to a CS, I think it implicitly means=20 > > that a CS owns some sort of media sources that generates media. In=20 > > other words, CS owns some automated participants as media sources=20 > > but we don't explicitly model them. I am okay with this definition=20 > > since the SRC can choose to model this either way - meaning if there > > is need to show what the CS is doing to the media sources then the=20 > > SRC can model a participant that generates the media to explain what > > it is. These implicit participants should terminate whenever the MS=20 > > terminates or the CS terminates. > [JRE] Sounds reasonable. >=20 > John >=20 > > > > Henry > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From john.elwell@siemens-enterprise.com Mon May 23 02:18: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 97F89E06F7 for ; Mon, 23 May 2011 02:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.43 X-Spam-Level: X-Spam-Status: No, score=-106.43 tagged_above=-999 required=5 tests=[AWL=0.169, 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 sPn9pT6yCGmf for ; Mon, 23 May 2011 02:18:52 -0700 (PDT) Received: from mail174.messagelabs.com (mail174.messagelabs.com [85.158.138.51]) by ietfa.amsl.com (Postfix) with SMTP id 8D2FAE0693 for ; Mon, 23 May 2011 02:18:51 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1306142329!14658670!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 2388 invoked from network); 23 May 2011 09:18:49 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-9.tower-174.messagelabs.com with SMTP; 23 May 2011 09:18:49 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id B2E541EB8420 for ; Mon, 23 May 2011 11:18:49 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 23 May 2011 11:18:49 +0200 From: "Elwell, John" To: "siprec@ietf.org" Date: Mon, 23 May 2011 11:18:48 +0200 Thread-Topic: What does an MS object represent? Can we pick one of these options? Thread-Index: AcwZKmxEJ87pgNK9TLyuXW/0h+4I1w== 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] What does an MS object represent? Can we pick one of these options? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 09:18:52 -0000 (Starting a new thread, because the previous thread ("Does MS have lifetime= ...") was getting confused in its various branches.) I think the fundamental question at issue is what exactly an MS object repr= esents. Draft-00 is certainly unclear on this. I think we have been discuss= ing two possibilities: 1. An MS object represents a given medium (e.g., audio, main video, present= ation video, current speaker video...). Different participants can contribu= te to this medium, in which case they are all contributing to this single M= S object. For example, in a 2-party audio-only CS, there is a single MS obj= ect (audio) contributed to by two participants. This has been my way of vie= wing it, but certainly not everyone considers it this way, and I am prepare= d to be persuaded otherwise. 2. An MS object represents a given medium as contributed to by a single par= ticipant (or by multiple participants that are not separately identifiable = and/or where their contributions are inseparable). Where different particip= ants are contributing to the same medium, this is represented by multiple M= S objects. For example, in a 2-party audio-only call, there are two MS obje= cts. In this case, presumably there would need to be some mechanism for tyi= ng together those MS objects representing the same medium (e.g., the two MS= objects representing audio in this same example). Possibly the name Media = Stream is not sufficiently descriptive in this case, but I can't come up wi= th a better name. I think we can possibly make this basic decision, and then fill in the deta= ils afterwards. John (as individual)= From john.elwell@siemens-enterprise.com Mon May 23 02:19:15 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA0B5E06F7 for ; Mon, 23 May 2011 02:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.437 X-Spam-Level: X-Spam-Status: No, score=-106.437 tagged_above=-999 required=5 tests=[AWL=0.162, 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 D8Z5i7qoJ9Kc for ; Mon, 23 May 2011 02:19:15 -0700 (PDT) Received: from mail216.messagelabs.com (mail216.messagelabs.com [85.158.143.99]) by ietfa.amsl.com (Postfix) with SMTP id 7A742E0693 for ; Mon, 23 May 2011 02:19:14 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-14.tower-216.messagelabs.com!1306142352!5789049!1 X-StarScan-Version: 6.2.16; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 17430 invoked from network); 23 May 2011 09:19:12 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-14.tower-216.messagelabs.com with SMTP; 23 May 2011 09:19:12 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id B62021EB841E; Mon, 23 May 2011 11:19:12 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 23 May 2011 11:19:12 +0200 From: "Elwell, John" To: "Charles Eckel (eckelcu)" , Henry Lum , Leon Portman , "Parthasarathi R (partr)" , "Muthu Arul Mozhi Perumal (mperumal)" , "Ram Mohan R (rmohanr)" , "Paul Kyzivat (pkyzivat)" Date: Mon, 23 May 2011 11:19:10 +0200 Thread-Topic: [siprec] Does MS have life outside a particular CS?(wasRE:comments on draft-ram-siprec-metadata-04) Thread-Index: AcwFuuvxdSy9/XTRSVq5DE/JiXPmDAAAgTPwAnuoqVAADSe5cAAkXwaAAUQXHCAAAoVIAAAuh9YwAAJ9VWAAGP/KIABZ8/ZQAEJY2NA= Message-ID: 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><07465C1D981ABC41A344374066! A E1A2C3 8 AB7A20DB @T LVMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD06480E2F@XMB-BGL-417.cisco.com><1D062974A4845E4D8A343C653804920205709791@XMB-BGL-414.cisco.com><07465C1D981ABC41A344374066AE1A2C38AC1D3CFC@TLVMBX01.nice.com><059AF07365DC474393A19A3AF187DF740716E063@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: 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?(wasRE: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: Mon, 23 May 2011 09:19:16 -0000 Charles, I see that my point 2 was rather ambiguous. I said: "2. The SRC sees mixed streams but can identify different contributing part= icipants." What I meant was that the SRC is aware of (by means of the conference event= package, for example) the identities of a number of participants contribut= ing to the stream, but is not aware of their particular contributions. Howe= ver, I had not considered that the different contributors might be known th= rough CSRC. So I agree this introduces further possibilities. John (as individual) > -----Original Message----- > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com]=20 > Sent: 22 May 2011 17:08 > To: Elwell, John; Henry Lum; Leon Portman; Parthasarathi R=20 > (partr); Muthu Arul Mozhi Perumal (mperumal); Ram Mohan R=20 > (rmohanr); Paul Kyzivat (pkyzivat) > Cc: siprec@ietf.org > Subject: RE: [siprec] Does MS have life outside a particular=20 > CS?(wasRE:comments on draft-ram-siprec-metadata-04) >=20 > Hi John, >=20 > I viewed this a bit differently. Please see inline. >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Elwell, John > > Sent: Friday, May 20, 2011 12:11 AM > > To: Henry Lum; Leon Portman; Parthasarathi R (partr); Muthu=20 > Arul Mozhi > Perumal (mperumal); Ram Mohan R > > (rmohanr); Paul Kyzivat (pkyzivat) > > Cc: siprec@ietf.org > > Subject: Re: [siprec] Does MS have life outside a particular > CS?(wasRE:comments on draft-ram-siprec- > > metadata-04) > >=20 > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Henry Lum [mailto:Henry.Lum@alcatel-lucent.com] > > > Sent: 19 May 2011 19:39 > > > To: Leon Portman; Elwell, John; Parthasarathi R (partr); > > > Muthu Arul Mozhi Perumal (mperumal); Ram Mohan R (rmohanr); > > > Paul Kyzivat (pkyzivat) > > > Cc: siprec@ietf.org > > > Subject: RE: [siprec] Does MS have life outside a particular > > > CS?(wasRE:comments on draft-ram-siprec-metadata-04) > > > > > > I agree with John that a recording session transports recorded > streams > > > and are already described in the SIP session so there is=20 > no need to > > > model recorded streams in the metadata model. MS in the > > > metadata model, > > > on the other hand, explains a media stream that is part a CS, and > the > > > recorded streams in the RS just refer to which MS in the model is > > > actually being recorded. When we record unmixed streams=20 > as a single > > > m-line in the RS, I think we should model as multiple MS in > > > the metadata > > > model but all the MS would refer to the same label in the recorded > > > stream. > > [JRE] Not sure. That might be one way of doing it. So an MS would > represent contribution to a medium > > (e.g., audio, main video) from a single Participant. So for a simple > 2-party audio-only call there > > would be two MS objects, one for Participant 1 and one for=20 > Participant > 2. This might work, I had not > > thought of it that way. >=20 > This is consistent with my thinking on the matter. >=20 > Certainly it doesn't align with the current metadata model, but of > course that > > can be changed. One problem that would need to be addressed - how to > tie together different MS objects > > that all relate to the same medium (e.g., audio, main video, > presentation video). Perhaps they would > > all share the same "content" attribute. > >=20 > > Another way of looking at it is that an MS models a single medium in > the CS, e.g., audio, main video, > > presentation video. The linkage between an MS object and a=20 > Participant > object would then point to an > > m-line in the SDP. To give some examples: > >=20 > > 1. The SRC sees only mixed streams and doesn't distinguish the > participants. In other words, > > everything is hidden behind a focus/mixer - it just sees the > conference as a single Participant. In > > this case it would be modelled as a single MS with a single > Participant. The linkage between the sole > > Participant and the MS would point to the m-line. >=20 > Sounds good. >=20 > > 2. The SRC sees mixed streams but can identify different=20 > contributing > participants. In this case it > > would be modelled as a single MS with multiple Participants. Each > linkage between a Participant and > > the MS would point to the same m-line. >=20 > SRC could send mixed stream to SRS, in which case there would be a > single m-line in the RS. SSRC for RTP stream would probably be that of > the SRC, and CSRC would indicate participants. Alternatively, the SRC > could separate them out into multiple streams, either represented as a > single RS m-line with different SSRC for each participant, or a > different m-line for each participant. > =20 > > 3. The SRC sees unmixed streams from different contributing > participants, but mixes them itself to > > send to the SRS as a single mixed stream. Modelling is=20 > similar to case > 2. >=20 > SRC could send mixed stream to SRS, in which case there would be a > single m-line in the RS. SSRC for RTP stream would probably be that of > the SRC, and CSRC would indicate participants. >=20 > > 4. The SRC sees unmixed streams from different contributing > participants and sends them unmixed as > > different RTP sessions to the SRS. In this case it would be modelled > as a single MS with multiple > > Participants. Each linkage between a Participant and the MS would > point to a different m-line.=20 > =20 > I was expecting this to be modeled as multiple different MS. The SRC > would send them as multiple streams, either represented as a single RS > m-line with different SSRC for each participant, or a different m-line > for each participant. >=20 > > 5. The SRC sees unmixed streams from different contributing > participants and sends them unmixed using > > different SSRC values in a single RTP session to the SRS.=20 > In this case > it would be modelled as a > > single MS with multiple Participants. Each linkage between a > Participant and the MS would point to the > > same m-line. There would also need to be a mechanism for tying a > linkage to a particular SSRC value. >=20 > That would be the most lightweight and efficient way, but the=20 > SRC could > alter it and represent it differently to the RS, if desired. >=20 > Cheers, > Charles >=20 > >=20 > > > > > > When we relate a MS directly to a CS, I think it implicitly > > > means that a > > > CS owns some sort of media sources that generates media. In > > > other words, > > > CS owns some automated participants as media sources but we don't > > > explicitly model them. I am okay with this definition since > > > the SRC can > > > choose to model this either way - meaning if there is need to > > > show what > > > the CS is doing to the media sources then the SRC can model a > > > participant that generates the media to explain what it is. These > > > implicit participants should terminate whenever the MS > > > terminates or the > > > CS terminates. > > [JRE] Sounds reasonable. > >=20 > > John > >=20 > > > > > > Henry > > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > = From john.elwell@siemens-enterprise.com Mon May 23 02:19: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 02EBFE06F7 for ; Mon, 23 May 2011 02:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.443 X-Spam-Level: X-Spam-Status: No, score=-106.443 tagged_above=-999 required=5 tests=[AWL=0.156, 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 K2C2T6PRAVxk for ; Mon, 23 May 2011 02:19:42 -0700 (PDT) Received: from mail216.messagelabs.com (mail216.messagelabs.com [85.158.143.99]) by ietfa.amsl.com (Postfix) with SMTP id EC8FDE0693 for ; Mon, 23 May 2011 02:19:41 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1306142380!5795190!1 X-StarScan-Version: 6.2.16; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 8302 invoked from network); 23 May 2011 09:19:40 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-7.tower-216.messagelabs.com with SMTP; 23 May 2011 09:19:40 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id D2B321EB841E; Mon, 23 May 2011 11:19:40 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 23 May 2011 11:19:39 +0200 From: "Elwell, John" To: "Parthasarathi R (partr)" , "Charles Eckel (eckelcu)" , Henry Lum , Leon Portman , "Muthu Arul Mozhi Perumal (mperumal)" , "Ram Mohan R (rmohanr)" , "Paul Kyzivat (pkyzivat)" Date: Mon, 23 May 2011 11:19:38 +0200 Thread-Topic: [siprec] Does MS have life outside a particular CS?(wasRE:comments on draft-ram-siprec-metadata-04) Thread-Index: AcwFuuvxdSy9/XTRSVq5DE/JiXPmDAAAgTPwAnuoqVAADSe5cAAkXwaAAUQXHCAAAoVIAAAuh9YwAAJ9VWAAGP/KIABZ8/ZQAC1UwlAAFb77sA== Message-ID: 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><07465C1D981ABC41A344374066! A E1A2C3 8 AB7A20DB @T LVMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD06480E2F@XMB-BGL-417.cisco.com><1D062974A4845E4D8A343C653804920205709791@XMB-BGL-414.cisco.com><07465C1D981ABC41A344374066AE1A2C38AC1D3CFC@TLVMBX01.nice.com><059AF07365DC474393A19A3AF187DF740716E063@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: 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?(wasRE: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: Mon, 23 May 2011 09:19:44 -0000 =20 > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com]=20 > Sent: 23 May 2011 00:14 > To: Charles Eckel (eckelcu); Elwell, John; Henry Lum; Leon=20 > Portman; Muthu Arul Mozhi Perumal (mperumal); Ram Mohan R=20 > (rmohanr); Paul Kyzivat (pkyzivat) > Cc: siprec@ietf.org > Subject: RE: [siprec] Does MS have life outside a particular=20 > CS?(wasRE:comments on draft-ram-siprec-metadata-04) >=20 > Hi all, >=20 > Please read inline. >=20 > Thanks > Partha=20 >=20 > -----Original Message----- > From: Charles Eckel (eckelcu)=20 > Sent: Sunday, May 22, 2011 9:38 PM > To: Elwell, John; Henry Lum; Leon Portman; Parthasarathi R (partr); > Muthu Arul Mozhi Perumal (mperumal); Ram Mohan R (rmohanr);=20 > Paul Kyzivat > (pkyzivat) > Cc: siprec@ietf.org > Subject: RE: [siprec] Does MS have life outside a particular > CS?(wasRE:comments on draft-ram-siprec-metadata-04) >=20 > Hi John, >=20 > I viewed this a bit differently. Please see inline. >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > > Behalf Of Elwell, John > > Sent: Friday, May 20, 2011 12:11 AM > > To: Henry Lum; Leon Portman; Parthasarathi R (partr); Muthu=20 > Arul Mozhi >=20 > > Perumal (mperumal); Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > Cc: siprec@ietf.org > > Subject: Re: [siprec] Does MS have life outside a particular=20 > > CS?(wasRE:comments on draft-ram-siprec- > > metadata-04) > >=20 > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Henry Lum [mailto:Henry.Lum@alcatel-lucent.com] > > > Sent: 19 May 2011 19:39 > > > To: Leon Portman; Elwell, John; Parthasarathi R (partr);=20 > Muthu Arul=20 > > > Mozhi Perumal (mperumal); Ram Mohan R (rmohanr); Paul Kyzivat=20 > > > (pkyzivat) > > > Cc: siprec@ietf.org > > > Subject: RE: [siprec] Does MS have life outside a particular=20 > > > CS?(wasRE:comments on draft-ram-siprec-metadata-04) > > > > > > I agree with John that a recording session transports recorded=20 > > > streams and are already described in the SIP session so=20 > there is no=20 > > > need to model recorded streams in the metadata model. MS in the=20 > > > metadata model, on the other hand, explains a media=20 > stream that is=20 > > > part a CS, and the recorded streams in the RS just refer=20 > to which MS >=20 > > > in the model is actually being recorded. When we record unmixed=20 > > > streams as a single m-line in the RS, I think we should model as=20 > > > multiple MS in the metadata model but all the MS would=20 > refer to the=20 > > > same label in the recorded stream. > > [JRE] Not sure. That might be one way of doing it. So an MS would=20 > > represent contribution to a medium (e.g., audio, main video) from a=20 > > single Participant. So for a simple 2-party audio-only call there=20 > > would be two MS objects, one for Participant 1 and one for=20 > Participant > 2. This might work, I had not thought of it that way. >=20 > Participant linkage with MS does the same. Label attribute > (media stream attribute) is one of the attribute in MS and=20 > not the only > attribute. In case of format, element in participant meets this > requirement. >=20 > This is consistent with my thinking on the matter. >=20 > Certainly it doesn't align with the current metadata model, but of > course that > > can be changed. One problem that would need to be addressed=20 > - how to=20 > > tie together different MS objects that all relate to the=20 > same medium=20 > > (e.g., audio, main video, presentation video). Perhaps they=20 > would all > share the same "content" attribute. > Please clarify more. I'm not getting the exact point here. > [JRE] Several participants are contributing to a single medium (e.g., audio= , main video, presentation video, current speaker video) and those contribu= tions get delivered separately to the SRS. I understand you favour modellin= g this as separate Media Stream objects. The point I am trying to make is t= hat MS objects relating to the same medium probably need to be tied togethe= r somehow, so that the SRS recognises them as belonging to the same medium,= rather than to different media. >=20 > >=20 > > Another way of looking at it is that an MS models a single=20 > medium in=20 > > the CS, e.g., audio, main video, presentation video. The linkage=20 > > between an MS object and a Participant object would then point to an > m-line in the SDP. >=20 > participant shall link m-line in the SDP through MS=20 > rather than > direct link. It provides better abstraction. In case of only direct > relationship with MS and participant to m-line using label=20 > attribute and > no linkage between MS and participant, the deriving linkage between MS > to participant will be tough in few scenarios. Also, Linkage between > participant and MS is redundant in case linkage exists between > participant and MS [JRE] I agree there would not be a direct link from Participant object to m= -line - I don't think anyone proposed that. >=20 > To give some examples: > >=20 > > 1. The SRC sees only mixed streams and doesn't distinguish the=20 > > participants. In other words, everything is hidden behind a=20 > > focus/mixer - it just sees the conference as a single=20 > Participant. In=20 > > this case it would be modelled as a single MS with a single > Participant. The linkage between the sole Participant and the MS would > point to the m-line. >=20 > Sounds good. >=20 > > 2. The SRC sees mixed streams but can identify different=20 > contributing=20 > > participants. In this case it would be modelled as a single MS with=20 > > multiple Participants. Each linkage between a Participant and the MS > would point to the same m-line. >=20 > In both examples, Even though same number of linkage, the > relationship with participant and MS needs more search with this > proposal. This could be modeled in a better way >=20 > SRC could send mixed stream to SRS, in which case there would be a > single m-line in the RS. SSRC for RTP stream would probably be that of > the SRC, and CSRC would indicate participants. Alternatively, the SRC > could separate them out into multiple streams, either represented as a > single RS m-line with different SSRC for each participant, or a > different m-line for each participant. > =20 > your alternative example looks similar to unmixed streams. > Please correct me if I'm wrong >=20 > > 3. The SRC sees unmixed streams from different contributing=20 > > participants, but mixes them itself to send to the SRS as a single > mixed stream. Modelling is similar to case 2. >=20 > SRC could send mixed stream to SRS, in which case there would be a > single m-line in the RS. SSRC for RTP stream would probably be that of > the SRC, and CSRC would indicate participants. >=20 > In case of mixed stream, exact participant who contributes to > the specific timeframe is not well known. Participant information in > metadata will help to understand the list of contributing=20 > sources. There > is no specific requirement to look into CSRC. Please clarify=20 > in case I'm > missing something. >=20 > > 4. The SRC sees unmixed streams from different contributing=20 > > participants and sends them unmixed as different RTP=20 > sessions to the=20 > > SRS. In this case it would be modelled as a single MS with multiple > Participants. Each linkage between a Participant and the MS=20 > would point > to a different m-line. > =20 > I was expecting this to be modeled as multiple different MS. The SRC > would send them as multiple streams, either represented as a single RS > m-line with different SSRC for each participant, or a different m-line > for each participant. >=20 > Agree with Charles. I'm seeing them as different MS [JRE] OK - perhaps that works. To get this sorted out (I will go with the m= ajority) I am starting a separate thread. >=20 > > 5. The SRC sees unmixed streams from different contributing=20 > > participants and sends them unmixed using different SSRC=20 > values in a=20 > > single RTP session to the SRS. In this case it would be=20 > modelled as a=20 > > single MS with multiple Participants. Each linkage between a > Participant and the MS would point to the same m-line. There=20 > would also > need to be a mechanism for tying a linkage to a particular SSRC value. >=20 > In all the example, there is duplicate linkage with=20 > m-line and > participant. The missing point is the linkage between participant and > MS. [JRE] I don't understand. There will always need to be linkage (association= ) between a Participant and a Media Stream. John (as individual) >=20 > That would be the most lightweight and efficient way, but the=20 > SRC could > alter it and represent it differently to the RS, if desired. >=20 > Cheers, > Charles >=20 > >=20 > > > > > > When we relate a MS directly to a CS, I think it implicitly means=20 > > > that a CS owns some sort of media sources that generates=20 > media. In=20 > > > other words, CS owns some automated participants as media sources=20 > > > but we don't explicitly model them. I am okay with this=20 > definition=20 > > > since the SRC can choose to model this either way -=20 > meaning if there >=20 > > > is need to show what the CS is doing to the media sources=20 > then the=20 > > > SRC can model a participant that generates the media to=20 > explain what >=20 > > > it is. These implicit participants should terminate=20 > whenever the MS=20 > > > terminates or the CS terminates. > > [JRE] Sounds reasonable. > >=20 > > John > >=20 > > > > > > Henry > > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > = From partr@cisco.com Mon May 23 03:11: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 01733E06ED for ; Mon, 23 May 2011 03:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.336 X-Spam-Level: X-Spam-Status: No, score=-10.336 tagged_above=-999 required=5 tests=[AWL=0.263, 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 nlcqXaBl8WWo for ; Mon, 23 May 2011 03:10:54 -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 58038E06A7 for ; Mon, 23 May 2011 03:10:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=2150; q=dns/txt; s=iport; t=1306145454; x=1307355054; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=NgMlRIMivhY/6931KSqTpGN8EcKmB94UWAClh2hsqKg=; b=WZXEXkHp5OTT+eemKkMvwALnpvtj1XgK+zySELy+7luy+wX2jPzHlP6E +ZNeyv1fmv/PYljwQzBdLq7iMcZm/XX2mUvJ/NrkXMqHuKsVb5d6Ftcg3 7a098lV28QS8RlzZAZmy6yg/oxr6iWHgDCrmEMcLBIMPms3wzbBsRUYio 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGQy2k1Io8UQ/2dsb2JhbACmInilNpx3hhkEhk6Ne4pF X-IronPort-AV: E=Sophos;i="4.65,255,1304294400"; d="scan'208";a="31765340" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-2.cisco.com with ESMTP; 23 May 2011 10:10:51 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4NAApFX023167; Mon, 23 May 2011 10:10:51 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, 23 May 2011 15:39: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: Mon, 23 May 2011 15:39:45 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Does MS have life outside a particular CS?(wasRE:comments on draft-ram-siprec-metadata-04) Thread-Index: AcwFuuvxdSy9/XTRSVq5DE/JiXPmDAAAgTPwAnuoqVAADSe5cAAkXwaAAUQXHCAAAoVIAAAuh9YwAAJ9VWAAGP/KIABZ8/ZQAC1UwlAAFb77sAAAuu4w 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><07465C1D981ABC41A344374066! A E1A2C 3 8 AB7A20 DB @TLVMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD06480E2F@XMB-BGL-417.cisco.com><1D062974A4845E4D8A343C653804920205709791@XMB-BGL-414.cisco.com><07465C1D981ABC41A344374066AE1A2C38AC1D3CFC@TLVMBX01.nice.com><059AF07365DC474393A19A3AF187DF740716E063@NAHALD.us.int.genesyslab.com> From: "Parthasarathi R (partr)" To: "Elwell, John" , "Charles Eckel (eckelcu)" , "Henry Lum" , "Leon Portman" , "Muthu Arul Mozhi Perumal (mperumal)" , "Ram Mohan R (rmohanr)" , "Paul Kyzivat (pkyzivat)" X-OriginalArrivalTime: 23 May 2011 10:09:46.0071 (UTC) FILETIME=[8ADCA670:01CC1931] Cc: siprec@ietf.org Subject: Re: [siprec] Does MS have life outside a particular CS?(wasRE: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: Mon, 23 May 2011 10:11:00 -0000 John=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >One problem that would need to be addressed > - how to > > tie together different MS objects that all relate to the > same medium > > (e.g., audio, main video, presentation video). Perhaps they > would all > share the same "content" attribute. > Please clarify more. I'm not getting the exact point here. > [JRE] Several participants are contributing to a single medium (e.g., audio, main video, presentation video, current speaker video) and those contributions get delivered separately to the SRS. I understand you favour modelling this as separate Media Stream objects. The point I am trying to make is that MS objects relating to the same medium probably need to be tied together somehow, so that the SRS recognises them as belonging to the same medium, rather than to different media. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Thanks for the clarification. I skimmed through 'content' attribute spec (RFC 4796) but it does not seems to help grouping but it will help to differentiate the media. In case of multiple media stream has to be grouped together, we will explore to use some grouping mechanism options like SDP grouping. Charles earlier proposed to tie together in the single m-line and use CSRC to differentiate the contributors within the single medium. The caveat with that approach is that SRC will not be able to acts as RTP translator. Due to this caveat, I won't prefer to have SIPREC's only mechanism as single MS for specific media type within multiple participant. The mixed stream for specific media type will tie-together for several contributors but it will work only for audio and not for video, so it will not be taken as a generic approach. My other queries in the mail thread are due to the my misinterpretation of your proposal, so Pls ignore it. =20 Thanks Partha From pkyzivat@cisco.com Mon May 23 05:22: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 B693AE077D for ; Mon, 23 May 2011 05:22: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 BZflxHdH33wh for ; Mon, 23 May 2011 05:22:40 -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 D459AE06AF for ; Mon, 23 May 2011 05:22:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=2386; q=dns/txt; s=iport; t=1306153360; x=1307362960; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=qZEJ+HoMYCujK8Yx9LsU3mHojdhAu4sr/bk+z11u4V4=; b=I8TxWYkNtXIgLYPXVgqWpMwrnz4akRmipGXh9FqhKRFab89flGLXyC09 jOaydXdDUP/49g36iErMkbDqHK2heiMP0+UagvOZghchvMhqfrTlyddi1 3Yz8VzNV6zkbIXh9cld/U8JXbwD7hgl14BqC48iT32x/l37/2u/NftH44 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMHAJZQ2k2tJV2a/2dsb2JhbACYJo1+d6UgnHyDFIMFBJARhC+KYg X-IronPort-AV: E=Sophos;i="4.65,256,1304294400"; d="scan'208";a="452532245" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by sj-iport-1.cisco.com with ESMTP; 23 May 2011 12:22:40 +0000 Received: from [10.86.244.32] ([10.86.244.32]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p4NCMdtO008371 for ; Mon, 23 May 2011 12:22:39 GMT Message-ID: <4DDA518F.1060509@cisco.com> Date: Mon, 23 May 2011 08:22:39 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 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] What does an MS object represent? Can we pick one of these options? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 12:22:41 -0000 John, I have been thinking of it as more like (2). I would allow the two streams matched in an o/a by m-line offset to be reported as two MS if passed to the RS separately, as as one MS if mixed and passed to the RS as one. I guess you are right that we ought to indicate the pairing of MS in the sense above via something in the metadata. If not explicitly so indicated it can probably be inferred in common simple cases, but might be difficult to infer in more complex cases. It is good when we identify and sort out these ambiguities. Thanks, Paul On 5/23/2011 5:18 AM, Elwell, John wrote: > (Starting a new thread, because the previous thread ("Does MS have lifetime...") was getting confused in its various branches.) > > I think the fundamental question at issue is what exactly an MS object represents. Draft-00 is certainly unclear on this. I think we have been discussing two possibilities: > > 1. An MS object represents a given medium (e.g., audio, main video, presentation video, current speaker video...). Different participants can contribute to this medium, in which case they are all contributing to this single MS object. For example, in a 2-party audio-only CS, there is a single MS object (audio) contributed to by two participants. This has been my way of viewing it, but certainly not everyone considers it this way, and I am prepared to be persuaded otherwise. > > 2. An MS object represents a given medium as contributed to by a single participant (or by multiple participants that are not separately identifiable and/or where their contributions are inseparable). Where different participants are contributing to the same medium, this is represented by multiple MS objects. For example, in a 2-party audio-only call, there are two MS objects. In this case, presumably there would need to be some mechanism for tying together those MS objects representing the same medium (e.g., the two MS objects representing audio in this same example). Possibly the name Media Stream is not sufficiently descriptive in this case, but I can't come up with a better name. > > I think we can possibly make this basic decision, and then fill in the details afterwards. > > John (as individual) > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From john.elwell@siemens-enterprise.com Mon May 23 05:33:36 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C228E077D for ; Mon, 23 May 2011 05:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 Qzd4N96c883z for ; Mon, 23 May 2011 05:33:35 -0700 (PDT) Received: from mail174.messagelabs.com (mail174.messagelabs.com [85.158.138.51]) by ietfa.amsl.com (Postfix) with SMTP id 5E107E0778 for ; Mon, 23 May 2011 05:33:35 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1306154014!14348955!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 31706 invoked from network); 23 May 2011 12:33:34 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-15.tower-174.messagelabs.com with SMTP; 23 May 2011 12:33:34 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 2131D23F03E2; Mon, 23 May 2011 14:33:34 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 23 May 2011 14:33:34 +0200 From: "Elwell, John" To: "Parthasarathi R (partr)" , "Charles Eckel (eckelcu)" , Henry Lum , Leon Portman , "Muthu Arul Mozhi Perumal (mperumal)" , "Ram Mohan R (rmohanr)" , "Paul Kyzivat (pkyzivat)" Date: Mon, 23 May 2011 14:33:32 +0200 Thread-Topic: [siprec] Does MS have life outside a particular CS?(wasRE:comments on draft-ram-siprec-metadata-04) Thread-Index: AcwFuuvxdSy9/XTRSVq5DE/JiXPmDAAAgTPwAnuoqVAADSe5cAAkXwaAAUQXHCAAAoVIAAAuh9YwAAJ9VWAAGP/KIABZ8/ZQAC1UwlAAFb77sAAAuu4wAAaKj3A= Message-ID: 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><07465C1D981ABC41A344374066! A E1A2C 3 8 AB7A20 DB @TLVMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD06480E2F@XMB-BGL-417.cisco.com><1D062974A4845E4D8A343C653804920205709791@XMB-BGL-414.cisco.com><07465C1D981ABC41A344374066AE1A2C38AC1D3CFC@TLVMBX01.nice.com><059AF07365DC474393A19A3AF187DF740716E063@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: 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?(wasRE: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: Mon, 23 May 2011 12:33:36 -0000 Partha, I don't think we need an SDP mechanism for grouping MS objects belonging to= the same medium - the metadata can provide that linkage somehow. John (as individual) > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com]=20 > Sent: 23 May 2011 11:10 > To: Elwell, John; Charles Eckel (eckelcu); Henry Lum; Leon=20 > Portman; Muthu Arul Mozhi Perumal (mperumal); Ram Mohan R=20 > (rmohanr); Paul Kyzivat (pkyzivat) > Cc: siprec@ietf.org > Subject: RE: [siprec] Does MS have life outside a particular=20 > CS?(wasRE:comments on draft-ram-siprec-metadata-04) >=20 > John=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >One problem that would need to be addressed > > - how to > > > tie together different MS objects that all relate to the > > same medium > > > (e.g., audio, main video, presentation video). Perhaps they > > would all > > share the same "content" attribute. > > Please clarify more. I'm not getting the exact point here. > > > [JRE] Several participants are contributing to a single medium (e.g., > audio, main video, presentation video, current speaker video)=20 > and those > contributions get delivered separately to the SRS. I understand you > favour modelling this as separate Media Stream objects. The point I am > trying to make is that MS objects relating to the same medium probably > need to be tied together somehow, so that the SRS recognises them as > belonging to the same medium, rather than to different media. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Thanks for the clarification. I skimmed through 'content' > attribute spec (RFC 4796) but it does not seems to help=20 > grouping but it > will help to differentiate the media. In case of multiple media stream > has to be grouped together, we will explore to use some grouping > mechanism options like SDP grouping. >=20 > Charles earlier proposed to tie together in the single m-line and use > CSRC to differentiate the contributors within the single medium. The > caveat with that approach is that SRC will not be able to acts as RTP > translator. Due to this caveat, I won't prefer to have SIPREC's only > mechanism as single MS for specific media type within multiple > participant. >=20 > The mixed stream for specific media type will tie-together for several > contributors but it will work only for audio and not for video, so it > will not be taken as a generic approach. >=20 > My other queries in the mail thread are due to the my=20 > misinterpretation > of your proposal, so Pls ignore it. =20 >=20 > Thanks > Partha > = From eckelcu@cisco.com Mon May 23 08:24:29 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0D55E07C4 for ; Mon, 23 May 2011 08:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.561 X-Spam-Level: X-Spam-Status: No, score=-10.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 xN8aOHj-byGc for ; Mon, 23 May 2011 08:24:27 -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 787A7E07C9 for ; Mon, 23 May 2011 08:24:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=9329; q=dns/txt; s=iport; t=1306164267; x=1307373867; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=L1HFZpZwA5RQo7cg4qKUIARO7cMkWwIT9++hqZIGz+Q=; b=Iwu9vcX8woG8y6wb6SoRUmosDR7b9DtBM78L3d600bTKrP6Oyq2D+t/I Hx5XfLV4BaGBynvK19cvFS7GTjIokfqoydYvqkpZPQVDL44r94usaTbrM 9WnLH2s9fTfPWRhmSUgq20lismI3D2dbvBEWPKoY9DshbHRlY+ag9Fund Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUBADh72k2rRDoG/2dsb2JhbACXaI4/d4hwnRydIoMUgwUEhlCNeYpd X-IronPort-AV: E=Sophos;i="4.65,257,1304294400"; d="scan'208";a="362484655" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-2.cisco.com with ESMTP; 23 May 2011 15:24:25 +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 p4NFOPcL012747; Mon, 23 May 2011 15:24:25 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, 23 May 2011 08:24:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 23 May 2011 08:24:23 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Does MS have life outside a particular CS?(wasRE:comments on draft-ram-siprec-metadata-04) Thread-Index: AcwFuuvxdSy9/XTRSVq5DE/JiXPmDAAAgTPwAnuoqVAADSe5cAAkXwaAAUQXHCAAAoVIAAAuh9YwAAJ9VWAAGP/KIABZ8/ZQAC1UwlAAIgmvcA== 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><07465C1D981ABC41A344374066! A E1A2C3 8 AB7A20DB @T LVMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD06480E2F@XMB-BGL-417.cisco.com><1D062974A4845E4D8A343C653804920205709791@XMB-BGL-414.cisco.com><07465C1D981ABC41A344374066AE1A2C38AC1D3CFC@TLVMBX01.nice.com><059AF07365DC474393A19A3AF187DF740716E063@NAHALD.us.int.genesyslab.com> From: "Charles Eckel (eckelcu)" To: "Parthasarathi R (partr)" , "Elwell, John" , "Henry Lum" , "Leon Portman" , "Muthu Arul Mozhi Perumal (mperumal)" , "Ram Mohan R (rmohanr)" , "Paul Kyzivat (pkyzivat)" X-OriginalArrivalTime: 23 May 2011 15:24:25.0114 (UTC) FILETIME=[7FA5FFA0:01CC195D] Cc: siprec@ietf.org Subject: Re: [siprec] Does MS have life outside a particular CS?(wasRE: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: Mon, 23 May 2011 15:24:29 -0000 Hi Partha, Please see inline for answers to the questions you raised regarding the comments I added previously. > -----Original Message----- > From: Parthasarathi R (partr) > Sent: Sunday, May 22, 2011 4:14 PM > To: Charles Eckel (eckelcu); 'Elwell, John'; 'Henry Lum'; 'Leon Portman'; Muthu Arul Mozhi Perumal > (mperumal); Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > Cc: 'siprec@ietf.org' > Subject: RE: [siprec] Does MS have life outside a particular CS?(wasRE:comments on draft-ram-siprec- > metadata-04) >=20 > Hi all, >=20 > Please read inline. >=20 > Thanks > Partha >=20 > -----Original Message----- > From: Charles Eckel (eckelcu) > Sent: Sunday, May 22, 2011 9:38 PM > To: Elwell, John; Henry Lum; Leon Portman; Parthasarathi R (partr); Muthu Arul Mozhi Perumal > (mperumal); Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > Cc: siprec@ietf.org > Subject: RE: [siprec] Does MS have life outside a particular CS?(wasRE:comments on draft-ram-siprec- > metadata-04) >=20 > Hi John, >=20 > I viewed this a bit differently. Please see inline. >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Elwell, John > > Sent: Friday, May 20, 2011 12:11 AM > > To: Henry Lum; Leon Portman; Parthasarathi R (partr); Muthu Arul Mozhi > > Perumal (mperumal); Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > Cc: siprec@ietf.org > > Subject: Re: [siprec] Does MS have life outside a particular > > CS?(wasRE:comments on draft-ram-siprec- > > metadata-04) > > > > > > > > > > > -----Original Message----- > > > From: Henry Lum [mailto:Henry.Lum@alcatel-lucent.com] > > > Sent: 19 May 2011 19:39 > > > To: Leon Portman; Elwell, John; Parthasarathi R (partr); Muthu Arul > > > Mozhi Perumal (mperumal); Ram Mohan R (rmohanr); Paul Kyzivat > > > (pkyzivat) > > > Cc: siprec@ietf.org > > > Subject: RE: [siprec] Does MS have life outside a particular > > > CS?(wasRE:comments on draft-ram-siprec-metadata-04) > > > > > > I agree with John that a recording session transports recorded > > > streams and are already described in the SIP session so there is no > > > need to model recorded streams in the metadata model. MS in the > > > metadata model, on the other hand, explains a media stream that is > > > part a CS, and the recorded streams in the RS just refer to which MS > > > in the model is actually being recorded. When we record unmixed > > > streams as a single m-line in the RS, I think we should model as > > > multiple MS in the metadata model but all the MS would refer to the > > > same label in the recorded stream. > > [JRE] Not sure. That might be one way of doing it. So an MS would > > represent contribution to a medium (e.g., audio, main video) from a > > single Participant. So for a simple 2-party audio-only call there > > would be two MS objects, one for Participant 1 and one for Participant 2. This might work, I had not > thought of it that way. >=20 > Participant linkage with MS does the same. Label attribute (media stream attribute) is one of > the attribute in MS and not the only attribute. In case of format, element in participant meets > this requirement. >=20 > This is consistent with my thinking on the matter. >=20 > Certainly it doesn't align with the current metadata model, but of course that > > can be changed. One problem that would need to be addressed - how to > > tie together different MS objects that all relate to the same medium > > (e.g., audio, main video, presentation video). Perhaps they would all share the same "content" > attribute. > Please clarify more. I'm not getting the exact point here. >=20 > > > > Another way of looking at it is that an MS models a single medium in > > the CS, e.g., audio, main video, presentation video. The linkage > > between an MS object and a Participant object would then point to an m-line in the SDP. >=20 > participant shall link m-line in the SDP through MS rather than direct link. It provides > better abstraction. In case of only direct relationship with MS and participant to m-line using label > attribute and no linkage between MS and participant, the deriving linkage between MS to participant > will be tough in few scenarios. Also, Linkage between participant and MS is redundant in case linkage > exists between participant and MS >=20 > To give some examples: > > > > 1. The SRC sees only mixed streams and doesn't distinguish the > > participants. In other words, everything is hidden behind a > > focus/mixer - it just sees the conference as a single Participant. In > > this case it would be modelled as a single MS with a single Participant. The linkage between the > sole Participant and the MS would point to the m-line. >=20 > Sounds good. >=20 > > 2. The SRC sees mixed streams but can identify different contributing > > participants. In this case it would be modelled as a single MS with > > multiple Participants. Each linkage between a Participant and the MS would point to the same m-line. >=20 > In both examples, Even though same number of linkage, the relationship with participant and > MS needs more search with this proposal. This could be modeled in a better way >=20 > SRC could send mixed stream to SRS, in which case there would be a single m-line in the RS. SSRC for > RTP stream would probably be that of the SRC, and CSRC would indicate participants. Alternatively, the > SRC could separate them out into multiple streams, either represented as a single RS m-line with > different SSRC for each participant, or a different m-line for each participant. >=20 > your alternative example looks similar to unmixed streams. Please correct me if I'm wrong > Yes. In this case, the SRC sees a mixed stream within the CS, and can represent it as either a single mixed stream, or one of more unmixed streams within the RS. =20 > > 3. The SRC sees unmixed streams from different contributing > > participants, but mixes them itself to send to the SRS as a single mixed stream. Modelling is > similar to case 2. >=20 > SRC could send mixed stream to SRS, in which case there would be a single m-line in the RS. SSRC for > RTP stream would probably be that of the SRC, and CSRC would indicate participants. >=20 > In case of mixed stream, exact participant who contributes to the specific timeframe is not > well known. Participant information in metadata will help to understand the list of contributing > sources. There is no specific requirement to look into CSRC. Please clarify in case I'm missing > something. Within a mixed stream, the CSRC may be used to indicate the contributing streams. Changes to the CSRC values can be as frequent as required to indicate changes among the actual contributors.=20 Cheers, Charles > > 4. The SRC sees unmixed streams from different contributing > > participants and sends them unmixed as different RTP sessions to the > > SRS. In this case it would be modelled as a single MS with multiple Participants. Each linkage > between a Participant and the MS would point to a different m-line. >=20 > I was expecting this to be modeled as multiple different MS. The SRC would send them as multiple > streams, either represented as a single RS m-line with different SSRC for each participant, or a > different m-line for each participant. >=20 > Agree with Charles. I'm seeing them as different MS >=20 > > 5. The SRC sees unmixed streams from different contributing > > participants and sends them unmixed using different SSRC values in a > > single RTP session to the SRS. In this case it would be modelled as a > > single MS with multiple Participants. Each linkage between a Participant and the MS would point to > the same m-line. There would also need to be a mechanism for tying a linkage to a particular SSRC > value. >=20 > In all the example, there is duplicate linkage with m-line and participant. The missing point > is the linkage between participant and MS. >=20 > That would be the most lightweight and efficient way, but the SRC could alter it and represent it > differently to the RS, if desired. >=20 > Cheers, > Charles >=20 > > > > > > > > When we relate a MS directly to a CS, I think it implicitly means > > > that a CS owns some sort of media sources that generates media. In > > > other words, CS owns some automated participants as media sources > > > but we don't explicitly model them. I am okay with this definition > > > since the SRC can choose to model this either way - meaning if there > > > is need to show what the CS is doing to the media sources then the > > > SRC can model a participant that generates the media to explain what > > > it is. These implicit participants should terminate whenever the MS > > > terminates or the CS terminates. > > [JRE] Sounds reasonable. > > > > John > > > > > > > > Henry > > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec From eckelcu@cisco.com Mon May 23 08: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 3EC72E06A3 for ; Mon, 23 May 2011 08:54:06 -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=-1.019, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, 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 CGaRa5bXxGo4 for ; Mon, 23 May 2011 08:54:04 -0700 (PDT) Received: from sj-iport-3.cisco.com (unknown [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9A86AE067F for ; Mon, 23 May 2011 08:54:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=2390; q=dns/txt; s=iport; t=1306166044; x=1307375644; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=c/mwC43o61LQFh7Kps8U/ogJaCpAWHAdyyVuo7hcyCY=; b=FkmvSsHLcHaMjf9AYiN0ABoEba83t1D3HSP+xq1zICp6EpXYg3guTU9B QCl9fkpEmkSLqjvIELBTkCOmmjEA0izZlwWshjvLHvxqOXfj3I1frFAyy 7KivQwrwE7tt2/xciWj2LGIMW7mvlOhtFetH+8C6imaqsh6LMnLQybAMy I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUBANiB2k2rRDoI/2dsb2JhbACXaI4/d6cxnTGGGQSGUI15il0 X-IronPort-AV: E=Sophos;i="4.65,257,1304294400"; d="scan'208";a="321686587" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-3.cisco.com with ESMTP; 23 May 2011 15:54:04 +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 p4NFs3r5010435; Mon, 23 May 2011 15:54:03 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, 23 May 2011 08:53:53 -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, 23 May 2011 08:53:52 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] What does an MS object represent? Can we pick one of theseoptions? Thread-Index: AcwZKmxEJ87pgNK9TLyuXW/0h+4I1wANpoBw References: From: "Charles Eckel (eckelcu)" To: "Elwell, John" , X-OriginalArrivalTime: 23 May 2011 15:53:53.0083 (UTC) FILETIME=[9D70A8B0:01CC1961] Subject: Re: [siprec] What does an MS object represent? Can we pick one of theseoptions? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 15:54:06 -0000 My thinking up until this point has been more aligned with option 2. I so see some benefit and simplification provided by option 1, but I think the flexibility provided by option 2 is worth the added complexity of representing an MS on a more granular level. Cheers, Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > Sent: Monday, May 23, 2011 2:19 AM > To: siprec@ietf.org > Subject: [siprec] What does an MS object represent? Can we pick one of theseoptions? >=20 > (Starting a new thread, because the previous thread ("Does MS have lifetime...") was getting confused > in its various branches.) >=20 > I think the fundamental question at issue is what exactly an MS object represents. Draft-00 is > certainly unclear on this. I think we have been discussing two possibilities: >=20 > 1. An MS object represents a given medium (e.g., audio, main video, presentation video, current > speaker video...). Different participants can contribute to this medium, in which case they are all > contributing to this single MS object. For example, in a 2-party audio-only CS, there is a single MS > object (audio) contributed to by two participants. This has been my way of viewing it, but certainly > not everyone considers it this way, and I am prepared to be persuaded otherwise. >=20 > 2. An MS object represents a given medium as contributed to by a single participant (or by multiple > participants that are not separately identifiable and/or where their contributions are inseparable). > Where different participants are contributing to the same medium, this is represented by multiple MS > objects. For example, in a 2-party audio-only call, there are two MS objects. In this case, presumably > there would need to be some mechanism for tying together those MS objects representing the same medium > (e.g., the two MS objects representing audio in this same example). Possibly the name Media Stream is > not sufficiently descriptive in this case, but I can't come up with a better name. >=20 > I think we can possibly make this basic decision, and then fill in the details afterwards. >=20 > John (as individual) > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From pkyzivat@cisco.com Mon May 23 09:23:17 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56D80E07A1 for ; Mon, 23 May 2011 09:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.224 X-Spam-Level: X-Spam-Status: No, score=-110.224 tagged_above=-999 required=5 tests=[AWL=0.375, 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 WyCGPIkZY2Wg for ; Mon, 23 May 2011 09:23:16 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC2FE0798 for ; Mon, 23 May 2011 09:23:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=2752; q=dns/txt; s=iport; t=1306167796; x=1307377396; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=i3giSTKgzTqOpMLOQ+b/A7k+sG8b1JmuAita5/Sfr3Q=; b=JCK2Z51tD//cKQ2QMmx4f7xM4HEM4rgvGNtIaATSEHAP1H0AOJuZudQe OZtS7iW00n8w8Rf91MJic+Cb0IVpVhnHxW1XdGboYIhrEFzitkrivxcNm MPLzZ/8A8G0vSnwrL3M1+rKPlgc0X4jsDRHCPkzpFcbChPVSYisZZr2Kf E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnkBAFGJ2k2tJXHA/2dsb2JhbACXaECNf3enVp0yhhkEkBGEL4pi X-IronPort-AV: E=Sophos;i="4.65,257,1304294400"; d="scan'208";a="233942520" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rtp-iport-1.cisco.com with ESMTP; 23 May 2011 16:23:15 +0000 Received: from [161.44.174.124] (dhcp-161-44-174-124.cisco.com [161.44.174.124]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p4NGNF7f029376 for ; Mon, 23 May 2011 16:23:15 GMT Message-ID: <4DDA89F2.50706@cisco.com> Date: Mon, 23 May 2011 12:23:14 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 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] What does an MS object represent? Can we pick one of theseoptions? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 16:23:17 -0000 IIUC, option 1 can be achieved as one of the possibilities within option 2. Thanks, Paul On 5/23/2011 11:53 AM, Charles Eckel (eckelcu) wrote: > My thinking up until this point has been more aligned with option 2. > I so see some benefit and simplification provided by option 1, but I > think the flexibility provided by option 2 is worth the added complexity > of representing an MS on a more granular level. > > Cheers, > Charles > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Elwell, John >> Sent: Monday, May 23, 2011 2:19 AM >> To: siprec@ietf.org >> Subject: [siprec] What does an MS object represent? Can we pick one of > theseoptions? >> >> (Starting a new thread, because the previous thread ("Does MS have > lifetime...") was getting confused >> in its various branches.) >> >> I think the fundamental question at issue is what exactly an MS object > represents. Draft-00 is >> certainly unclear on this. I think we have been discussing two > possibilities: >> >> 1. An MS object represents a given medium (e.g., audio, main video, > presentation video, current >> speaker video...). Different participants can contribute to this > medium, in which case they are all >> contributing to this single MS object. For example, in a 2-party > audio-only CS, there is a single MS >> object (audio) contributed to by two participants. This has been my > way of viewing it, but certainly >> not everyone considers it this way, and I am prepared to be persuaded > otherwise. >> >> 2. An MS object represents a given medium as contributed to by a > single participant (or by multiple >> participants that are not separately identifiable and/or where their > contributions are inseparable). >> Where different participants are contributing to the same medium, this > is represented by multiple MS >> objects. For example, in a 2-party audio-only call, there are two MS > objects. In this case, presumably >> there would need to be some mechanism for tying together those MS > objects representing the same medium >> (e.g., the two MS objects representing audio in this same example). > Possibly the name Media Stream is >> not sufficiently descriptive in this case, but I can't come up with a > better name. >> >> I think we can possibly make this basic decision, and then fill in the > details afterwards. >> >> 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 Mon May 23 10:02:17 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A190E077A for ; Mon, 23 May 2011 10:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.283 X-Spam-Level: X-Spam-Status: No, score=-10.283 tagged_above=-999 required=5 tests=[AWL=0.316, 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 w7AkhrzlQFM8 for ; Mon, 23 May 2011 10:02:16 -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 B80F2E065D for ; Mon, 23 May 2011 10:02:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=10191; q=dns/txt; s=iport; t=1306170135; x=1307379735; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=A0B7pyzSvuFIa+cF1p0PEJDRUjovf71Phu793qMYbBo=; b=BrZZxVFOMTTg4LJz8QHnj1+z9tOaYx9gh0kHGMmIwGfmJ0zb/kdH8rpt fUSO/0Iz0vjuEt2Fsk368drtn8qGMppPnM8AiKXlATa58/7/7NBIUbo1G IaUoqs9aQ1zOxXfyMByS6Hi0bwypnjHRy++zd286Y5jBKT3DF2+9ZR9Zn g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYBALiS2k1Io8UT/2dsb2JhbACXY45Cd4hwnlidOYMUgwUEhk6Ne4pF X-IronPort-AV: E=Sophos;i="4.65,257,1304294400"; d="scan'208";a="90234856" Received: from bgl-core-4.cisco.com ([72.163.197.19]) by ams-iport-1.cisco.com with ESMTP; 23 May 2011 17:02:12 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p4NH2Bhe023373; Mon, 23 May 2011 17:02:11 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, 23 May 2011 22:32: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: Mon, 23 May 2011 22:32:09 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Does MS have life outside a particular CS?(wasRE:comments on draft-ram-siprec-metadata-04) Thread-Index: AcwFuuvxdSy9/XTRSVq5DE/JiXPmDAAAgTPwAnuoqVAADSe5cAAkXwaAAUQXHCAAAoVIAAAuh9YwAAJ9VWAAGP/KIABZ8/ZQAC1UwlAAIgmvcAAEV7zg 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><07465C1D981ABC41A344374066! A E1A2C3 8 AB7A20DB @T LVMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD06480E2F@XMB-BGL-417.cisco.com><1D062974A4845E4D8A343C653804920205709791@XMB-BGL-414.cisco.com><07465C1D981ABC41A344374066AE1A2C38AC1D3CFC@TLVMBX01.nice.com><059AF07365DC474393A19A3AF187DF740716E063@NAHALD.us.int.genesyslab.com> From: "Parthasarathi R (partr)" To: "Charles Eckel (eckelcu)" , "Elwell, John" , "Henry Lum" , "Leon Portman" , "Muthu Arul Mozhi Perumal (mperumal)" , "Ram Mohan R (rmohanr)" , "Paul Kyzivat (pkyzivat)" X-OriginalArrivalTime: 23 May 2011 17:02:10.0511 (UTC) FILETIME=[27B28DF0:01CC196B] Cc: siprec@ietf.org Subject: Re: [siprec] Does MS have life outside a particular CS?(wasRE: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: Mon, 23 May 2011 17:02:17 -0000 Hi Charles, Thanks for the clarification. I agree that CSRC based solution has better recording information but only the limitation is that SRC has to acts as RTP endpoint or RTP mixer. Thanks Partha=20 -----Original Message----- From: Charles Eckel (eckelcu)=20 Sent: Monday, May 23, 2011 8:54 PM To: Parthasarathi R (partr); 'Elwell, John'; 'Henry Lum'; 'Leon Portman'; Muthu Arul Mozhi Perumal (mperumal); Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) Cc: 'siprec@ietf.org' Subject: RE: [siprec] Does MS have life outside a particular CS?(wasRE:comments on draft-ram-siprec-metadata-04) Hi Partha, Please see inline for answers to the questions you raised regarding the comments I added previously. > -----Original Message----- > From: Parthasarathi R (partr) > Sent: Sunday, May 22, 2011 4:14 PM > To: Charles Eckel (eckelcu); 'Elwell, John'; 'Henry Lum'; 'Leon=20 > Portman'; Muthu Arul Mozhi Perumal (mperumal); Ram Mohan R (rmohanr);=20 > Paul Kyzivat (pkyzivat) > Cc: 'siprec@ietf.org' > Subject: RE: [siprec] Does MS have life outside a particular=20 > CS?(wasRE:comments on draft-ram-siprec- > metadata-04) >=20 > Hi all, >=20 > Please read inline. >=20 > Thanks > Partha >=20 > -----Original Message----- > From: Charles Eckel (eckelcu) > Sent: Sunday, May 22, 2011 9:38 PM > To: Elwell, John; Henry Lum; Leon Portman; Parthasarathi R (partr);=20 > Muthu Arul Mozhi Perumal (mperumal); Ram Mohan R (rmohanr); Paul=20 > Kyzivat (pkyzivat) > Cc: siprec@ietf.org > Subject: RE: [siprec] Does MS have life outside a particular=20 > CS?(wasRE:comments on draft-ram-siprec- > metadata-04) >=20 > Hi John, >=20 > I viewed this a bit differently. Please see inline. >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > > Behalf Of Elwell, John > > Sent: Friday, May 20, 2011 12:11 AM > > To: Henry Lum; Leon Portman; Parthasarathi R (partr); Muthu Arul=20 > > Mozhi Perumal (mperumal); Ram Mohan R (rmohanr); Paul Kyzivat=20 > > (pkyzivat) > > Cc: siprec@ietf.org > > Subject: Re: [siprec] Does MS have life outside a particular=20 > > CS?(wasRE:comments on draft-ram-siprec- > > metadata-04) > > > > > > > > > > > -----Original Message----- > > > From: Henry Lum [mailto:Henry.Lum@alcatel-lucent.com] > > > Sent: 19 May 2011 19:39 > > > To: Leon Portman; Elwell, John; Parthasarathi R (partr); Muthu=20 > > > Arul Mozhi Perumal (mperumal); Ram Mohan R (rmohanr); Paul Kyzivat > > > (pkyzivat) > > > Cc: siprec@ietf.org > > > Subject: RE: [siprec] Does MS have life outside a particular=20 > > > CS?(wasRE:comments on draft-ram-siprec-metadata-04) > > > > > > I agree with John that a recording session transports recorded=20 > > > streams and are already described in the SIP session so there is=20 > > > no need to model recorded streams in the metadata model. MS in the > > > metadata model, on the other hand, explains a media stream that is > > > part a CS, and the recorded streams in the RS just refer to which=20 > > > MS in the model is actually being recorded. When we record unmixed > > > streams as a single m-line in the RS, I think we should model as=20 > > > multiple MS in the metadata model but all the MS would refer to=20 > > > the same label in the recorded stream. > > [JRE] Not sure. That might be one way of doing it. So an MS would=20 > > represent contribution to a medium (e.g., audio, main video) from a=20 > > single Participant. So for a simple 2-party audio-only call there=20 > > would be two MS objects, one for Participant 1 and one for=20 > > Participant 2. This might work, I had not > thought of it that way. >=20 > Participant linkage with MS does the same. Label attribute=20 > (media stream attribute) is one of the attribute in MS and not the=20 > only attribute. In case of format, element in participant meets > this requirement. >=20 > This is consistent with my thinking on the matter. >=20 > Certainly it doesn't align with the current metadata model, but of=20 > course that > > can be changed. One problem that would need to be addressed - how to > > tie together different MS objects that all relate to the same medium > > (e.g., audio, main video, presentation video). Perhaps they would all share the same "content" > attribute. > Please clarify more. I'm not getting the exact point here.=20 > >=20 > > > > Another way of looking at it is that an MS models a single medium in > > the CS, e.g., audio, main video, presentation video. The linkage=20 > > between an MS object and a Participant object would then point to an m-line in the SDP. >=20 > participant shall link m-line in the SDP through MS rather=20 > than direct link. It provides better abstraction. In case of only=20 > direct relationship with MS and participant to m-line using label=20 > attribute and no linkage between MS and participant, the deriving=20 > linkage between MS to participant will be tough in few scenarios.=20 > Also, Linkage between participant and MS is redundant in case linkage=20 > exists between participant and MS >=20 > To give some examples: > > > > 1. The SRC sees only mixed streams and doesn't distinguish the=20 > > participants. In other words, everything is hidden behind a=20 > > focus/mixer - it just sees the conference as a single Participant.=20 > > In this case it would be modelled as a single MS with a single=20 > > Participant. The linkage between the > sole Participant and the MS would point to the m-line. >=20 > Sounds good. >=20 > > 2. The SRC sees mixed streams but can identify different=20 > > contributing participants. In this case it would be modelled as a=20 > > single MS with multiple Participants. Each linkage between a Participant and the MS would point to the same m-line. >=20 > In both examples, Even though same number of linkage, the=20 > relationship with participant and MS needs more search with this=20 > proposal. This could be modeled in a better way >=20 > SRC could send mixed stream to SRS, in which case there would be a=20 > single m-line in the RS. SSRC for RTP stream would probably be that of > the SRC, and CSRC would indicate participants. Alternatively, the SRC=20 > could separate them out into multiple streams, either represented as a single RS m-line with different SSRC for each participant, or a different m-line for each participant. >=20 > your alternative example looks similar to unmixed streams.=20 > Please correct me if I'm wrong Yes. In this case, the SRC sees a mixed stream within the CS, and can represent it as either a single mixed stream, or one of more unmixed streams within the RS. =20 > > 3. The SRC sees unmixed streams from different contributing=20 > > participants, but mixes them itself to send to the SRS as a single=20 > > mixed stream. Modelling is > similar to case 2. >=20 > SRC could send mixed stream to SRS, in which case there would be a=20 > single m-line in the RS. SSRC for RTP stream would probably be that of the SRC, and CSRC would indicate participants. >=20 > In case of mixed stream, exact participant who contributes to > the specific timeframe is not well known. Participant information in=20 > metadata will help to understand the list of contributing sources.=20 > There is no specific requirement to look into CSRC. Please clarify in=20 > case I'm missing something. Within a mixed stream, the CSRC may be used to indicate the contributing streams. Changes to the CSRC values can be as frequent as required to indicate changes among the actual contributors.=20 Cheers, Charles > > 4. The SRC sees unmixed streams from different contributing=20 > > participants and sends them unmixed as different RTP sessions to the > > SRS. In this case it would be modelled as a single MS with multiple=20 > > Participants. Each linkage > between a Participant and the MS would point to a different m-line. >=20 > I was expecting this to be modeled as multiple different MS. The SRC=20 > would send them as multiple streams, either represented as a single RS > m-line with different SSRC for each participant, or a different m-line for each participant. >=20 > Agree with Charles. I'm seeing them as different MS >=20 > > 5. The SRC sees unmixed streams from different contributing=20 > > participants and sends them unmixed using different SSRC values in a > > single RTP session to the SRS. In this case it would be modelled as=20 > > a single MS with multiple Participants. Each linkage between a=20 > > Participant and the MS would point to > the same m-line. There would also need to be a mechanism for tying a=20 > linkage to a particular SSRC value. >=20 > In all the example, there is duplicate linkage with m-line=20 > and participant. The missing point is the linkage between participant=20 > and MS. >=20 > That would be the most lightweight and efficient way, but the SRC=20 > could alter it and represent it differently to the RS, if desired. >=20 > Cheers, > Charles >=20 > > > > > > > > When we relate a MS directly to a CS, I think it implicitly means=20 > > > that a CS owns some sort of media sources that generates media. In > > > other words, CS owns some automated participants as media sources=20 > > > but we don't explicitly model them. I am okay with this definition > > > since the SRC can choose to model this either way - meaning if=20 > > > there is need to show what the CS is doing to the media sources=20 > > > then the SRC can model a participant that generates the media to=20 > > > explain what it is. These implicit participants should terminate=20 > > > whenever the MS terminates or the CS terminates. > > [JRE] Sounds reasonable. > > > > John > > > > > > > > Henry > > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec From eckelcu@cisco.com Mon May 23 11:02: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 C180CE069E for ; Mon, 23 May 2011 11:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.464 X-Spam-Level: X-Spam-Status: No, score=-10.464 tagged_above=-999 required=5 tests=[AWL=0.135, 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 jnZjfMJH8RkV for ; Mon, 23 May 2011 11:02:09 -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 1DF62E0658 for ; Mon, 23 May 2011 11:02:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=3684; q=dns/txt; s=iport; t=1306173729; x=1307383329; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=FigM3AevSQpgeaAnTnvTzzBfHsBCFP8jWCyxRHQGcj4=; b=B1o/NvjR9r1AlG6A2UlpGXTEoF2I/cnoQVkarNM5DkflRrtSmMh+hWt6 r0LkSWq0+V89Qa6z7l1a/7HbAADlZiesADxkjPt7I4IGadD9FvD0sPEnJ axZYhgkS7GvHtL7Qb7GurvfEPdyvlhKfgM5JLrQMHB/pIGRkNed2uEgL2 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYBAHqg2k2rRDoJ/2dsb2JhbACXZY5Cd6dFnUWGGQSGUI15il0 X-IronPort-AV: E=Sophos;i="4.65,257,1304294400"; d="scan'208";a="362601187" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-2.cisco.com with ESMTP; 23 May 2011 18:02:08 +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 p4NI28D3032379 for ; Mon, 23 May 2011 18:02: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); Mon, 23 May 2011 11:02:08 -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, 23 May 2011 11:02:07 -0700 Message-ID: In-Reply-To: <4DDA89F2.50706@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] What does an MS object represent? Can we pick one of theseoptions? Thread-Index: AcwZZcGFimGccUMXQZ23lwf0fmT3zwADWICg References: <4DDA89F2.50706@cisco.com> From: "Charles Eckel (eckelcu)" To: "Paul Kyzivat (pkyzivat)" , X-OriginalArrivalTime: 23 May 2011 18:02:08.0415 (UTC) FILETIME=[883722F0:01CC1973] Subject: Re: [siprec] What does an MS object represent? Can we pick one of theseoptions? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 18:02:09 -0000 Essentially yes, though option 1 and option 2 are just two different representations of the information. I think it is really a matter of which way we think is more straightforward. If you want to be able to break out the media on a per participant basis, it is more intuitive, in my opinion, to go with option 2. Cheers, Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat (pkyzivat) > Sent: Monday, May 23, 2011 9:23 AM > To: siprec@ietf.org > Subject: Re: [siprec] What does an MS object represent? Can we pick one of theseoptions? >=20 > IIUC, option 1 can be achieved as one of the possibilities within option 2. >=20 > Thanks, > Paul >=20 > On 5/23/2011 11:53 AM, Charles Eckel (eckelcu) wrote: > > My thinking up until this point has been more aligned with option 2. > > I so see some benefit and simplification provided by option 1, but I > > think the flexibility provided by option 2 is worth the added complexity > > of representing an MS on a more granular level. > > > > Cheers, > > Charles > > > >> -----Original Message----- > >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Elwell, John > >> Sent: Monday, May 23, 2011 2:19 AM > >> To: siprec@ietf.org > >> Subject: [siprec] What does an MS object represent? Can we pick one of > > theseoptions? > >> > >> (Starting a new thread, because the previous thread ("Does MS have > > lifetime...") was getting confused > >> in its various branches.) > >> > >> I think the fundamental question at issue is what exactly an MS object > > represents. Draft-00 is > >> certainly unclear on this. I think we have been discussing two > > possibilities: > >> > >> 1. An MS object represents a given medium (e.g., audio, main video, > > presentation video, current > >> speaker video...). Different participants can contribute to this > > medium, in which case they are all > >> contributing to this single MS object. For example, in a 2-party > > audio-only CS, there is a single MS > >> object (audio) contributed to by two participants. This has been my > > way of viewing it, but certainly > >> not everyone considers it this way, and I am prepared to be persuaded > > otherwise. > >> > >> 2. An MS object represents a given medium as contributed to by a > > single participant (or by multiple > >> participants that are not separately identifiable and/or where their > > contributions are inseparable). > >> Where different participants are contributing to the same medium, this > > is represented by multiple MS > >> objects. For example, in a 2-party audio-only call, there are two MS > > objects. In this case, presumably > >> there would need to be some mechanism for tying together those MS > > objects representing the same medium > >> (e.g., the two MS objects representing audio in this same example). > > Possibly the name Media Stream is > >> not sufficiently descriptive in this case, but I can't come up with a > > better name. > >> > >> I think we can possibly make this basic decision, and then fill in the > > details afterwards. > >> > >> 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 wwwrun@ietfa.amsl.com Mon May 23 11:26:13 2011 Return-Path: X-Original-To: siprec@ietf.org Delivered-To: siprec@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id 45D7DE07AD; Mon, 23 May 2011 11:26:13 -0700 (PDT) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110523182613.45D7DE07AD@ietfa.amsl.com> Date: Mon, 23 May 2011 11:26:13 -0700 (PDT) Cc: siprec@ietf.org Subject: [siprec] SIPREC WG Virtual Interim Meeting, June 23, 2011 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 18:26:13 -0000 The SIPREC WG will hold an interim virtual meeting on: 2011-06-23, 13.00-15.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 pkyzivat@cisco.com Mon May 23 13:58: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 8F6BBE080D for ; Mon, 23 May 2011 13:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.238 X-Spam-Level: X-Spam-Status: No, score=-110.238 tagged_above=-999 required=5 tests=[AWL=0.361, 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 oLRAIAKQGjq4 for ; Mon, 23 May 2011 13:58:12 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE22E07EB for ; Mon, 23 May 2011 13:58:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=3946; q=dns/txt; s=iport; t=1306184292; x=1307393892; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=MQKfhpflYDsFmLTiVnOsKRdZnYXQ2Y2O3XGko36hsyg=; b=Xa/Hkwsk8IHNROoJiLZ66B4YRMjFWW0LMHibqC7U9M/jYx/8JAd6SWSY xjF/DMgXqr6Hfm2DFAZmqDSHpI63RGI8eGwMEH/UTcEyO8VHHTWnIP+Ie oeTZuv12b5M7Je2urzEYNs0OVX6D9dJWTZyvmYyWLcea4iek6MYMLDD4g U=; X-IronPort-AV: E=Sophos;i="4.65,258,1304294400"; d="scan'208";a="321899212" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-3.cisco.com with ESMTP; 23 May 2011 20:58:12 +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 p4NKwBi7008086; Mon, 23 May 2011 20:58:12 GMT Message-ID: <4DDACA63.3010507@cisco.com> Date: Mon, 23 May 2011 16:58:11 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Charles Eckel (eckelcu)" References: <4DDA89F2.50706@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] What does an MS object represent? Can we pick one of theseoptions? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 20:58:13 -0000 My goal here is to leave the SRC with as much flexibility as possible about how it does things. 2 provides more options than 1 does. Thanks, Paul On 5/23/2011 2:02 PM, Charles Eckel (eckelcu) wrote: > Essentially yes, though option 1 and option 2 are just two different > representations of the information. I think it is really a matter of > which way we think is more straightforward. If you want to be able to > break out the media on a per participant basis, it is more intuitive, in > my opinion, to go with option 2. > > Cheers, > Charles > > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Paul Kyzivat (pkyzivat) >> Sent: Monday, May 23, 2011 9:23 AM >> To: siprec@ietf.org >> Subject: Re: [siprec] What does an MS object represent? Can we pick > one of theseoptions? >> >> IIUC, option 1 can be achieved as one of the possibilities within > option 2. >> >> Thanks, >> Paul >> >> On 5/23/2011 11:53 AM, Charles Eckel (eckelcu) wrote: >>> My thinking up until this point has been more aligned with option 2. >>> I so see some benefit and simplification provided by option 1, but I >>> think the flexibility provided by option 2 is worth the added > complexity >>> of representing an MS on a more granular level. >>> >>> Cheers, >>> Charles >>> >>>> -----Original Message----- >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>> Behalf Of Elwell, John >>>> Sent: Monday, May 23, 2011 2:19 AM >>>> To: siprec@ietf.org >>>> Subject: [siprec] What does an MS object represent? Can we pick one > of >>> theseoptions? >>>> >>>> (Starting a new thread, because the previous thread ("Does MS have >>> lifetime...") was getting confused >>>> in its various branches.) >>>> >>>> I think the fundamental question at issue is what exactly an MS > object >>> represents. Draft-00 is >>>> certainly unclear on this. I think we have been discussing two >>> possibilities: >>>> >>>> 1. An MS object represents a given medium (e.g., audio, main video, >>> presentation video, current >>>> speaker video...). Different participants can contribute to this >>> medium, in which case they are all >>>> contributing to this single MS object. For example, in a 2-party >>> audio-only CS, there is a single MS >>>> object (audio) contributed to by two participants. This has been my >>> way of viewing it, but certainly >>>> not everyone considers it this way, and I am prepared to be > persuaded >>> otherwise. >>>> >>>> 2. An MS object represents a given medium as contributed to by a >>> single participant (or by multiple >>>> participants that are not separately identifiable and/or where > their >>> contributions are inseparable). >>>> Where different participants are contributing to the same medium, > this >>> is represented by multiple MS >>>> objects. For example, in a 2-party audio-only call, there are two > MS >>> objects. In this case, presumably >>>> there would need to be some mechanism for tying together those MS >>> objects representing the same medium >>>> (e.g., the two MS objects representing audio in this same example). >>> Possibly the name Media Stream is >>>> not sufficiently descriptive in this case, but I can't come up with > a >>> better name. >>>> >>>> I think we can possibly make this basic decision, and then fill in > the >>> details afterwards. >>>> >>>> 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 Mon May 23 21:00:29 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F056AE0677 for ; Mon, 23 May 2011 21:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.312 X-Spam-Level: X-Spam-Status: No, score=-10.312 tagged_above=-999 required=5 tests=[AWL=0.287, 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 dIdtoU5z0i6Y for ; Mon, 23 May 2011 21:00:29 -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 6D1BCE062B for ; Mon, 23 May 2011 21:00:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=6047; q=dns/txt; s=iport; t=1306209628; x=1307419228; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=G67sHvU21dETlxNwTnCT4PspFDo8TsleW6naYiqZjao=; b=CoMEuZDOOODY6f6KbSj1DNHTR1gwVpNshpMCkqNduuWTO4xnb7Su6VY5 opz+h1usIpTdZGSqCpkBXd5ke+ZBaQQcKLzz7EVmEHcf73oB0kikTMj6X h2DCWbcYosw/u54UqMwY5gdAI8jWGR0Vb3RzzBCw57fc6WLqFHXEGEETB 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoBAEMs201Io8US/2dsb2JhbACXYI5Dd4hwokGeBYYZBIZTjgSKSA X-IronPort-AV: E=Sophos;i="4.65,259,1304294400"; d="scan'208";a="90307898" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-1.cisco.com with ESMTP; 24 May 2011 04:00:26 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p4O40IIu020304 for ; Tue, 24 May 2011 04:00:25 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, 24 May 2011 09:30:19 +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, 24 May 2011 09:30:19 +0530 Message-ID: In-Reply-To: <4DDACA63.3010507@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] What does an MS object represent? Can we pick one of theseoptions? Thread-Index: AcwZjEMdxsU1ku7RShyAfgLHhq8tdQAOmjtA References: <4DDA89F2.50706@cisco.com> <4DDACA63.3010507@cisco.com> From: "Parthasarathi R (partr)" To: "Paul Kyzivat (pkyzivat)" , "Charles Eckel (eckelcu)" X-OriginalArrivalTime: 24 May 2011 04:00:19.0427 (UTC) FILETIME=[18ECF330:01CC19C7] Cc: siprec@ietf.org Subject: Re: [siprec] What does an MS object represent? Can we pick one of theseoptions? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 04:00:30 -0000 I agree with Paul & Charles for using option 2 because option 1 is a the subset of option 2. Adding to their point, I'll provide my understanding of Media stream object as follows: Each Media stream object has metadata information about one recorded RTP stream and its related media specific information. For the sake easy understanding, I'm writing Media stream object in terms of format. Media stream object shall be visualized in the format as follows:=20 1) Start & Stop time attribute for the specific media stream. This will be represented as Metadata XML attribute 2) Media reference ("label") attribute has the linkage between RS SDP m-line and Media stream element in XML 3) Codec parameters shall refer to RS SDP codec specific attributes. In the current model, each metadata object shall be mapped to one of the m-line in RS SDP. How RS SDP m-line is mapped to CS-SDP m-line based on SRC deployment.=20 General MS object mechanism: 1) Each MS shall be contributed by multiple participant or single participant.=20 2) Each MS lifetime related to CSG because participant may move from one CS to another CS within single CSG and also CSG will span across multiple RS.=20 Please read inline for more comments. Thanks Partha=20 -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat (pkyzivat) Sent: Tuesday, May 24, 2011 2:28 AM To: Charles Eckel (eckelcu) Cc: siprec@ietf.org Subject: Re: [siprec] What does an MS object represent? Can we pick one of theseoptions? My goal here is to leave the SRC with as much flexibility as possible about how it does things. 2 provides more options than 1 does. Thanks, Paul On 5/23/2011 2:02 PM, Charles Eckel (eckelcu) wrote: > Essentially yes, though option 1 and option 2 are just two different=20 > representations of the information. I think it is really a matter of=20 > which way we think is more straightforward. If you want to be able to=20 > break out the media on a per participant basis, it is more intuitive,=20 > in my opinion, to go with option 2. > > Cheers, > Charles > > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Paul Kyzivat (pkyzivat) >> Sent: Monday, May 23, 2011 9:23 AM >> To: siprec@ietf.org >> Subject: Re: [siprec] What does an MS object represent? Can we pick > one of theseoptions? >> >> IIUC, option 1 can be achieved as one of the possibilities within > option 2. >> >> Thanks, >> Paul >> >> On 5/23/2011 11:53 AM, Charles Eckel (eckelcu) wrote: >>> My thinking up until this point has been more aligned with option 2. >>> I so see some benefit and simplification provided by option 1, but I >>> think the flexibility provided by option 2 is worth the added > complexity >>> of representing an MS on a more granular level. >>> >>> Cheers, >>> Charles >>> >>>> -----Original Message----- >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>> Behalf Of Elwell, John >>>> Sent: Monday, May 23, 2011 2:19 AM >>>> To: siprec@ietf.org >>>> Subject: [siprec] What does an MS object represent? Can we pick one > of >>> theseoptions? >>>> >>>> (Starting a new thread, because the previous thread ("Does MS have >>> lifetime...") was getting confused >>>> in its various branches.) >>>> >>>> I think the fundamental question at issue is what exactly an MS > object >>> represents. Draft-00 is >>>> certainly unclear on this. I think we have been discussing two >>> possibilities: >>>> >>>> 1. An MS object represents a given medium (e.g., audio, main video, >>> presentation video, current >>>> speaker video...). Different participants can contribute to this >>> medium, in which case they are all >>>> contributing to this single MS object. For example, in a 2-party >>> audio-only CS, there is a single MS >>>> object (audio) contributed to by two participants. This has been my >>> way of viewing it, but certainly >>>> not everyone considers it this way, and I am prepared to be > persuaded >>> otherwise. >>>> This may be achieved in some scenario but not always because multiple contributing participant within single RTP stream is not possible for SRC which are acting as RTP translator. >>>> 2. An MS object represents a given medium as contributed to by a >>> single participant (or by multiple >>>> participants that are not separately identifiable and/or where > their >>> contributions are inseparable). >>>> Where different participants are contributing to the same medium, > this >>> is represented by multiple MS >>>> objects. For example, in a 2-party audio-only call, there are two > MS >>> objects. In this case, presumably >>>> there would need to be some mechanism for tying together those MS >>> objects representing the same medium >>>> (e.g., the two MS objects representing audio in this same example). >>> Possibly the name Media Stream is >>>> not sufficiently descriptive in this case, but I can't come up with > a >>> better name. Even though both MS object representing audio, Metadata information like MS helps to understand the real relationship with participant & CS >>>> >>>> I think we can possibly make this basic decision, and then fill in > the >>> details afterwards. >>>> >>>> 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 Mon May 23 23: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 CB256E0662 for ; Mon, 23 May 2011 23:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.454 X-Spam-Level: X-Spam-Status: No, score=-107.454 tagged_above=-999 required=5 tests=[AWL=1.144, BAYES_00=-2.599, GB_I_INVITATION=-2, 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 hoNRpOWLxCrv for ; Mon, 23 May 2011 23:47:52 -0700 (PDT) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfa.amsl.com (Postfix) with SMTP id 67076E06B2 for ; Mon, 23 May 2011 23:47:51 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1306219664!40052043!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 12526 invoked from network); 24 May 2011 06:47:44 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-8.tower-27.messagelabs.com with SMTP; 24 May 2011 06:47:44 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id EBA2023F03E6 for ; Tue, 24 May 2011 08:47:49 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 24 May 2011 08:47:49 +0200 From: "Elwell, John" To: "siprec@ietf.org" Date: Tue, 24 May 2011 08:47:48 +0200 Thread-Topic: Meeting invitation for interim 2011-06-23 13.00-15.00 GMT Thread-Index: AcwZdVZRZWNFTfFgTgyNuW5ns6HTvQAaMepA Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A444A0F8084434499206E78C106220CA089BE68759MCHP058Agloba_" MIME-Version: 1.0 Subject: [siprec] Meeting invitation for interim 2011-06-23 13.00-15.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: Tue, 24 May 2011 06:47:52 -0000 --_000_A444A0F8084434499206E78C106220CA089BE68759MCHP058Agloba_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ________________________________ From: IETF Secretariat [mailto:messenger@webex.com] Sent: 23 May 2011 19:15 To: Elwell, John Subject: Meeting invitation: SIPREC Hello , IETF Secretariat invites you to attend this online meeting. Topic: SIPREC Date: Thursday, June 23, 2011 Time: 6:00 am, Pacific Daylight Time (San Francisco, GMT-07:00) Meeting Number: 968 609 328 Meeting Password: (This meeting does not require a password.) ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://workgreen.webex.com/workgreen/j.php?ED=3D153455152&UID=3D1= 213223202&RT=3DMiM0 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: (This meeting doe= s not require a password.) 4. Click "Join". To view in other time zones or languages, please click the link: https://workgreen.webex.com/workgreen/j.php?ED=3D153455152&UID=3D1213223202= &ORT=3DMiM0 ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting= , or call the number below and enter the access code. Call-in toll number (US/Canada): 1-408-792-6300 Global call-in numbers: https://workgreen.webex.com/workgreen/globalcallin.= php?serviceType=3DMC&ED=3D153455152&tollFree=3D0 Access code:968 609 328 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://workgreen.webex.com/workgreen/mc 2. On the left navigation bar, click "Support". You can contact me at: amorris@amsl.com 1-510-492-4081 To add this meeting to your calendar program (for example Microsoft Outlook= ), click this link: https://workgreen.webex.com/workgreen/j.php?ED=3D153455152&UID=3D1213223202= &ICS=3DMI&LD=3D1&RD=3D2&ST=3D1&SHA2=3DLPf9VhQCwsopjc9YJMqSmsVEPkGtoXT9-i3bR= m5ngM4=3D&RT=3DMiM0 The playback of UCF (Universal Communications Format) rich media files requ= ires appropriate players. To view this type of rich media files in the meet= ing, please check whether you have the players installed on your computer b= y going to https://workgreen.webex.com/workgreen/systemdiagnosis.php Sign up for a free trial of WebEx http://www.webex.com/go/mcemfreetrial http://www.webex.com CCP:+14087926300x968609328# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns = with the meeting host prior to the start of the recording or do not join th= e session. Please note that any such recordings may be subject to discovery= in the event of litigation. --_000_A444A0F8084434499206E78C106220CA089BE68759MCHP058Agloba_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 

From: IETF Secretariat=20 [mailto:messenger@webex.com]
Sent: 23 May 2011 19:15
To:= =20 Elwell, John
Subject: Meeting invitation:=20 SIPREC


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

Topic: SIP= REC=20
Date: Thursday, June 23, 2011
Time: 6:00 am, Pacific Daylight Tim= e=20 (San Francisco, GMT-07:00)
Meeting Number: 968 609 328
Meeting=20 Password: (This meeting does not require a password.)=20


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

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

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

Access code:968 609 328=20

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

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

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

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

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

http://www.webex.com=20

CCP:+14087926300x968609328#

IMPORTANT NOTICE: This WebEx= =20 service includes a feature that allows audio and any documents and other= =20 materials exchanged or viewed during the session to be recorded. By joini= ng=20 this session, you automatically consent to such recordings. If you do not= =20 consent to the recording, discuss your concerns with the meeting host pri= or to=20 the start of the recording or do not join the session. Please note that a= ny=20 such recordings may be subject to discovery in the event of litigation.=20
--_000_A444A0F8084434499206E78C106220CA089BE68759MCHP058Agloba_-- From john.elwell@siemens-enterprise.com Tue May 24 00:35:11 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9778E06B6 for ; Tue, 24 May 2011 00:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.494 X-Spam-Level: X-Spam-Status: No, score=-106.494 tagged_above=-999 required=5 tests=[AWL=0.105, 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 hr50J+Rd52rC for ; Tue, 24 May 2011 00:35:11 -0700 (PDT) Received: from mail216.messagelabs.com (mail216.messagelabs.com [85.158.143.99]) by ietfa.amsl.com (Postfix) with SMTP id 90C2DE06CE for ; Tue, 24 May 2011 00:35:10 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-14.tower-216.messagelabs.com!1306222509!5895310!1 X-StarScan-Version: 6.2.16; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 9129 invoked from network); 24 May 2011 07:35:09 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-14.tower-216.messagelabs.com with SMTP; 24 May 2011 07:35:09 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 340CD23F03E6; Tue, 24 May 2011 09:35:09 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 24 May 2011 09:35:09 +0200 From: "Elwell, John" To: "Parthasarathi R (partr)" , "Paul Kyzivat (pkyzivat)" , "Charles Eckel (eckelcu)" Date: Tue, 24 May 2011 09:35:07 +0200 Thread-Topic: [siprec] What does an MS object represent? Can we pick one of theseoptions? Thread-Index: AcwZjEMdxsU1ku7RShyAfgLHhq8tdQAOmjtAAAbBovA= Message-ID: References: <4DDA89F2.50706@cisco.com> <4DDACA63.3010507@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] What does an MS object represent? Can we pick one of theseoptions? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 07:35:12 -0000 So those who have responded prefer option 2, and therefore I can agree to t= hat. Essentially a Media Stream object models a recorded media stream. This= should be made clear in the description of this object class in the model = draft. A recorded media stream can be contributed to by one, several or all Partic= ipants. If there are two recorded media streams relating to the same medium= , there should be a means within the model to tie the two together. For exa= mple, in a 2-party audio call where there is one recorded media stream per = direction, the two should somehow be indicated as related (e.g, by having a= common value of a "content" attribute). I am not sure I agree with Partha's further point about CSG. I will reply s= eparately on that. John (as individual) > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi R (partr) > Sent: 24 May 2011 05:00 > To: Paul Kyzivat (pkyzivat); Charles Eckel (eckelcu) > Cc: siprec@ietf.org > Subject: Re: [siprec] What does an MS object represent? Can=20 > we pick one of theseoptions? >=20 > I agree with Paul & Charles for using option 2 because option=20 > 1 is a the > subset of option 2. >=20 > Adding to their point, I'll provide my understanding of Media stream > object as follows: >=20 > Each Media stream object has metadata information about one=20 > recorded RTP > stream and its related media specific information. For the sake easy > understanding, I'm writing Media stream object in terms of=20 > format. Media > stream object shall be visualized in the format as follows:=20 >=20 > 1) Start & Stop time attribute for the specific media stream.=20 > This will > be represented as Metadata XML attribute > 2) Media reference ("label") attribute has the linkage between RS SDP > m-line and Media stream element in XML > 3) Codec parameters shall refer to RS SDP codec specific attributes. >=20 > In the current model, each metadata object shall be mapped to=20 > one of the > m-line in RS SDP. How RS SDP m-line is mapped to CS-SDP=20 > m-line based on > SRC deployment.=20 >=20 > General MS object mechanism: > 1) Each MS shall be contributed by multiple participant or single > participant.=20 > 2) Each MS lifetime related to CSG because participant may=20 > move from one > CS to another CS within single CSG and also CSG will span across > multiple RS.=20 >=20 > Please read inline for more comments. >=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: Tuesday, May 24, 2011 2:28 AM > To: Charles Eckel (eckelcu) > Cc: siprec@ietf.org > Subject: Re: [siprec] What does an MS object represent? Can=20 > we pick one > of theseoptions? >=20 > My goal here is to leave the SRC with as much flexibility as possible > about how it does things. 2 provides more options than 1 does. >=20 > Thanks, > Paul >=20 > On 5/23/2011 2:02 PM, Charles Eckel (eckelcu) wrote: > > Essentially yes, though option 1 and option 2 are just two=20 > different=20 > > representations of the information. I think it is really a=20 > matter of=20 > > which way we think is more straightforward. If you want to=20 > be able to=20 > > break out the media on a per participant basis, it is more=20 > intuitive,=20 > > in my opinion, to go with option 2. > > > > Cheers, > > Charles > > > > > >> -----Original Message----- > >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Paul Kyzivat (pkyzivat) > >> Sent: Monday, May 23, 2011 9:23 AM > >> To: siprec@ietf.org > >> Subject: Re: [siprec] What does an MS object represent? Can we pick > > one of theseoptions? > >> > >> IIUC, option 1 can be achieved as one of the possibilities within > > option 2. > >> > >> Thanks, > >> Paul > >> > >> On 5/23/2011 11:53 AM, Charles Eckel (eckelcu) wrote: > >>> My thinking up until this point has been more aligned=20 > with option 2. > >>> I so see some benefit and simplification provided by=20 > option 1, but I >=20 > >>> think the flexibility provided by option 2 is worth the added > > complexity > >>> of representing an MS on a more granular level. > >>> > >>> Cheers, > >>> Charles > >>> > >>>> -----Original Message----- > >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >>> Behalf Of Elwell, John > >>>> Sent: Monday, May 23, 2011 2:19 AM > >>>> To: siprec@ietf.org > >>>> Subject: [siprec] What does an MS object represent? Can=20 > we pick one > > of > >>> theseoptions? > >>>> > >>>> (Starting a new thread, because the previous thread=20 > ("Does MS have > >>> lifetime...") was getting confused > >>>> in its various branches.) > >>>> > >>>> I think the fundamental question at issue is what exactly an MS > > object > >>> represents. Draft-00 is > >>>> certainly unclear on this. I think we have been discussing two > >>> possibilities: > >>>> > >>>> 1. An MS object represents a given medium (e.g., audio,=20 > main video, > >>> presentation video, current > >>>> speaker video...). Different participants can contribute to this > >>> medium, in which case they are all > >>>> contributing to this single MS object. For example, in a 2-party > >>> audio-only CS, there is a single MS > >>>> object (audio) contributed to by two participants. This=20 > has been my > >>> way of viewing it, but certainly > >>>> not everyone considers it this way, and I am prepared to be > > persuaded > >>> otherwise. > >>>> > This may be achieved in some scenario but not always because > multiple contributing participant within single RTP stream is not > possible for SRC which are acting as RTP translator. >=20 > >>>> 2. An MS object represents a given medium as contributed to by a > >>> single participant (or by multiple > >>>> participants that are not separately identifiable and/or where > > their > >>> contributions are inseparable). > >>>> Where different participants are contributing to the same medium, > > this > >>> is represented by multiple MS > >>>> objects. For example, in a 2-party audio-only call, there are two > > MS > >>> objects. In this case, presumably > >>>> there would need to be some mechanism for tying together those MS > >>> objects representing the same medium > >>>> (e.g., the two MS objects representing audio in this=20 > same example). > >>> Possibly the name Media Stream is > >>>> not sufficiently descriptive in this case, but I can't=20 > come up with > > a > >>> better name. >=20 > Even though both MS object representing audio, Metadata > information like MS helps to understand the real relationship with > participant & CS >=20 > >>>> > >>>> I think we can possibly make this basic decision, and=20 > then fill in > > the > >>> details afterwards. > >>>> > >>>> 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 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > = From john.elwell@siemens-enterprise.com Tue May 24 00:36:24 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 5965CE06D4 for ; Tue, 24 May 2011 00:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.497 X-Spam-Level: X-Spam-Status: No, score=-106.497 tagged_above=-999 required=5 tests=[AWL=0.102, 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 VVsldX6CrMmc for ; Tue, 24 May 2011 00:36:23 -0700 (PDT) Received: from mail182.messagelabs.com (mail182.messagelabs.com [85.158.139.83]) by ietfa.amsl.com (Postfix) with SMTP id 71216E06CE for ; Tue, 24 May 2011 00:36:23 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-12.tower-182.messagelabs.com!1306222582!7609505!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 25299 invoked from network); 24 May 2011 07:36:22 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-12.tower-182.messagelabs.com with SMTP; 24 May 2011 07:36:22 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 315131EB83D3 for ; Tue, 24 May 2011 09:36:22 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 24 May 2011 09:36:22 +0200 From: "Elwell, John" To: "siprec@ietf.org" Date: Tue, 24 May 2011 09:36:21 +0200 Thread-Topic: Can an MS object span several CSs in a CSG? Thread-Index: AcwZ5UbR730mQiXZRGSqd4Xx2cnzHg== 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] Can an MS object span several CSs in a CSG? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 07:36:24 -0000 We seem to have consensus that a Media Stream object represents a recorded = media stream, contributed to by one, several or all Participants. However, = Partha also wrote: "2) Each MS lifetime related to CSG because participant may move from one CS to another CS within single CSG and also CSG will span across multiple RS." I am not sure we had resolved this during earlier discussions on the scope = of an MS object. Although the same Participant can participate in several C= Ss within the same CSG, I don't think the recorded media streams need to be= considered the same. Any other views? John (as individual)= From partr@cisco.com Tue May 24 04:26:42 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 60BADE071E for ; Tue, 24 May 2011 04:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.336 X-Spam-Level: X-Spam-Status: No, score=-10.336 tagged_above=-999 required=5 tests=[AWL=0.263, 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 BZ6O5ZjDT4DF for ; Tue, 24 May 2011 04:26:41 -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 00417E0711 for ; Tue, 24 May 2011 04:26:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=1273; q=dns/txt; s=iport; t=1306236401; x=1307446001; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=WKJTFFRoLgJfFZ1BeQ7yfPMx8qySBPKgeg7kNmZ+JNA=; b=P9nQ+6JYE3zs4TB7s01ZsXyd9uGIL8HcqJy2bRg8SiDg/YZH/rKK0m/8 saxXn3UaVs4KvCA19avM26OxIYAb4L98EugmT9h316UBCAlIrlZTuEw1C FT3hw48DggmyBmAdy0AG6BogL/IKIM/X1X4WsV12DVs92KBr0u/2pwwRh w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYBAKaV201Io8UT/2dsb2JhbACXYo5Ed6tanX+GGwSGVI4Iikw X-IronPort-AV: E=Sophos;i="4.65,261,1304294400"; d="scan'208";a="90402774" Received: from bgl-core-4.cisco.com ([72.163.197.19]) by ams-iport-1.cisco.com with ESMTP; 24 May 2011 11:26:38 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p4OBQGut022708; Tue, 24 May 2011 11:26:16 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, 24 May 2011 16:56:16 +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, 24 May 2011 16:56:15 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Can an MS object span several CSs in a CSG? Thread-Index: AcwZ5UbR730mQiXZRGSqd4Xx2cnzHgAHpFKQ References: From: "Parthasarathi R (partr)" To: "Elwell, John" , X-OriginalArrivalTime: 24 May 2011 11:26:16.0121 (UTC) FILETIME=[65287290:01CC1A05] Subject: Re: [siprec] Can an MS object span several CSs in a CSG? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 11:26:42 -0000 John, I agree that it is not mandatory to consider recorded stream of a specific participant in several CS within the same CSG as one recorded stream but SIPREC protocol design MUST NOT restrict a SRC in case it wishes to design in such a way. Thanks Partha=20 -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John Sent: Tuesday, May 24, 2011 1:06 PM To: siprec@ietf.org Subject: [siprec] Can an MS object span several CSs in a CSG? We seem to have consensus that a Media Stream object represents a recorded media stream, contributed to by one, several or all Participants. However, Partha also wrote: "2) Each MS lifetime related to CSG because participant may move from one CS to another CS within single CSG and also CSG will span across multiple RS." I am not sure we had resolved this during earlier discussions on the scope of an MS object. Although the same Participant can participate in several CSs within the same CSG, I don't think the recorded media streams need to be considered the same. Any other views? John (as individual) _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From pkyzivat@cisco.com Tue May 24 05:57:05 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 B9829E0742 for ; Tue, 24 May 2011 05:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.242 X-Spam-Level: X-Spam-Status: No, score=-110.242 tagged_above=-999 required=5 tests=[AWL=0.357, 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 Jk5HKjn+ybvv for ; Tue, 24 May 2011 05:57:04 -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 C88C7E0738 for ; Tue, 24 May 2011 05:57:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=8885; q=dns/txt; s=iport; t=1306241824; x=1307451424; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=VZs1yyDk5Kb+NJkfmuxwE3pQZK/tnXzKE+sXI1lt2+4=; b=l4+TygXS5ej13wtIqKi650klyh5h6pHu2sIztZX2SjKfZXP1zofRKscM U5+pzvumQbB60x4QvxpnFUt0KLDOQ+hsZqG4lXMNU5W/gyeh8YnWXuxgk gf/cW2EpLZDPVF2sWFOkhdmmYeHNNLtpRvBDREopH6rpiwzDKDmmYQDxJ o=; X-IronPort-AV: E=Sophos;i="4.65,261,1304294400"; d="scan'208";a="702403038" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-6.cisco.com with ESMTP; 24 May 2011 12:57:04 +0000 Received: from [161.44.174.124] (dhcp-161-44-174-124.cisco.com [161.44.174.124]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p4OCv3dp021298; Tue, 24 May 2011 12:57:04 GMT Message-ID: <4DDBAB1F.8090505@cisco.com> Date: Tue, 24 May 2011 08:57:03 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Elwell, John" References: <4DDA89F2.50706@cisco.com> <4DDACA63.3010507@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] What does an MS object represent? Can we pick one of theseoptions? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 12:57:05 -0000 On 5/24/2011 3:35 AM, Elwell, John wrote: > So those who have responded prefer option 2, and therefore I can agree to that. Essentially a Media Stream object models a recorded media stream. This should be made clear in the description of this object class in the model draft. Fair enough > A recorded media stream can be contributed to by one, several or all Participants. If there are two recorded media streams relating to the same medium, there should be a means within the model to tie the two together. For example, in a 2-party audio call where there is one recorded media stream per direction, the two should somehow be indicated as related (e.g, by having a common value of a "content" attribute). While your example is a place where tying is perhaps important, I don't think the criteria for doing so is that they are the "same medium", at least not the way I think of medium. AFAIK two streams would be considered "the same medium" if they are both video, or both voice. But not all such things should be tied together, at least not in the same way. The matched pair of streams, one in each direction, between a pair of participants, that carries the two sides of a conversation, is a special relationship. And I agree that we currently seem to lack a way to represent that. We could also have multiple streams of the same medium in a CS - for instance carrying multiple streams of video. That is a different relationship. It could be a lot of work to figure out all the relationships that might need to be represented. I would suggest leaving most of that out of scope for now to avoid a rat hole. But we probably do need to describe the pairing of the two sides of a single conversation. Thanks, Paul > I am not sure I agree with Partha's further point about CSG. I will reply separately on that. > > John (as individual) > >> -----Original Message----- >> From: siprec-bounces@ietf.org >> [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi R (partr) >> Sent: 24 May 2011 05:00 >> To: Paul Kyzivat (pkyzivat); Charles Eckel (eckelcu) >> Cc: siprec@ietf.org >> Subject: Re: [siprec] What does an MS object represent? Can >> we pick one of theseoptions? >> >> I agree with Paul& Charles for using option 2 because option >> 1 is a the >> subset of option 2. >> >> Adding to their point, I'll provide my understanding of Media stream >> object as follows: >> >> Each Media stream object has metadata information about one >> recorded RTP >> stream and its related media specific information. For the sake easy >> understanding, I'm writing Media stream object in terms of >> format. Media >> stream object shall be visualized in the format as follows: >> >> 1) Start& Stop time attribute for the specific media stream. >> This will >> be represented as Metadata XML attribute >> 2) Media reference ("label") attribute has the linkage between RS SDP >> m-line and Media stream element in XML >> 3) Codec parameters shall refer to RS SDP codec specific attributes. >> >> In the current model, each metadata object shall be mapped to >> one of the >> m-line in RS SDP. How RS SDP m-line is mapped to CS-SDP >> m-line based on >> SRC deployment. >> >> General MS object mechanism: >> 1) Each MS shall be contributed by multiple participant or single >> participant. >> 2) Each MS lifetime related to CSG because participant may >> move from one >> CS to another CS within single CSG and also CSG will span across >> multiple RS. >> >> Please read inline for more comments. >> >> Thanks >> Partha >> >> -----Original Message----- >> From: siprec-bounces@ietf.org >> [mailto:siprec-bounces@ietf.org] On Behalf >> Of Paul Kyzivat (pkyzivat) >> Sent: Tuesday, May 24, 2011 2:28 AM >> To: Charles Eckel (eckelcu) >> Cc: siprec@ietf.org >> Subject: Re: [siprec] What does an MS object represent? Can >> we pick one >> of theseoptions? >> >> My goal here is to leave the SRC with as much flexibility as possible >> about how it does things. 2 provides more options than 1 does. >> >> Thanks, >> Paul >> >> On 5/23/2011 2:02 PM, Charles Eckel (eckelcu) wrote: >>> Essentially yes, though option 1 and option 2 are just two >> different >>> representations of the information. I think it is really a >> matter of >>> which way we think is more straightforward. If you want to >> be able to >>> break out the media on a per participant basis, it is more >> intuitive, >>> in my opinion, to go with option 2. >>> >>> Cheers, >>> Charles >>> >>> >>>> -----Original Message----- >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>> Behalf Of Paul Kyzivat (pkyzivat) >>>> Sent: Monday, May 23, 2011 9:23 AM >>>> To: siprec@ietf.org >>>> Subject: Re: [siprec] What does an MS object represent? Can we pick >>> one of theseoptions? >>>> >>>> IIUC, option 1 can be achieved as one of the possibilities within >>> option 2. >>>> >>>> Thanks, >>>> Paul >>>> >>>> On 5/23/2011 11:53 AM, Charles Eckel (eckelcu) wrote: >>>>> My thinking up until this point has been more aligned >> with option 2. >>>>> I so see some benefit and simplification provided by >> option 1, but I >> >>>>> think the flexibility provided by option 2 is worth the added >>> complexity >>>>> of representing an MS on a more granular level. >>>>> >>>>> Cheers, >>>>> Charles >>>>> >>>>>> -----Original Message----- >>>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>>>> Behalf Of Elwell, John >>>>>> Sent: Monday, May 23, 2011 2:19 AM >>>>>> To: siprec@ietf.org >>>>>> Subject: [siprec] What does an MS object represent? Can >> we pick one >>> of >>>>> theseoptions? >>>>>> >>>>>> (Starting a new thread, because the previous thread >> ("Does MS have >>>>> lifetime...") was getting confused >>>>>> in its various branches.) >>>>>> >>>>>> I think the fundamental question at issue is what exactly an MS >>> object >>>>> represents. Draft-00 is >>>>>> certainly unclear on this. I think we have been discussing two >>>>> possibilities: >>>>>> >>>>>> 1. An MS object represents a given medium (e.g., audio, >> main video, >>>>> presentation video, current >>>>>> speaker video...). Different participants can contribute to this >>>>> medium, in which case they are all >>>>>> contributing to this single MS object. For example, in a 2-party >>>>> audio-only CS, there is a single MS >>>>>> object (audio) contributed to by two participants. This >> has been my >>>>> way of viewing it, but certainly >>>>>> not everyone considers it this way, and I am prepared to be >>> persuaded >>>>> otherwise. >>>>>> >> This may be achieved in some scenario but not always because >> multiple contributing participant within single RTP stream is not >> possible for SRC which are acting as RTP translator. >> >>>>>> 2. An MS object represents a given medium as contributed to by a >>>>> single participant (or by multiple >>>>>> participants that are not separately identifiable and/or where >>> their >>>>> contributions are inseparable). >>>>>> Where different participants are contributing to the same medium, >>> this >>>>> is represented by multiple MS >>>>>> objects. For example, in a 2-party audio-only call, there are two >>> MS >>>>> objects. In this case, presumably >>>>>> there would need to be some mechanism for tying together those MS >>>>> objects representing the same medium >>>>>> (e.g., the two MS objects representing audio in this >> same example). >>>>> Possibly the name Media Stream is >>>>>> not sufficiently descriptive in this case, but I can't >> come up with >>> a >>>>> better name. >> >> Even though both MS object representing audio, Metadata >> information like MS helps to understand the real relationship with >> participant& CS >> >>>>>> >>>>>> I think we can possibly make this basic decision, and >> then fill in >>> the >>>>> details afterwards. >>>>>> >>>>>> 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 >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >> From john.elwell@siemens-enterprise.com Tue May 24 06:17:40 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEAD8E0743 for ; Tue, 24 May 2011 06:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.501 X-Spam-Level: X-Spam-Status: No, score=-106.501 tagged_above=-999 required=5 tests=[AWL=0.098, 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 kJOzK9HJ1VLP for ; Tue, 24 May 2011 06:17:39 -0700 (PDT) Received: from mail216.messagelabs.com (mail216.messagelabs.com [85.158.143.99]) by ietfa.amsl.com (Postfix) with SMTP id 3066AE0746 for ; Tue, 24 May 2011 06:17:39 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-14.tower-216.messagelabs.com!1306243057!5943886!1 X-StarScan-Version: 6.2.16; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 785 invoked from network); 24 May 2011 13:17:37 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-14.tower-216.messagelabs.com with SMTP; 24 May 2011 13:17:37 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 6BA5B23F03E8; Tue, 24 May 2011 15:17: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, 24 May 2011 15:17:37 +0200 From: "Elwell, John" To: Paul Kyzivat Date: Tue, 24 May 2011 15:17:34 +0200 Thread-Topic: [siprec] What does an MS object represent? Can we pick one of theseoptions? Thread-Index: AcwaEha5oibxkgCWR8yhZUd/6Q2vWQAAnU/w Message-ID: References: <4DDA89F2.50706@cisco.com> <4DDACA63.3010507@cisco.com> <4DDBAB1F.8090505@cisco.com> In-Reply-To: <4DDBAB1F.8090505@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] What does an MS object represent? Can we pick one of theseoptions? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 13:17:40 -0000 =20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: 24 May 2011 13:57 > To: Elwell, John > Cc: Parthasarathi R (partr); Charles Eckel (eckelcu); siprec@ietf.org > Subject: Re: [siprec] What does an MS object represent? Can=20 > we pick one of theseoptions? >=20 >=20 >=20 > On 5/24/2011 3:35 AM, Elwell, John wrote: > > So those who have responded prefer option 2, and therefore=20 > I can agree to that. Essentially a Media Stream object models=20 > a recorded media stream. This should be made clear in the=20 > description of this object class in the model draft. >=20 > Fair enough >=20 > > A recorded media stream can be contributed to by one,=20 > several or all Participants. If there are two recorded media=20 > streams relating to the same medium, there should be a means=20 > within the model to tie the two together. For example, in a=20 > 2-party audio call where there is one recorded media stream=20 > per direction, the two should somehow be indicated as related=20 > (e.g, by having a common value of a "content" attribute). >=20 > While your example is a place where tying is perhaps=20 > important, I don't=20 > think the criteria for doing so is that they are the "same=20 > medium", at=20 > least not the way I think of medium. >=20 > AFAIK two streams would be considered "the same medium" if=20 > they are both=20 > video, or both voice. But not all such things should be tied=20 > together,=20 > at least not in the same way. >=20 > The matched pair of streams, one in each direction, between a pair of=20 > participants, that carries the two sides of a conversation,=20 > is a special=20 > relationship. And I agree that we currently seem to lack a way to=20 > represent that. >=20 > We could also have multiple streams of the same medium in a CS - for=20 > instance carrying multiple streams of video. That is a different=20 > relationship. >=20 > It could be a lot of work to figure out all the relationships=20 > that might=20 > need to be represented. I would suggest leaving most of that out of=20 > scope for now to avoid a rat hole. But we probably do need to=20 > describe=20 > the pairing of the two sides of a single conversation. [JRE] Yes and no. I had considered things like main video, presentation vid= eo, current speaker video as being different media (albeit of the same type= , video). So we need some means of tying together the two or more sides of = a single conversation, whether this be an audio conversation, a main video = conversation, or whatever. John (as individual) >=20 > Thanks, > Paul >=20 > > I am not sure I agree with Partha's further point about=20 > CSG. I will reply separately on that. > > > > John (as individual) > > > >> -----Original Message----- > >> From: siprec-bounces@ietf.org > >> [mailto:siprec-bounces@ietf.org] On Behalf Of=20 > Parthasarathi R (partr) > >> Sent: 24 May 2011 05:00 > >> To: Paul Kyzivat (pkyzivat); Charles Eckel (eckelcu) > >> Cc: siprec@ietf.org > >> Subject: Re: [siprec] What does an MS object represent? Can > >> we pick one of theseoptions? > >> > >> I agree with Paul& Charles for using option 2 because option > >> 1 is a the > >> subset of option 2. > >> > >> Adding to their point, I'll provide my understanding of=20 > Media stream > >> object as follows: > >> > >> Each Media stream object has metadata information about one > >> recorded RTP > >> stream and its related media specific information. For the=20 > sake easy > >> understanding, I'm writing Media stream object in terms of > >> format. Media > >> stream object shall be visualized in the format as follows: > >> > >> 1) Start& Stop time attribute for the specific media stream. > >> This will > >> be represented as Metadata XML attribute > >> 2) Media reference ("label") attribute has the linkage=20 > between RS SDP > >> m-line and Media stream element in XML > >> 3) Codec parameters shall refer to RS SDP codec specific=20 > attributes. > >> > >> In the current model, each metadata object shall be mapped to > >> one of the > >> m-line in RS SDP. How RS SDP m-line is mapped to CS-SDP > >> m-line based on > >> SRC deployment. > >> > >> General MS object mechanism: > >> 1) Each MS shall be contributed by multiple participant or single > >> participant. > >> 2) Each MS lifetime related to CSG because participant may > >> move from one > >> CS to another CS within single CSG and also CSG will span across > >> multiple RS. > >> > >> Please read inline for more comments. > >> > >> Thanks > >> Partha > >> > >> -----Original Message----- > >> From: siprec-bounces@ietf.org > >> [mailto:siprec-bounces@ietf.org] On Behalf > >> Of Paul Kyzivat (pkyzivat) > >> Sent: Tuesday, May 24, 2011 2:28 AM > >> To: Charles Eckel (eckelcu) > >> Cc: siprec@ietf.org > >> Subject: Re: [siprec] What does an MS object represent? Can > >> we pick one > >> of theseoptions? > >> > >> My goal here is to leave the SRC with as much flexibility=20 > as possible > >> about how it does things. 2 provides more options than 1 does. > >> > >> Thanks, > >> Paul > >> > >> On 5/23/2011 2:02 PM, Charles Eckel (eckelcu) wrote: > >>> Essentially yes, though option 1 and option 2 are just two > >> different > >>> representations of the information. I think it is really a > >> matter of > >>> which way we think is more straightforward. If you want to > >> be able to > >>> break out the media on a per participant basis, it is more > >> intuitive, > >>> in my opinion, to go with option 2. > >>> > >>> Cheers, > >>> Charles > >>> > >>> > >>>> -----Original Message----- > >>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >>> Behalf Of Paul Kyzivat (pkyzivat) > >>>> Sent: Monday, May 23, 2011 9:23 AM > >>>> To: siprec@ietf.org > >>>> Subject: Re: [siprec] What does an MS object represent?=20 > Can we pick > >>> one of theseoptions? > >>>> > >>>> IIUC, option 1 can be achieved as one of the possibilities within > >>> option 2. > >>>> > >>>> Thanks, > >>>> Paul > >>>> > >>>> On 5/23/2011 11:53 AM, Charles Eckel (eckelcu) wrote: > >>>>> My thinking up until this point has been more aligned > >> with option 2. > >>>>> I so see some benefit and simplification provided by > >> option 1, but I > >> > >>>>> think the flexibility provided by option 2 is worth the added > >>> complexity > >>>>> of representing an MS on a more granular level. > >>>>> > >>>>> Cheers, > >>>>> Charles > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On > >>>>> Behalf Of Elwell, John > >>>>>> Sent: Monday, May 23, 2011 2:19 AM > >>>>>> To: siprec@ietf.org > >>>>>> Subject: [siprec] What does an MS object represent? Can > >> we pick one > >>> of > >>>>> theseoptions? > >>>>>> > >>>>>> (Starting a new thread, because the previous thread > >> ("Does MS have > >>>>> lifetime...") was getting confused > >>>>>> in its various branches.) > >>>>>> > >>>>>> I think the fundamental question at issue is what exactly an MS > >>> object > >>>>> represents. Draft-00 is > >>>>>> certainly unclear on this. I think we have been discussing two > >>>>> possibilities: > >>>>>> > >>>>>> 1. An MS object represents a given medium (e.g., audio, > >> main video, > >>>>> presentation video, current > >>>>>> speaker video...). Different participants can=20 > contribute to this > >>>>> medium, in which case they are all > >>>>>> contributing to this single MS object. For example, in=20 > a 2-party > >>>>> audio-only CS, there is a single MS > >>>>>> object (audio) contributed to by two participants. This > >> has been my > >>>>> way of viewing it, but certainly > >>>>>> not everyone considers it this way, and I am prepared to be > >>> persuaded > >>>>> otherwise. > >>>>>> > >> This may be achieved in some scenario but not=20 > always because > >> multiple contributing participant within single RTP stream is not > >> possible for SRC which are acting as RTP translator. > >> > >>>>>> 2. An MS object represents a given medium as=20 > contributed to by a > >>>>> single participant (or by multiple > >>>>>> participants that are not separately identifiable and/or where > >>> their > >>>>> contributions are inseparable). > >>>>>> Where different participants are contributing to the=20 > same medium, > >>> this > >>>>> is represented by multiple MS > >>>>>> objects. For example, in a 2-party audio-only call,=20 > there are two > >>> MS > >>>>> objects. In this case, presumably > >>>>>> there would need to be some mechanism for tying=20 > together those MS > >>>>> objects representing the same medium > >>>>>> (e.g., the two MS objects representing audio in this > >> same example). > >>>>> Possibly the name Media Stream is > >>>>>> not sufficiently descriptive in this case, but I can't > >> come up with > >>> a > >>>>> better name. > >> > >> Even though both MS object representing audio, Metadata > >> information like MS helps to understand the real relationship with > >> participant& CS > >> > >>>>>> > >>>>>> I think we can possibly make this basic decision, and > >> then fill in > >>> the > >>>>> details afterwards. > >>>>>> > >>>>>> 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 > >> _______________________________________________ > >> siprec mailing list > >> siprec@ietf.org > >> https://www.ietf.org/mailman/listinfo/siprec > >> > = From pkyzivat@cisco.com Tue May 24 07:56: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 A66A6E0760 for ; Tue, 24 May 2011 07:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.265 X-Spam-Level: X-Spam-Status: No, score=-110.265 tagged_above=-999 required=5 tests=[AWL=0.334, 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 SL87lXSyn+bB for ; Tue, 24 May 2011 07:56:18 -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 D0440E0755 for ; Tue, 24 May 2011 07:56:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=10548; q=dns/txt; s=iport; t=1306248978; x=1307458578; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=33h/jZu8nZ+1Umma7xuHy7g8obw3xUzr2AdNcVmyiBk=; b=Llf90cnnF+HaT5HtrkplYWwqtPzbf1nCOZhrl2scM1fKi0cnIWCYidTZ AoZySEo/2KY18xQ3eMa/iGl8iFP2pOwAJlCMvnrDWIueecKW17vL7XGda acBayOJJwTt3U4LyfuUNPvG1DoJsgN2Zg0GxzHJbi2otFuIbR79N/2QSq U=; X-IronPort-AV: E=Sophos;i="4.65,261,1304294400"; d="scan'208";a="363241071" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by sj-iport-2.cisco.com with ESMTP; 24 May 2011 14:56:18 +0000 Received: from [161.44.174.124] (dhcp-161-44-174-124.cisco.com [161.44.174.124]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4OEuHkV002118; Tue, 24 May 2011 14:56:17 GMT Message-ID: <4DDBC711.5090205@cisco.com> Date: Tue, 24 May 2011 10:56:17 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Elwell, John" References: <4DDA89F2.50706@cisco.com> <4DDACA63.3010507@cisco.com> <4DDBAB1F.8090505@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] What does an MS object represent? Can we pick one of theseoptions? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 14:56:20 -0000 Partha/Ram, Can you add something to the metadata to tie together the two MS that represent the two sides of a single conversation? (m-lines with same offset in offer and answer of a CS dialog). I guess this is a new relationship in the metamodel. (Somehow I think it was in there once.) Thanks, Paul On 5/24/2011 9:17 AM, Elwell, John wrote: > > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: 24 May 2011 13:57 >> To: Elwell, John >> Cc: Parthasarathi R (partr); Charles Eckel (eckelcu); siprec@ietf.org >> Subject: Re: [siprec] What does an MS object represent? Can >> we pick one of theseoptions? >> >> >> >> On 5/24/2011 3:35 AM, Elwell, John wrote: >>> So those who have responded prefer option 2, and therefore >> I can agree to that. Essentially a Media Stream object models >> a recorded media stream. This should be made clear in the >> description of this object class in the model draft. >> >> Fair enough >> >>> A recorded media stream can be contributed to by one, >> several or all Participants. If there are two recorded media >> streams relating to the same medium, there should be a means >> within the model to tie the two together. For example, in a >> 2-party audio call where there is one recorded media stream >> per direction, the two should somehow be indicated as related >> (e.g, by having a common value of a "content" attribute). >> >> While your example is a place where tying is perhaps >> important, I don't >> think the criteria for doing so is that they are the "same >> medium", at >> least not the way I think of medium. >> >> AFAIK two streams would be considered "the same medium" if >> they are both >> video, or both voice. But not all such things should be tied >> together, >> at least not in the same way. >> >> The matched pair of streams, one in each direction, between a pair of >> participants, that carries the two sides of a conversation, >> is a special >> relationship. And I agree that we currently seem to lack a way to >> represent that. >> >> We could also have multiple streams of the same medium in a CS - for >> instance carrying multiple streams of video. That is a different >> relationship. >> >> It could be a lot of work to figure out all the relationships >> that might >> need to be represented. I would suggest leaving most of that out of >> scope for now to avoid a rat hole. But we probably do need to >> describe >> the pairing of the two sides of a single conversation. > [JRE] Yes and no. I had considered things like main video, presentation video, current speaker video as being different media (albeit of the same type, video). So we need some means of tying together the two or more sides of a single conversation, whether this be an audio conversation, a main video conversation, or whatever. > > John (as individual) > > >> >> Thanks, >> Paul >> >>> I am not sure I agree with Partha's further point about >> CSG. I will reply separately on that. >>> >>> John (as individual) >>> >>>> -----Original Message----- >>>> From: siprec-bounces@ietf.org >>>> [mailto:siprec-bounces@ietf.org] On Behalf Of >> Parthasarathi R (partr) >>>> Sent: 24 May 2011 05:00 >>>> To: Paul Kyzivat (pkyzivat); Charles Eckel (eckelcu) >>>> Cc: siprec@ietf.org >>>> Subject: Re: [siprec] What does an MS object represent? Can >>>> we pick one of theseoptions? >>>> >>>> I agree with Paul& Charles for using option 2 because option >>>> 1 is a the >>>> subset of option 2. >>>> >>>> Adding to their point, I'll provide my understanding of >> Media stream >>>> object as follows: >>>> >>>> Each Media stream object has metadata information about one >>>> recorded RTP >>>> stream and its related media specific information. For the >> sake easy >>>> understanding, I'm writing Media stream object in terms of >>>> format. Media >>>> stream object shall be visualized in the format as follows: >>>> >>>> 1) Start& Stop time attribute for the specific media stream. >>>> This will >>>> be represented as Metadata XML attribute >>>> 2) Media reference ("label") attribute has the linkage >> between RS SDP >>>> m-line and Media stream element in XML >>>> 3) Codec parameters shall refer to RS SDP codec specific >> attributes. >>>> >>>> In the current model, each metadata object shall be mapped to >>>> one of the >>>> m-line in RS SDP. How RS SDP m-line is mapped to CS-SDP >>>> m-line based on >>>> SRC deployment. >>>> >>>> General MS object mechanism: >>>> 1) Each MS shall be contributed by multiple participant or single >>>> participant. >>>> 2) Each MS lifetime related to CSG because participant may >>>> move from one >>>> CS to another CS within single CSG and also CSG will span across >>>> multiple RS. >>>> >>>> Please read inline for more comments. >>>> >>>> Thanks >>>> Partha >>>> >>>> -----Original Message----- >>>> From: siprec-bounces@ietf.org >>>> [mailto:siprec-bounces@ietf.org] On Behalf >>>> Of Paul Kyzivat (pkyzivat) >>>> Sent: Tuesday, May 24, 2011 2:28 AM >>>> To: Charles Eckel (eckelcu) >>>> Cc: siprec@ietf.org >>>> Subject: Re: [siprec] What does an MS object represent? Can >>>> we pick one >>>> of theseoptions? >>>> >>>> My goal here is to leave the SRC with as much flexibility >> as possible >>>> about how it does things. 2 provides more options than 1 does. >>>> >>>> Thanks, >>>> Paul >>>> >>>> On 5/23/2011 2:02 PM, Charles Eckel (eckelcu) wrote: >>>>> Essentially yes, though option 1 and option 2 are just two >>>> different >>>>> representations of the information. I think it is really a >>>> matter of >>>>> which way we think is more straightforward. If you want to >>>> be able to >>>>> break out the media on a per participant basis, it is more >>>> intuitive, >>>>> in my opinion, to go with option 2. >>>>> >>>>> Cheers, >>>>> Charles >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>>>> Behalf Of Paul Kyzivat (pkyzivat) >>>>>> Sent: Monday, May 23, 2011 9:23 AM >>>>>> To: siprec@ietf.org >>>>>> Subject: Re: [siprec] What does an MS object represent? >> Can we pick >>>>> one of theseoptions? >>>>>> >>>>>> IIUC, option 1 can be achieved as one of the possibilities within >>>>> option 2. >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>> On 5/23/2011 11:53 AM, Charles Eckel (eckelcu) wrote: >>>>>>> My thinking up until this point has been more aligned >>>> with option 2. >>>>>>> I so see some benefit and simplification provided by >>>> option 1, but I >>>> >>>>>>> think the flexibility provided by option 2 is worth the added >>>>> complexity >>>>>>> of representing an MS on a more granular level. >>>>>>> >>>>>>> Cheers, >>>>>>> Charles >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: siprec-bounces@ietf.org >> [mailto:siprec-bounces@ietf.org] On >>>>>>> Behalf Of Elwell, John >>>>>>>> Sent: Monday, May 23, 2011 2:19 AM >>>>>>>> To: siprec@ietf.org >>>>>>>> Subject: [siprec] What does an MS object represent? Can >>>> we pick one >>>>> of >>>>>>> theseoptions? >>>>>>>> >>>>>>>> (Starting a new thread, because the previous thread >>>> ("Does MS have >>>>>>> lifetime...") was getting confused >>>>>>>> in its various branches.) >>>>>>>> >>>>>>>> I think the fundamental question at issue is what exactly an MS >>>>> object >>>>>>> represents. Draft-00 is >>>>>>>> certainly unclear on this. I think we have been discussing two >>>>>>> possibilities: >>>>>>>> >>>>>>>> 1. An MS object represents a given medium (e.g., audio, >>>> main video, >>>>>>> presentation video, current >>>>>>>> speaker video...). Different participants can >> contribute to this >>>>>>> medium, in which case they are all >>>>>>>> contributing to this single MS object. For example, in >> a 2-party >>>>>>> audio-only CS, there is a single MS >>>>>>>> object (audio) contributed to by two participants. This >>>> has been my >>>>>>> way of viewing it, but certainly >>>>>>>> not everyone considers it this way, and I am prepared to be >>>>> persuaded >>>>>>> otherwise. >>>>>>>> >>>> This may be achieved in some scenario but not >> always because >>>> multiple contributing participant within single RTP stream is not >>>> possible for SRC which are acting as RTP translator. >>>> >>>>>>>> 2. An MS object represents a given medium as >> contributed to by a >>>>>>> single participant (or by multiple >>>>>>>> participants that are not separately identifiable and/or where >>>>> their >>>>>>> contributions are inseparable). >>>>>>>> Where different participants are contributing to the >> same medium, >>>>> this >>>>>>> is represented by multiple MS >>>>>>>> objects. For example, in a 2-party audio-only call, >> there are two >>>>> MS >>>>>>> objects. In this case, presumably >>>>>>>> there would need to be some mechanism for tying >> together those MS >>>>>>> objects representing the same medium >>>>>>>> (e.g., the two MS objects representing audio in this >>>> same example). >>>>>>> Possibly the name Media Stream is >>>>>>>> not sufficiently descriptive in this case, but I can't >>>> come up with >>>>> a >>>>>>> better name. >>>> >>>> Even though both MS object representing audio, Metadata >>>> information like MS helps to understand the real relationship with >>>> participant& CS >>>> >>>>>>>> >>>>>>>> I think we can possibly make this basic decision, and >>>> then fill in >>>>> the >>>>>>> details afterwards. >>>>>>>> >>>>>>>> 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 >>>> _______________________________________________ >>>> siprec mailing list >>>> siprec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/siprec >>>> >> From eckelcu@cisco.com Tue May 24 08:40: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 B2E9FE0761 for ; Tue, 24 May 2011 08:40:57 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YQ4wn2SpkVXr for ; Tue, 24 May 2011 08:40:56 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id E4991E0755 for ; Tue, 24 May 2011 08:40:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=2105; q=dns/txt; s=iport; t=1306251656; x=1307461256; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=itOlVqJAm4fjX8rMMd9PJje/AVZFvlXXv64MiGzNH1U=; b=K/tFL/t8idt664LnBzwpAxAhjwRR7Qcm2nFYmzVLhlvx349O91PzEbha 0+PjSVPVp1SDAzVuNs9uKrzuuQX9lGut5fYEgefiQHA8auWIgqw7Msy0/ 9UqaKbXKhXyvzTJDrVBIrVedq8Yq4OkzGU70HWOtlAkajKMGw41QPzSOu o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhABAAvR202rRDoG/2dsb2JhbACXZo5Ed6sxnXuGGwSGVo4GimQ X-IronPort-AV: E=Sophos;i="4.65,261,1304294400"; d="scan'208";a="322517761" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-3.cisco.com with ESMTP; 24 May 2011 15:40:56 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4OFeumA006317; Tue, 24 May 2011 15:40:56 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 24 May 2011 08:40:56 -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, 24 May 2011 08:40:54 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Can an MS object span several CSs in a CSG? Thread-Index: AcwZ5UbR730mQiXZRGSqd4Xx2cnzHgAHpFKQAAkglcA= References: From: "Charles Eckel (eckelcu)" To: "Parthasarathi R (partr)" , "Elwell, John" , X-OriginalArrivalTime: 24 May 2011 15:40:56.0488 (UTC) FILETIME=[F8F76A80:01CC1A28] Subject: Re: [siprec] Can an MS object span several CSs in a CSG? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 15:40:57 -0000 Hi Partha, Is an example of this the same music on hold audio stream existing as the same MS within multiple CSs? If so, then I understand your requirement to be that the SRC be able to indicate multiple instances of this audio stream within several CSs as being the same MS. Is that correct? Thanks, Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi R (partr) > Sent: Tuesday, May 24, 2011 4:26 AM > To: Elwell, John; siprec@ietf.org > Subject: Re: [siprec] Can an MS object span several CSs in a CSG? >=20 > John, >=20 > I agree that it is not mandatory to consider recorded stream of a > specific participant in several CS within the same CSG as one recorded > stream but SIPREC protocol design MUST NOT restrict a SRC in case it > wishes to design in such a way. >=20 > Thanks > Partha >=20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf > Of Elwell, John > Sent: Tuesday, May 24, 2011 1:06 PM > To: siprec@ietf.org > Subject: [siprec] Can an MS object span several CSs in a CSG? >=20 > We seem to have consensus that a Media Stream object represents a > recorded media stream, contributed to by one, several or all > Participants. However, Partha also wrote: >=20 > "2) Each MS lifetime related to CSG because participant may move from > one CS to another CS within single CSG and also CSG will span across > multiple RS." >=20 > I am not sure we had resolved this during earlier discussions on the > scope of an MS object. Although the same Participant can participate in > several CSs within the same CSG, I don't think the recorded media > streams need to be considered the same. Any other views? >=20 > 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 rmohanr@cisco.com Tue May 24 09:36:24 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 CAF42E0770 for ; Tue, 24 May 2011 09:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.134 X-Spam-Level: X-Spam-Status: No, score=-10.134 tagged_above=-999 required=5 tests=[AWL=0.465, 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 6BvL+vOLQmlx for ; Tue, 24 May 2011 09:36:23 -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 27E7FE0752 for ; Tue, 24 May 2011 09:36:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=3146; q=dns/txt; s=iport; t=1306254983; x=1307464583; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=UzVjnRwBtVP/+SBdXZwbcwl5fkSQbshRP81qCotC/zU=; b=cWaLMZhaf4p5LtL0O8Pc2BiBehB/t1n/yfrIRxT3ydjWlrSN80ixplk+ EDmLIOHhcS/DSRXT/m2CsGpRUNA3bDIQIcYN/CuD8TmN6abDIUUqbNjzj 1JKnErwMr8iTvPN5u4StKH+4Q57mno/pQ0i9l77zdoamO69WFYVkaOPfI k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AscAAF3e201Io8URgWdsb2JhbACXZY5EFAEBFiYlq22dd4YbBIZUjgiKTA X-IronPort-AV: E=Sophos;i="4.65,261,1304294400"; d="scan'208";a="90469738" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-1.cisco.com with ESMTP; 24 May 2011 16:36:05 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p4OGa4pL020683; Tue, 24 May 2011 16:36:04 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, 24 May 2011 22:06: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, 24 May 2011 22:06:01 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD067EECD7@XMB-BGL-417.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Can an MS object span several CSs in a CSG? Thread-Index: AcwZ5UbR730mQiXZRGSqd4Xx2cnzHgAHpFKQAAkglcAAAc/qEA== References: From: "Ram Mohan R (rmohanr)" To: "Charles Eckel (eckelcu)" , "Parthasarathi R (partr)" , "Elwell, John" , X-OriginalArrivalTime: 24 May 2011 16:36:04.0133 (UTC) FILETIME=[AC79FD50:01CC1A30] Subject: Re: [siprec] Can an MS object span several CSs in a CSG? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 16:36:24 -0000 Charles, I did bring about this specific usecase of MMOH/MOH stream being played to different participants earlier and suggested that they have to treated as a same MS across multiple CSs (potentially recorded using multiple RSs). Refer http://www.ietf.org/mail-archive/web/siprec/current/msg01886.html We had several discussions on it and it and several folks were in favor of treating it as separate MS as there would be complexity in DB design. Regards, Ram > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Charles Eckel (eckelcu) > Sent: Tuesday, May 24, 2011 9:11 PM > To: Parthasarathi R (partr); Elwell, John; siprec@ietf.org > Subject: Re: [siprec] Can an MS object span several CSs in a CSG? >=20 > Hi Partha, >=20 > Is an example of this the same music on hold audio stream existing as > the same MS within multiple CSs? If so, then I understand your > requirement to be that the SRC be able to indicate multiple instances > of > this audio stream within several CSs as being the same MS. Is that > correct? >=20 > Thanks, > Charles >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Parthasarathi R (partr) > > Sent: Tuesday, May 24, 2011 4:26 AM > > To: Elwell, John; siprec@ietf.org > > Subject: Re: [siprec] Can an MS object span several CSs in a CSG? > > > > John, > > > > I agree that it is not mandatory to consider recorded stream of a > > specific participant in several CS within the same CSG as one > recorded > > stream but SIPREC protocol design MUST NOT restrict a SRC in case it > > wishes to design in such a way. > > > > Thanks > > Partha > > > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf > > Of Elwell, John > > Sent: Tuesday, May 24, 2011 1:06 PM > > To: siprec@ietf.org > > Subject: [siprec] Can an MS object span several CSs in a CSG? > > > > We seem to have consensus that a Media Stream object represents a > > recorded media stream, contributed to by one, several or all > > Participants. However, Partha also wrote: > > > > "2) Each MS lifetime related to CSG because participant may move from > > one CS to another CS within single CSG and also CSG will span across > > multiple RS." > > > > I am not sure we had resolved this during earlier discussions on the > > scope of an MS object. Although the same Participant can participate > in > > several CSs within the same CSG, I don't think the recorded media > > streams need to be considered the same. Any other views? > > > > 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 rmohanr@cisco.com Tue May 24 09:52:24 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 B7677E073D for ; Tue, 24 May 2011 09:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.289 X-Spam-Level: X-Spam-Status: No, score=-10.289 tagged_above=-999 required=5 tests=[AWL=0.310, 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 2FhRHlRTorIx for ; Tue, 24 May 2011 09:52:23 -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 E636EE0730 for ; Tue, 24 May 2011 09:52:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=12092; q=dns/txt; s=iport; t=1306255943; x=1307465543; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=kn1Cz+ga+xMus8Ih+ghoqQBeyy41RCQ5VEiDr7TKDGg=; b=HHGEqgHa71xzXIJ79FFETW4elqMoQ4H6gRljuIDIqPUbYukUxNNgxD/T JgJ/Ty158GybJ34iGy59BijZoak28n7TftBDYA9AKn8ianhvAiQ/w2CGC wEDFEU18TgDdaeYWmqenxbO0sOG9viDiSYGafMaR3tfbkJX0NDnWVItFJ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AscAAJHh201Io8UQgWdsb2JhbACXZY5EFAEBFiYlq2Cdd4YbBIZUjgiKTA X-IronPort-AV: E=Sophos;i="4.65,261,1304294400"; d="scan'208";a="32061574" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-2.cisco.com with ESMTP; 24 May 2011 16:52:20 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4OGqKSk019910; Tue, 24 May 2011 16:52:20 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, 24 May 2011 22: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: Tue, 24 May 2011 22:22:18 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD067EECE1@XMB-BGL-417.cisco.com> In-Reply-To: <4DDBC711.5090205@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] What does an MS object represent? Can we pick one of theseoptions? Thread-Index: AcwaIsc0aCD6k+S5RjCjn28RXU8GBAADo/xg References: <4DDA89F2.50706@cisco.com> <4DDACA63.3010507@cisco.com><4DDBAB1F.8090505@cisco.com> <4DDBC711.5090205@cisco.com> From: "Ram Mohan R (rmohanr)" To: "Paul Kyzivat (pkyzivat)" , "Elwell, John" X-OriginalArrivalTime: 24 May 2011 16:52:20.0108 (UTC) FILETIME=[F233F4C0:01CC1A32] Cc: siprec@ietf.org Subject: Re: [siprec] What does an MS object represent? Can we pick one of theseoptions? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 16:52:24 -0000 Paul/ John, I am ok to add attribute "content" in MS block of the model.=20 The question is do we want to map this attribute in the model to=20 1) The Session Description Protocol (SDP) Content Attribute defined in RFC 4796 OR=20 2)define our own content in the metadata XML which can take values as "audio" / "main video" / "presentation video" / "current speaker video" as suggested by John. Please let me know your inputs. Ram > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Paul Kyzivat (pkyzivat) > Sent: Tuesday, May 24, 2011 8:26 PM > To: Elwell, John > Cc: siprec@ietf.org > Subject: Re: [siprec] What does an MS object represent? Can we pick one > of theseoptions? >=20 > Partha/Ram, >=20 > Can you add something to the metadata to tie together the two MS that > represent the two sides of a single conversation? (m-lines with same > offset in offer and answer of a CS dialog). I guess this is a new > relationship in the metamodel. (Somehow I think it was in there once.) >=20 > Thanks, > Paul >=20 > On 5/24/2011 9:17 AM, Elwell, John wrote: > > > > > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: 24 May 2011 13:57 > >> To: Elwell, John > >> Cc: Parthasarathi R (partr); Charles Eckel (eckelcu); > siprec@ietf.org > >> Subject: Re: [siprec] What does an MS object represent? Can > >> we pick one of theseoptions? > >> > >> > >> > >> On 5/24/2011 3:35 AM, Elwell, John wrote: > >>> So those who have responded prefer option 2, and therefore > >> I can agree to that. Essentially a Media Stream object models > >> a recorded media stream. This should be made clear in the > >> description of this object class in the model draft. > >> > >> Fair enough > >> > >>> A recorded media stream can be contributed to by one, > >> several or all Participants. If there are two recorded media > >> streams relating to the same medium, there should be a means > >> within the model to tie the two together. For example, in a > >> 2-party audio call where there is one recorded media stream > >> per direction, the two should somehow be indicated as related > >> (e.g, by having a common value of a "content" attribute). > >> > >> While your example is a place where tying is perhaps > >> important, I don't > >> think the criteria for doing so is that they are the "same > >> medium", at > >> least not the way I think of medium. > >> > >> AFAIK two streams would be considered "the same medium" if > >> they are both > >> video, or both voice. But not all such things should be tied > >> together, > >> at least not in the same way. > >> > >> The matched pair of streams, one in each direction, between a pair > of > >> participants, that carries the two sides of a conversation, > >> is a special > >> relationship. And I agree that we currently seem to lack a way to > >> represent that. > >> > >> We could also have multiple streams of the same medium in a CS - for > >> instance carrying multiple streams of video. That is a different > >> relationship. > >> > >> It could be a lot of work to figure out all the relationships > >> that might > >> need to be represented. I would suggest leaving most of that out of > >> scope for now to avoid a rat hole. But we probably do need to > >> describe > >> the pairing of the two sides of a single conversation. > > [JRE] Yes and no. I had considered things like main video, > presentation video, current speaker video as being different media > (albeit of the same type, video). So we need some means of tying > together the two or more sides of a single conversation, whether this > be an audio conversation, a main video conversation, or whatever. > > > > John (as individual) > > > > > >> > >> Thanks, > >> Paul > >> > >>> I am not sure I agree with Partha's further point about > >> CSG. I will reply separately on that. > >>> > >>> John (as individual) > >>> > >>>> -----Original Message----- > >>>> From: siprec-bounces@ietf.org > >>>> [mailto:siprec-bounces@ietf.org] On Behalf Of > >> Parthasarathi R (partr) > >>>> Sent: 24 May 2011 05:00 > >>>> To: Paul Kyzivat (pkyzivat); Charles Eckel (eckelcu) > >>>> Cc: siprec@ietf.org > >>>> Subject: Re: [siprec] What does an MS object represent? Can > >>>> we pick one of theseoptions? > >>>> > >>>> I agree with Paul& Charles for using option 2 because option > >>>> 1 is a the > >>>> subset of option 2. > >>>> > >>>> Adding to their point, I'll provide my understanding of > >> Media stream > >>>> object as follows: > >>>> > >>>> Each Media stream object has metadata information about one > >>>> recorded RTP > >>>> stream and its related media specific information. For the > >> sake easy > >>>> understanding, I'm writing Media stream object in terms of > >>>> format. Media > >>>> stream object shall be visualized in the format as follows: > >>>> > >>>> 1) Start& Stop time attribute for the specific media stream. > >>>> This will > >>>> be represented as Metadata XML attribute > >>>> 2) Media reference ("label") attribute has the linkage > >> between RS SDP > >>>> m-line and Media stream element in XML > >>>> 3) Codec parameters shall refer to RS SDP codec specific > >> attributes. > >>>> > >>>> In the current model, each metadata object shall be mapped to > >>>> one of the > >>>> m-line in RS SDP. How RS SDP m-line is mapped to CS-SDP > >>>> m-line based on > >>>> SRC deployment. > >>>> > >>>> General MS object mechanism: > >>>> 1) Each MS shall be contributed by multiple participant or single > >>>> participant. > >>>> 2) Each MS lifetime related to CSG because participant may > >>>> move from one > >>>> CS to another CS within single CSG and also CSG will span across > >>>> multiple RS. > >>>> > >>>> Please read inline for more comments. > >>>> > >>>> Thanks > >>>> Partha > >>>> > >>>> -----Original Message----- > >>>> From: siprec-bounces@ietf.org > >>>> [mailto:siprec-bounces@ietf.org] On Behalf > >>>> Of Paul Kyzivat (pkyzivat) > >>>> Sent: Tuesday, May 24, 2011 2:28 AM > >>>> To: Charles Eckel (eckelcu) > >>>> Cc: siprec@ietf.org > >>>> Subject: Re: [siprec] What does an MS object represent? Can > >>>> we pick one > >>>> of theseoptions? > >>>> > >>>> My goal here is to leave the SRC with as much flexibility > >> as possible > >>>> about how it does things. 2 provides more options than 1 does. > >>>> > >>>> Thanks, > >>>> Paul > >>>> > >>>> On 5/23/2011 2:02 PM, Charles Eckel (eckelcu) wrote: > >>>>> Essentially yes, though option 1 and option 2 are just two > >>>> different > >>>>> representations of the information. I think it is really a > >>>> matter of > >>>>> which way we think is more straightforward. If you want to > >>>> be able to > >>>>> break out the media on a per participant basis, it is more > >>>> intuitive, > >>>>> in my opinion, to go with option 2. > >>>>> > >>>>> Cheers, > >>>>> Charles > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] > On > >>>>> Behalf Of Paul Kyzivat (pkyzivat) > >>>>>> Sent: Monday, May 23, 2011 9:23 AM > >>>>>> To: siprec@ietf.org > >>>>>> Subject: Re: [siprec] What does an MS object represent? > >> Can we pick > >>>>> one of theseoptions? > >>>>>> > >>>>>> IIUC, option 1 can be achieved as one of the possibilities > within > >>>>> option 2. > >>>>>> > >>>>>> Thanks, > >>>>>> Paul > >>>>>> > >>>>>> On 5/23/2011 11:53 AM, Charles Eckel (eckelcu) wrote: > >>>>>>> My thinking up until this point has been more aligned > >>>> with option 2. > >>>>>>> I so see some benefit and simplification provided by > >>>> option 1, but I > >>>> > >>>>>>> think the flexibility provided by option 2 is worth the added > >>>>> complexity > >>>>>>> of representing an MS on a more granular level. > >>>>>>> > >>>>>>> Cheers, > >>>>>>> Charles > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: siprec-bounces@ietf.org > >> [mailto:siprec-bounces@ietf.org] On > >>>>>>> Behalf Of Elwell, John > >>>>>>>> Sent: Monday, May 23, 2011 2:19 AM > >>>>>>>> To: siprec@ietf.org > >>>>>>>> Subject: [siprec] What does an MS object represent? Can > >>>> we pick one > >>>>> of > >>>>>>> theseoptions? > >>>>>>>> > >>>>>>>> (Starting a new thread, because the previous thread > >>>> ("Does MS have > >>>>>>> lifetime...") was getting confused > >>>>>>>> in its various branches.) > >>>>>>>> > >>>>>>>> I think the fundamental question at issue is what exactly an > MS > >>>>> object > >>>>>>> represents. Draft-00 is > >>>>>>>> certainly unclear on this. I think we have been discussing two > >>>>>>> possibilities: > >>>>>>>> > >>>>>>>> 1. An MS object represents a given medium (e.g., audio, > >>>> main video, > >>>>>>> presentation video, current > >>>>>>>> speaker video...). Different participants can > >> contribute to this > >>>>>>> medium, in which case they are all > >>>>>>>> contributing to this single MS object. For example, in > >> a 2-party > >>>>>>> audio-only CS, there is a single MS > >>>>>>>> object (audio) contributed to by two participants. This > >>>> has been my > >>>>>>> way of viewing it, but certainly > >>>>>>>> not everyone considers it this way, and I am prepared to be > >>>>> persuaded > >>>>>>> otherwise. > >>>>>>>> > >>>> This may be achieved in some scenario but not > >> always because > >>>> multiple contributing participant within single RTP stream is not > >>>> possible for SRC which are acting as RTP translator. > >>>> > >>>>>>>> 2. An MS object represents a given medium as > >> contributed to by a > >>>>>>> single participant (or by multiple > >>>>>>>> participants that are not separately identifiable and/or where > >>>>> their > >>>>>>> contributions are inseparable). > >>>>>>>> Where different participants are contributing to the > >> same medium, > >>>>> this > >>>>>>> is represented by multiple MS > >>>>>>>> objects. For example, in a 2-party audio-only call, > >> there are two > >>>>> MS > >>>>>>> objects. In this case, presumably > >>>>>>>> there would need to be some mechanism for tying > >> together those MS > >>>>>>> objects representing the same medium > >>>>>>>> (e.g., the two MS objects representing audio in this > >>>> same example). > >>>>>>> Possibly the name Media Stream is > >>>>>>>> not sufficiently descriptive in this case, but I can't > >>>> come up with > >>>>> a > >>>>>>> better name. > >>>> > >>>> Even though both MS object representing audio, Metadata > >>>> information like MS helps to understand the real relationship with > >>>> participant& CS > >>>> > >>>>>>>> > >>>>>>>> I think we can possibly make this basic decision, and > >>>> then fill in > >>>>> the > >>>>>>> details afterwards. > >>>>>>>> > >>>>>>>> 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 > >>>> _______________________________________________ > >>>> siprec mailing 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 May 24 10:07:31 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 089C1E076F for ; Tue, 24 May 2011 10:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.975 X-Spam-Level: X-Spam-Status: No, score=-109.975 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, J_CHICKENPOX_17=0.6, 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 bqN1uC6UhkmE for ; Tue, 24 May 2011 10:07:30 -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 7CD4CE073C for ; Tue, 24 May 2011 10:07:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=1169; q=dns/txt; s=iport; t=1306256850; x=1307466450; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=sBZb5vunwQfvDwAHlcvj/jZVwxA8H6yMGdFmOY8vh+I=; b=Tw+c+iKQvnHEhaqInFPcV87iwNTc5ntBj6V/wyhYH0M4jARpnaNO0ofz szXif+1hyRuV4gqjHK4YUicL3KETyZ2CnDkvV5UuD2FMliu3L/BgjvDES r919BZdEUgJvkSuo1SObCGsQeTjA5BxaRmE0vHEkOo1WbIeEkPzRP7eQk Y=; X-IronPort-AV: E=Sophos;i="4.65,261,1304294400"; d="scan'208";a="453458871" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-1.cisco.com with ESMTP; 24 May 2011 17:07:30 +0000 Received: from [161.44.174.124] (dhcp-161-44-174-124.cisco.com [161.44.174.124]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p4OH7TiG029284; Tue, 24 May 2011 17:07:29 GMT Message-ID: <4DDBE5D1.7030704@cisco.com> Date: Tue, 24 May 2011 13:07:29 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Ram Mohan R (rmohanr)" References: <4DDA89F2.50706@cisco.com> <4DDACA63.3010507@cisco.com><4DDBAB1F.8090505@cisco.com> <4DDBC711.5090205@cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD067EECE1@XMB-BGL-417.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD067EECE1@XMB-BGL-417.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: siprec@ietf.org Subject: Re: [siprec] What does an MS object represent? Can we pick one of theseoptions? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 17:07:31 -0000 On 5/24/2011 12:52 PM, Ram Mohan R (rmohanr) wrote: > Paul/ John, > > I am ok to add attribute "content" in MS block of the model. > > The question is do we want to map this attribute in the model to > 1) The Session Description Protocol (SDP) Content Attribute defined in > RFC 4796 OR > 2)define our own content in the metadata XML which can take values as > "audio" / "main video" / "presentation video" / "current speaker video" > as suggested by John. Well... ISTM that if there is already an a=content in the CS SDP, then we would want to report that in the metadata. If there is a pair (one from offer, one from answer, same m-line offset) and there is *not* an a=content that pairs them, then we would want to report it anyway. But if we do that we have a problem with names and conflicts. rfc4796 doesn't define a lot of names, nor does it say whether corresponding streams in offer & answer must have the same names. So I think we have something similar but not quite the same, and we need to define something new. It must permit identifying streams even though we know nothing of their purpose. Thanks, Paul From partr@cisco.com Tue May 24 11:17: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 2D38BE0785 for ; Tue, 24 May 2011 11:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.056 X-Spam-Level: X-Spam-Status: No, score=-10.056 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, J_CHICKENPOX_17=0.6, 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 iE2Rac6H-v7z for ; Tue, 24 May 2011 11:17:19 -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 9E5BBE076B for ; Tue, 24 May 2011 11:17:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=2200; q=dns/txt; s=iport; t=1306261038; x=1307470638; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=M/Ube7cOChczrIaNqrhTva84yjdYBdZQNdLUECZmzn8=; b=b4xkCIM2P7e+k9apURfCMoFbUuEhT9TjqxkzdbdqozSFjZP81Zd/CVEC 9t6FMos71iFLhBbj5bOIsujWfAXKVEBtnoynwIzThZWWnAkG7nkaN6Ndv YO3Ts+OCubasdmn8wUQQY92DUOkcvXOhJh/6jcp6Y3gOrgktf5+u9N3XP g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvkAAH71201Io8URgWdsb2JhbACXZY5EFAEBFiYliHCiep13hhsEhlSOCIpM X-IronPort-AV: E=Sophos;i="4.65,262,1304294400"; d="scan'208";a="32071270" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-2.cisco.com with ESMTP; 24 May 2011 18:17:17 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p4OIHGOd004608 for ; Tue, 24 May 2011 18:17:16 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, 24 May 2011 23:47: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, 24 May 2011 23:47:14 +0530 Message-ID: In-Reply-To: <4DDBE5D1.7030704@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] What does an MS object represent? Can we pick one of theseoptions? Thread-Index: AcwaNRbPSHK44ZUfSAW47INxD0XMIQAAkgxA References: <4DDA89F2.50706@cisco.com> <4DDACA63.3010507@cisco.com><4DDBAB1F.8090505@cisco.com><4DDBC711.5090205@cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD067EECE1@XMB-BGL-417.cisco.com> <4DDBE5D1.7030704@cisco.com> From: "Parthasarathi R (partr)" To: "Paul Kyzivat (pkyzivat)" , "Ram Mohan R (rmohanr)" X-OriginalArrivalTime: 24 May 2011 18:17:15.0809 (UTC) FILETIME=[CF7A3910:01CC1A3E] Cc: siprec@ietf.org Subject: Re: [siprec] What does an MS object represent? Can we pick one of theseoptions? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 18:17:20 -0000 I agree with John that there is a need for relationship between MS for grouping. Also, I'm of the same opinion as Paul that "content" attribute may not serve this requirement.=20 I had offline discussion with Ram, we think that new "media stream content group" metadata object may solve this issue. The half-baked idea is to 1) Create new optional "Media Stream Content Group" (MSCG) metadata object=20 2) MSCG is related to MS as [0..*]-[1..*]=20 3) MSCG is relate to CS as [0..*]- [1..*] Please let me know your opinion on the same. Thanks Partha =20 -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat (pkyzivat) Sent: Tuesday, May 24, 2011 10:37 PM To: Ram Mohan R (rmohanr) Cc: siprec@ietf.org Subject: Re: [siprec] What does an MS object represent? Can we pick one of theseoptions? On 5/24/2011 12:52 PM, Ram Mohan R (rmohanr) wrote: > Paul/ John, > > I am ok to add attribute "content" in MS block of the model. > > The question is do we want to map this attribute in the model to > 1) The Session Description Protocol (SDP) Content Attribute defined in > RFC 4796 OR 2)define our own content in the metadata XML which can=20 > take values as "audio" / "main video" / "presentation video" /=20 > "current speaker video" > as suggested by John. Well... ISTM that if there is already an a=3Dcontent in the CS SDP, then we = would want to report that in the metadata. If there is a pair (one from offer, one from answer, same m-line offset) and there is *not* an a=3Dcontent that pairs them, then we would want to report it anyway. But if we do that we have a problem with names and conflicts. rfc4796 doesn't define a lot of names, nor does it say whether corresponding streams in offer & answer must have the same names. So I think we have something similar but not quite the same, and we need to define something new. It must permit identifying streams even though we know nothing of their purpose. Thanks, Paul _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From Leon.Portman@nice.com Tue May 24 11:37:22 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B112EE075B for ; Tue, 24 May 2011 11:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.94 X-Spam-Level: X-Spam-Status: No, score=-1.94 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, J_CHICKENPOX_17=0.6] 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 Cm87xx-+j1GQ for ; Tue, 24 May 2011 11:37:20 -0700 (PDT) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id 4E69FE074F for ; Tue, 24 May 2011 11:37:20 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.15]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Tue, 24 May 2011 21:37:19 +0300 From: Leon Portman To: "Parthasarathi R (partr)" , "Paul Kyzivat (pkyzivat)" , "Ram Mohan R (rmohanr)" Date: Tue, 24 May 2011 21:37:16 +0300 Thread-Topic: [siprec] What does an MS object represent? Can we pick one of theseoptions? Thread-Index: AcwaNRbPSHK44ZUfSAW47INxD0XMIQAAkgxAAAKNZ/A= Message-ID: <07465C1D981ABC41A344374066AE1A2C38AC24DA56@TLVMBX01.nice.com> References: <4DDA89F2.50706@cisco.com> <4DDACA63.3010507@cisco.com><4DDBAB1F.8090505@cisco.com><4DDBC711.5090205@cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD067EECE1@XMB-BGL-417.cisco.com> <4DDBE5D1.7030704@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] What does an MS object represent? Can we pick one of theseoptions? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 18:37:22 -0000 I am OK with the below Leon -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Parthasarathi R (partr) Sent: Tuesday, May 24, 2011 9:17 PM To: Paul Kyzivat (pkyzivat); Ram Mohan R (rmohanr) Cc: siprec@ietf.org Subject: Re: [siprec] What does an MS object represent? Can we pick one of = theseoptions? I agree with John that there is a need for relationship between MS for grou= ping. Also, I'm of the same opinion as Paul that "content" attribute may no= t serve this requirement.=20 I had offline discussion with Ram, we think that new "media stream content = group" metadata object may solve this issue. The half-baked idea is to 1) Create new optional "Media Stream Content Group" (MSCG) metadata object 2) MSCG is related to MS as [0..*]-[1..*] 3) MSCG is relate to CS as [0..*]- [1..*] Please let me know your opinion on the same. Thanks Partha =20 -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Paul Kyzivat (pkyzivat) Sent: Tuesday, May 24, 2011 10:37 PM To: Ram Mohan R (rmohanr) Cc: siprec@ietf.org Subject: Re: [siprec] What does an MS object represent? Can we pick one of = theseoptions? On 5/24/2011 12:52 PM, Ram Mohan R (rmohanr) wrote: > Paul/ John, > > I am ok to add attribute "content" in MS block of the model. > > The question is do we want to map this attribute in the model to > 1) The Session Description Protocol (SDP) Content Attribute defined in > RFC 4796 OR 2)define our own content in the metadata XML which can=20 > take values as "audio" / "main video" / "presentation video" /=20 > "current speaker video" > as suggested by John. Well... ISTM that if there is already an a=3Dcontent in the CS SDP, then we would w= ant to report that in the metadata. If there is a pair (one from offer, one from answer, same m-line offset) an= d there is *not* an a=3Dcontent that pairs them, then we would want to repo= rt it anyway. But if we do that we have a problem with names and conflicts. rfc4796 doesn= 't define a lot of names, nor does it say whether corresponding streams in = offer & answer must have the same names. So I think we have something similar but not quite the same, and we need to= define something new. It must permit identifying streams even though we kn= ow nothing of their purpose. 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 eckelcu@cisco.com Tue May 24 13:08: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 C526AE07E0 for ; Tue, 24 May 2011 13:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.495 X-Spam-Level: X-Spam-Status: No, score=-10.495 tagged_above=-999 required=5 tests=[AWL=0.104, 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 XMlSLE-yveLZ for ; Tue, 24 May 2011 13:08:32 -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 CC775E07DF for ; Tue, 24 May 2011 13:08:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=4053; q=dns/txt; s=iport; t=1306267712; x=1307477312; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=e4drxPGTBfwPXg9O6g1XH4raizZe7Fm50eQ+//GL4+Y=; b=VlzxorFvBe1Q47wbdP1swzhleYHF+CO5B7T+9dtebt82uqpFfDRE9MfV Xk0yxjOEpDUho7TouezZpdRMbMcNP0IIplPRjony0zZeTwuK6/KuoTsd0 vEXTNqKpEfT4k1c3SlW6oxxB/XcfyvTzQodHJzI7iIxPAkskLyZb8SPoX s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwBAIkP3E2rRDoI/2dsb2JhbACXZY5Ed6s1nXCGGwSGVo4GimQ X-IronPort-AV: E=Sophos;i="4.65,263,1304294400"; d="scan'208";a="702700577" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-6.cisco.com with ESMTP; 24 May 2011 20:08:32 +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 p4OK8W8C014595; Tue, 24 May 2011 20:08:32 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 24 May 2011 13:08:32 -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, 24 May 2011 13:08:30 -0700 Message-ID: In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD067EECD7@XMB-BGL-417.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Can an MS object span several CSs in a CSG? Thread-Index: AcwZ5UbR730mQiXZRGSqd4Xx2cnzHgAHpFKQAAkglcAAAc/qEAAHiqxw References: <35BCE99A477D6A4986FB2216D8CF2CFD067EECD7@XMB-BGL-417.cisco.com> From: "Charles Eckel (eckelcu)" To: "Ram Mohan R (rmohanr)" , "Parthasarathi R (partr)" , "Elwell, John" , X-OriginalArrivalTime: 24 May 2011 20:08:32.0463 (UTC) FILETIME=[5B12C5F0:01CC1A4E] Subject: Re: [siprec] Can an MS object span several CSs in a CSG? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 20:08:33 -0000 Hi Ram, I think that is many cases, they will be treated as separate MSs due to the complexities you mention. However, I am trying to understand if Partha feels allowing an SRC to treat them as a single MS is still required. If not, then what is a use case? A concrete example would help me, and potentially others, to better understand the motivation behind Partha's requirement for modeling media from multiple CSs as a single MS. Cheers, Charles > -----Original Message----- > From: Ram Mohan R (rmohanr) > Sent: Tuesday, May 24, 2011 9:36 AM > To: Charles Eckel (eckelcu); Parthasarathi R (partr); Elwell, John; siprec@ietf.org > Subject: RE: [siprec] Can an MS object span several CSs in a CSG? >=20 > Charles, >=20 > I did bring about this specific usecase of MMOH/MOH stream being played to different participants > earlier and suggested that they have to treated as a same MS across multiple CSs (potentially recorded > using multiple RSs). > Refer http://www.ietf.org/mail-archive/web/siprec/current/msg01886.html >=20 > We had several discussions on it and it and several folks were in favor of treating it as separate MS > as there would be complexity in DB design. >=20 > Regards, > Ram >=20 >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Charles Eckel (eckelcu) > > Sent: Tuesday, May 24, 2011 9:11 PM > > To: Parthasarathi R (partr); Elwell, John; siprec@ietf.org > > Subject: Re: [siprec] Can an MS object span several CSs in a CSG? > > > > Hi Partha, > > > > Is an example of this the same music on hold audio stream existing as > > the same MS within multiple CSs? If so, then I understand your > > requirement to be that the SRC be able to indicate multiple instances > > of > > this audio stream within several CSs as being the same MS. Is that > > correct? > > > > Thanks, > > Charles > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Parthasarathi R (partr) > > > Sent: Tuesday, May 24, 2011 4:26 AM > > > To: Elwell, John; siprec@ietf.org > > > Subject: Re: [siprec] Can an MS object span several CSs in a CSG? > > > > > > John, > > > > > > I agree that it is not mandatory to consider recorded stream of a > > > specific participant in several CS within the same CSG as one > > recorded > > > stream but SIPREC protocol design MUST NOT restrict a SRC in case it > > > wishes to design in such a way. > > > > > > Thanks > > > Partha > > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf > > > Of Elwell, John > > > Sent: Tuesday, May 24, 2011 1:06 PM > > > To: siprec@ietf.org > > > Subject: [siprec] Can an MS object span several CSs in a CSG? > > > > > > We seem to have consensus that a Media Stream object represents a > > > recorded media stream, contributed to by one, several or all > > > Participants. However, Partha also wrote: > > > > > > "2) Each MS lifetime related to CSG because participant may move from > > > one CS to another CS within single CSG and also CSG will span across > > > multiple RS." > > > > > > I am not sure we had resolved this during earlier discussions on the > > > scope of an MS object. Although the same Participant can participate > > in > > > several CSs within the same CSG, I don't think the recorded media > > > streams need to be considered the same. Any other views? > > > > > > 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 eckelcu@cisco.com Tue May 24 13:44:14 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68F3FE078C for ; Tue, 24 May 2011 13:44:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.502 X-Spam-Level: X-Spam-Status: No, score=-10.502 tagged_above=-999 required=5 tests=[AWL=0.097, 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 PMIL-TShunG5 for ; Tue, 24 May 2011 13:44:13 -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 BDB1DE0784 for ; Tue, 24 May 2011 13:44:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=2; q=dns/txt; s=iport; t=1306269853; x=1307479453; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=frcCV1k9oG9oKj3dpUqdJg1PxRT2RSN/XKdLCPjaYaY=; b=mHr6uWMjLG569gvGQoHDOOJ9YsetSQlb3gPql59xAFqg6KGlwmQNfaye FgcenxAlM+hvbzi5LaleXzuWPDS54aLsfSKqcNmWqi1iNyuNcISMtzBs9 omeLv9cWHrjFWE1ur+P7/OJHq7molraNha0EdZte75UOR67h5gtr9mCib M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At4GAGsX3E2rRDoI/2dsb2JhbACHGpELjgR3iGmhBoEdnXSGGwSGVo4GimQ X-IronPort-AV: E=Sophos;i="4.65,263,1304294400"; d="scan'208";a="453598914" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-1.cisco.com with ESMTP; 24 May 2011 20:44:12 +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 p4OKiCD9012010 for ; Tue, 24 May 2011 20:44:12 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, 24 May 2011 13:44:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: A6gq BPyf Bopx Bz6W CXrh Cl64 Cnhi Dl0r D788 EfWK Fl8r Gzc5 G4Ss G6ar G6az LvdW; 1; cwBpAHAAcgBlAGMAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {3E44BFB1-0487-4137-91F1-E22F55055C05}; ZQBjAGsAZQBsAGMAdQBAAGMAaQBzAGMAbwAuAGMAbwBtAA==; Tue, 24 May 2011 20:44:08 GMT; dABlAHMAdAAgAC0AIABwAGwAZQBhAHMAZQAgAGkAZwBuAG8AcgBlACAAPABlAG8AbQA+AA== MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {3E44BFB1-0487-4137-91F1-E22F55055C05} Content-class: urn:content-classes:message Date: Tue, 24 May 2011 13:44:08 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: test - please ignore Thread-Index: AcwaU1RunzAVX+lVTY+EKm46qY9FZw== From: "Charles Eckel (eckelcu)" To: X-OriginalArrivalTime: 24 May 2011 20:44:12.0519 (UTC) FILETIME=[56A56770:01CC1A53] Subject: [siprec] test - please ignore X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 20:44:14 -0000 From pkyzivat@cisco.com Tue May 24 14:21:44 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 321BCE07EA for ; Tue, 24 May 2011 14:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.976 X-Spam-Level: X-Spam-Status: No, score=-109.976 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, J_CHICKENPOX_17=0.6, 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 jEmdM-h4RLSL for ; Tue, 24 May 2011 14:21:43 -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 30C61E07DE for ; Tue, 24 May 2011 14:21:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=2942; q=dns/txt; s=iport; t=1306272103; x=1307481703; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Jbv0f4GSvV6Tkv61JtHnLwW3ZvrR02GD0TWaQi3PyBg=; b=fP5sr40o7m1CbLbAgpL3FKh3xC0ib+gz2makmhZQxNlDWTlImcvNZqzR rKhcqNv8pZs5p/YhJcr9Sz2lq1HU05dOzh8n+3zVJoiPOK2/DPsmYt9bh qdd2TrhwRp/PtGsUBuoVL9U4n3X7cA4/95uQiVnmPDHGxXiTpdZ/Jc39d o=; X-IronPort-AV: E=Sophos;i="4.65,263,1304294400"; d="scan'208";a="453619752" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-1.cisco.com with ESMTP; 24 May 2011 21:21:43 +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 p4OLLg1o028292; Tue, 24 May 2011 21:21:42 GMT Message-ID: <4DDC2166.6040502@cisco.com> Date: Tue, 24 May 2011 17:21:42 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Parthasarathi R (partr)" References: <4DDA89F2.50706@cisco.com> <4DDACA63.3010507@cisco.com><4DDBAB1F.8090505@cisco.com><4DDBC711.5090205@cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD067EECE1@XMB-BGL-417.cisco.com> <4DDBE5D1.7030704@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] What does an MS object represent? Can we pick one of theseoptions? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 21:21:44 -0000 On 5/24/2011 2:17 PM, Parthasarathi R (partr) wrote: > I agree with John that there is a need for relationship between MS for > grouping. Also, I'm of the same opinion as Paul that "content" attribute > may not serve this requirement. > > I had offline discussion with Ram, we think that new "media stream > content group" metadata object may solve this issue. > > The half-baked idea is to > > 1) Create new optional "Media Stream Content Group" (MSCG) metadata > object > 2) MSCG is related to MS as [0..*]-[1..*] > 3) MSCG is relate to CS as [0..*]- [1..*] > > Please let me know your opinion on the same. This will presumably be used *a lot*, so its best if its not cumbersome. It could be simpler if its limited to describing pairs of streams that are "mated". Then they could simply refer to one another. It is perhaps more complex if you consider a conference, where each participant has a "pair", where one side is what it sends towards the focus and the other side is what it receives from the focus. Then the relationship is more complex. We also *perhaps* need a way to represent the a=content things in the CS. But that can be considered a separate problem. Thanks, Paul > Thanks > Partha > > > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf > Of Paul Kyzivat (pkyzivat) > Sent: Tuesday, May 24, 2011 10:37 PM > To: Ram Mohan R (rmohanr) > Cc: siprec@ietf.org > Subject: Re: [siprec] What does an MS object represent? Can we pick one > of theseoptions? > > > > On 5/24/2011 12:52 PM, Ram Mohan R (rmohanr) wrote: >> Paul/ John, >> >> I am ok to add attribute "content" in MS block of the model. >> >> The question is do we want to map this attribute in the model to >> 1) The Session Description Protocol (SDP) Content Attribute defined in > >> RFC 4796 OR 2)define our own content in the metadata XML which can >> take values as "audio" / "main video" / "presentation video" / >> "current speaker video" >> as suggested by John. > > Well... > > ISTM that if there is already an a=content in the CS SDP, then we would > want to report that in the metadata. > > If there is a pair (one from offer, one from answer, same m-line offset) > and there is *not* an a=content that pairs them, then we would want to > report it anyway. > > But if we do that we have a problem with names and conflicts. rfc4796 > doesn't define a lot of names, nor does it say whether corresponding > streams in offer& answer must have the same names. > > So I think we have something similar but not quite the same, and we need > to define something new. It must permit identifying streams even though > we know nothing of their purpose. > > Thanks, > Paul > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From partr@cisco.com Tue May 24 15:14: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 CC1B6E07A7 for ; Tue, 24 May 2011 15:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.352 X-Spam-Level: X-Spam-Status: No, score=-10.352 tagged_above=-999 required=5 tests=[AWL=0.247, 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 1B6Mr856GyoU for ; Tue, 24 May 2011 15:14:15 -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 0EC1DE0670 for ; Tue, 24 May 2011 15:14:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=5236; q=dns/txt; s=iport; t=1306275255; x=1307484855; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=aLx8dt8JHhVP9WSXgg0VxhoLJNz37JhWvFCCA+jVgDA=; b=IRF5YExMQjwgty1ix355i1Zagr5L5VK9bqPMdx4P/KSunsl8jk8PQ57v COkS6ysPi4sn+RmBl8o6DS2+yJAt6RqCR64YE4TqqsRI0G2+To5cY9Lyh QZipewbxf/Mp97WKybvxkh8tk4C2Kvq+SsZP/FCEXQd26BggKXbcoJTII E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvkAANws3E1Io8UQgWdsb2JhbACXZY5EFAEBFiYliHChY512hhsEhlSOCIpM X-IronPort-AV: E=Sophos;i="4.65,263,1304294400"; d="scan'208";a="90508709" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-1.cisco.com with ESMTP; 24 May 2011 22:14:13 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4OMECS6032250; Tue, 24 May 2011 22:14: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); Wed, 25 May 2011 03:44: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, 25 May 2011 03:44:10 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Can an MS object span several CSs in a CSG? Thread-Index: AcwZ5UbR730mQiXZRGSqd4Xx2cnzHgAHpFKQAAkglcAAAc/qEAAHiqxwAARuZ7A= References: <35BCE99A477D6A4986FB2216D8CF2CFD067EECD7@XMB-BGL-417.cisco.com> From: "Parthasarathi R (partr)" To: "Charles Eckel (eckelcu)" , "Ram Mohan R (rmohanr)" , "Elwell, John" , X-OriginalArrivalTime: 24 May 2011 22:14:11.0669 (UTC) FILETIME=[E8CA5050:01CC1A5F] Subject: Re: [siprec] Can an MS object span several CSs in a CSG? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 22:14:16 -0000 Hi Charles, One of the usecase in my mind is discussed in http://www.ietf.org/mail-archive/web/siprec/current/msg01890.html. The details are 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 Thanks Partha =20 -----Original Message----- From: Charles Eckel (eckelcu)=20 Sent: Wednesday, May 25, 2011 1:39 AM To: Ram Mohan R (rmohanr); Parthasarathi R (partr); 'Elwell, John'; 'siprec@ietf.org' Subject: RE: [siprec] Can an MS object span several CSs in a CSG? Hi Ram, I think that is many cases, they will be treated as separate MSs due to the complexities you mention. However, I am trying to understand if Partha feels allowing an SRC to treat them as a single MS is still required. If not, then what is a use case? A concrete example would help me, and potentially others, to better understand the motivation behind Partha's requirement for modeling media from multiple CSs as a single MS. Cheers, Charles > -----Original Message----- > From: Ram Mohan R (rmohanr) > Sent: Tuesday, May 24, 2011 9:36 AM > To: Charles Eckel (eckelcu); Parthasarathi R (partr); Elwell, John;=20 > siprec@ietf.org > Subject: RE: [siprec] Can an MS object span several CSs in a CSG? >=20 > Charles, >=20 > I did bring about this specific usecase of MMOH/MOH stream being=20 > played to different participants earlier and suggested that they have=20 > to treated as a same MS across multiple CSs (potentially recorded using multiple RSs). > Refer=20 > http://www.ietf.org/mail-archive/web/siprec/current/msg01886.html >=20 > We had several discussions on it and it and several folks were in=20 > favor of treating it as separate MS as there would be complexity in DB design. >=20 > Regards, > Ram >=20 >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > > Behalf Of Charles Eckel (eckelcu) > > Sent: Tuesday, May 24, 2011 9:11 PM > > To: Parthasarathi R (partr); Elwell, John; siprec@ietf.org > > Subject: Re: [siprec] Can an MS object span several CSs in a CSG? > > > > Hi Partha, > > > > Is an example of this the same music on hold audio stream existing=20 > > as the same MS within multiple CSs? If so, then I understand your=20 > > requirement to be that the SRC be able to indicate multiple=20 > > instances of this audio stream within several CSs as being the same=20 > > MS. Is that correct? > > > > Thanks, > > Charles > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Parthasarathi R (partr) > > > Sent: Tuesday, May 24, 2011 4:26 AM > > > To: Elwell, John; siprec@ietf.org > > > Subject: Re: [siprec] Can an MS object span several CSs in a CSG? > > > > > > John, > > > > > > I agree that it is not mandatory to consider recorded stream of a=20 > > > specific participant in several CS within the same CSG as one > > recorded > > > stream but SIPREC protocol design MUST NOT restrict a SRC in case=20 > > > it wishes to design in such a way. > > > > > > Thanks > > > Partha > > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf > > > Of Elwell, John > > > Sent: Tuesday, May 24, 2011 1:06 PM > > > To: siprec@ietf.org > > > Subject: [siprec] Can an MS object span several CSs in a CSG? > > > > > > We seem to have consensus that a Media Stream object represents a=20 > > > recorded media stream, contributed to by one, several or all=20 > > > Participants. However, Partha also wrote: > > > > > > "2) Each MS lifetime related to CSG because participant may move=20 > > > from one CS to another CS within single CSG and also CSG will span > > > across multiple RS." > > > > > > I am not sure we had resolved this during earlier discussions on=20 > > > the scope of an MS object. Although the same Participant can=20 > > > participate > > in > > > several CSs within the same CSG, I don't think the recorded media=20 > > > streams need to be considered the same. Any other views? > > > > > > 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 john.elwell@siemens-enterprise.com Tue May 24 23:15:31 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C75813000B for ; Tue, 24 May 2011 23:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.204 X-Spam-Level: X-Spam-Status: No, score=-106.204 tagged_above=-999 required=5 tests=[AWL=-0.205, BAYES_00=-2.599, J_CHICKENPOX_17=0.6, 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 Xg2QXLNY6SIo for ; Tue, 24 May 2011 23:15:30 -0700 (PDT) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfa.amsl.com (Postfix) with SMTP id 25D7D13000A for ; Tue, 24 May 2011 23:15:29 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1306304120!34905787!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 14917 invoked from network); 25 May 2011 06:15:20 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-9.tower-27.messagelabs.com with SMTP; 25 May 2011 06:15:20 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 2ADE71EB83D3; Wed, 25 May 2011 08:15:27 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 25 May 2011 08:15:27 +0200 From: "Elwell, John" To: Paul Kyzivat , "Ram Mohan R (rmohanr)" Date: Wed, 25 May 2011 08:14:59 +0200 Thread-Topic: [siprec] What does an MS object represent? Can we pick one of theseoptions? Thread-Index: AcwaNRNd5Kpg41TSSeWFPJywVvLejAAbXOUA Message-ID: References: <4DDA89F2.50706@cisco.com> <4DDACA63.3010507@cisco.com><4DDBAB1F.8090505@cisco.com> <4DDBC711.5090205@cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD067EECE1@XMB-BGL-417.cisco.com> <4DDBE5D1.7030704@cisco.com> In-Reply-To: <4DDBE5D1.7030704@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] What does an MS object represent? Can we pick one of theseoptions? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 25 May 2011 06:15:31 -0000 Given that SDP's a=3Dcontent might not be rich enough, I think we need to d= efine something new for metadata, independent of a=3Dcontent. The SRC could= choose to derive the metadata content attribute from the a=3Dcontent attri= butes of the contributing CS streams (that is an SRC decision), but should = not use the a=3Dcontent label in the RS SDP. John (as individual) > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: 24 May 2011 18:07 > To: Ram Mohan R (rmohanr) > Cc: Elwell, John; siprec@ietf.org > Subject: Re: [siprec] What does an MS object represent? Can=20 > we pick one of theseoptions? >=20 >=20 >=20 > On 5/24/2011 12:52 PM, Ram Mohan R (rmohanr) wrote: > > Paul/ John, > > > > I am ok to add attribute "content" in MS block of the model. > > > > The question is do we want to map this attribute in the model to > > 1) The Session Description Protocol (SDP) Content Attribute=20 > defined in > > RFC 4796 OR > > 2)define our own content in the metadata XML which can take=20 > values as > > "audio" / "main video" / "presentation video" / "current=20 > speaker video" > > as suggested by John. >=20 > Well... >=20 > ISTM that if there is already an a=3Dcontent in the CS SDP,=20 > then we would=20 > want to report that in the metadata. >=20 > If there is a pair (one from offer, one from answer, same=20 > m-line offset)=20 > and there is *not* an a=3Dcontent that pairs them, then we=20 > would want to=20 > report it anyway. >=20 > But if we do that we have a problem with names and conflicts. rfc4796=20 > doesn't define a lot of names, nor does it say whether corresponding=20 > streams in offer & answer must have the same names. >=20 > So I think we have something similar but not quite the same,=20 > and we need=20 > to define something new. It must permit identifying streams=20 > even though=20 > we know nothing of their purpose. >=20 > Thanks, > Paul > = From john.elwell@siemens-enterprise.com Wed May 25 00:18:15 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9C1AE06B2 for ; Wed, 25 May 2011 00:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.469 X-Spam-Level: X-Spam-Status: No, score=-106.469 tagged_above=-999 required=5 tests=[AWL=0.130, 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 PP+LaYRAHSvn for ; Wed, 25 May 2011 00:18:15 -0700 (PDT) Received: from mail21.messagelabs.com (mail21.messagelabs.com [85.158.143.35]) by ietfa.amsl.com (Postfix) with SMTP id 8DB9BE069A for ; Wed, 25 May 2011 00:18:14 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-9.tower-21.messagelabs.com!1306307866!41502206!1 X-StarScan-Version: 6.2.16; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 4297 invoked from network); 25 May 2011 07:17:46 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-9.tower-21.messagelabs.com with SMTP; 25 May 2011 07:17:46 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 765B323F03E6; Wed, 25 May 2011 09:18: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, 25 May 2011 09:18:14 +0200 From: "Elwell, John" To: "Parthasarathi R (partr)" , "Charles Eckel (eckelcu)" , "Ram Mohan R (rmohanr)" , "siprec@ietf.org" Date: Wed, 25 May 2011 09:18:12 +0200 Thread-Topic: [siprec] Can an MS object span several CSs in a CSG? Thread-Index: AcwZ5UbR730mQiXZRGSqd4Xx2cnzHgAHpFKQAAkglcAAAc/qEAAHiqxwAARuZ7AAEv0wYA== Message-ID: References: <35BCE99A477D6A4986FB2216D8CF2CFD067EECD7@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 Subject: Re: [siprec] Can an MS object span several CSs in a CSG? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 25 May 2011 07:18:16 -0000 =20 > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com]=20 > Sent: 24 May 2011 23:14 > To: Charles Eckel (eckelcu); Ram Mohan R (rmohanr); Elwell,=20 > John; siprec@ietf.org > Subject: RE: [siprec] Can an MS object span several CSs in a CSG? >=20 > Hi Charles, >=20 > One of the usecase in my mind is discussed in > http://www.ietf.org/mail-archive/web/siprec/current/msg01890.html. The > details are 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. > 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). 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 [JRE] What harm is done (what do we lose) if, following transfer, A's media= stream is called MS3 and C's media stream is called MS4? MS3 can reference= the same SDP m-line (through a=3Dlabel) as MS1, and likewise MS4 could ref= erence the same SDP m-line as MS2, if we are concerned about recycling medi= a descriptions in RS SDP. John (as individual) >=20 > Thanks > Partha =20 >=20 > -----Original Message----- > From: Charles Eckel (eckelcu)=20 > Sent: Wednesday, May 25, 2011 1:39 AM > To: Ram Mohan R (rmohanr); Parthasarathi R (partr); 'Elwell, John'; > 'siprec@ietf.org' > Subject: RE: [siprec] Can an MS object span several CSs in a CSG? >=20 > Hi Ram, >=20 > I think that is many cases, they will be treated as separate=20 > MSs due to > the complexities you mention. However, I am trying to understand if > Partha feels allowing an SRC to treat them as a single MS is still > required. If not, then what is a use case? A concrete example=20 > would help > me, and potentially others, to better understand the motivation behind > Partha's requirement for modeling media from multiple CSs as a single > MS. >=20 > Cheers, > Charles >=20 > > -----Original Message----- > > From: Ram Mohan R (rmohanr) > > Sent: Tuesday, May 24, 2011 9:36 AM > > To: Charles Eckel (eckelcu); Parthasarathi R (partr); Elwell, John;=20 > > siprec@ietf.org > > Subject: RE: [siprec] Can an MS object span several CSs in a CSG? > >=20 > > Charles, > >=20 > > I did bring about this specific usecase of MMOH/MOH stream being=20 > > played to different participants earlier and suggested that=20 > they have=20 > > to treated as a same MS across multiple CSs (potentially recorded > using multiple RSs). > > Refer=20 > > http://www.ietf.org/mail-archive/web/siprec/current/msg01886.html > >=20 > > We had several discussions on it and it and several folks were in=20 > > favor of treating it as separate MS as there would be=20 > complexity in DB > design. > >=20 > > Regards, > > Ram > >=20 > >=20 > > > -----Original Message----- > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > > > Behalf Of Charles Eckel (eckelcu) > > > Sent: Tuesday, May 24, 2011 9:11 PM > > > To: Parthasarathi R (partr); Elwell, John; siprec@ietf.org > > > Subject: Re: [siprec] Can an MS object span several CSs in a CSG? > > > > > > Hi Partha, > > > > > > Is an example of this the same music on hold audio stream=20 > existing=20 > > > as the same MS within multiple CSs? If so, then I understand your=20 > > > requirement to be that the SRC be able to indicate multiple=20 > > > instances of this audio stream within several CSs as=20 > being the same=20 > > > MS. Is that correct? > > > > > > Thanks, > > > Charles > > > > > > > -----Original Message----- > > > > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On > > > Behalf Of Parthasarathi R (partr) > > > > Sent: Tuesday, May 24, 2011 4:26 AM > > > > To: Elwell, John; siprec@ietf.org > > > > Subject: Re: [siprec] Can an MS object span several CSs=20 > in a CSG? > > > > > > > > John, > > > > > > > > I agree that it is not mandatory to consider recorded=20 > stream of a=20 > > > > specific participant in several CS within the same CSG as one > > > recorded > > > > stream but SIPREC protocol design MUST NOT restrict a=20 > SRC in case=20 > > > > it wishes to design in such a way. > > > > > > > > Thanks > > > > Partha > > > > > > > > -----Original Message----- > > > > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On > > > Behalf > > > > Of Elwell, John > > > > Sent: Tuesday, May 24, 2011 1:06 PM > > > > To: siprec@ietf.org > > > > Subject: [siprec] Can an MS object span several CSs in a CSG? > > > > > > > > We seem to have consensus that a Media Stream object=20 > represents a=20 > > > > recorded media stream, contributed to by one, several or all=20 > > > > Participants. However, Partha also wrote: > > > > > > > > "2) Each MS lifetime related to CSG because participant=20 > may move=20 > > > > from one CS to another CS within single CSG and also=20 > CSG will span >=20 > > > > across multiple RS." > > > > > > > > I am not sure we had resolved this during earlier=20 > discussions on=20 > > > > the scope of an MS object. Although the same Participant can=20 > > > > participate > > > in > > > > several CSs within the same CSG, I don't think the=20 > recorded media=20 > > > > streams need to be considered the same. Any other views? > > > > > > > > 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 Wed May 25 00:47:41 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33465E06BE for ; Wed, 25 May 2011 00:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.383 X-Spam-Level: X-Spam-Status: No, score=-10.383 tagged_above=-999 required=5 tests=[AWL=0.216, 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 keQXC+HXWhlU for ; Wed, 25 May 2011 00:47:40 -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 89154E06B2 for ; Wed, 25 May 2011 00:47:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=7076; q=dns/txt; s=iport; t=1306309659; x=1307519259; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=2ntcycOaw1/k+F3g6RnC5uQqZDV7sWrNiD+xBHv0SHI=; b=PcHP37+FqPN4Ooatt5iWCUkaEKMpx9TRcOrTLj+YCRNX99eA9KXM+U1I OV2VRdnW7bL7jlwPU3ctOIFtonSvosNGQ//+/jHBuV2q8u0AFVc1unaNN 2BDp41UNNi0BJnCpS5ncIOr3as1p06+wDmztyUdLJIQLaCJaqyzLsm9rE A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjkBAJKz3E1Io8US/2dsb2JhbACXZY5FeIhwn0edeIYcBIZZjhWKTw X-IronPort-AV: E=Sophos;i="4.65,266,1304294400"; d="scan'208";a="90584074" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-1.cisco.com with ESMTP; 25 May 2011 07:47:37 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p4P7lafD017107; Wed, 25 May 2011 07:47: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); Wed, 25 May 2011 13:17: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, 25 May 2011 13:17:34 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Can an MS object span several CSs in a CSG? Thread-Index: AcwZ5UbR730mQiXZRGSqd4Xx2cnzHgAHpFKQAAkglcAAAc/qEAAHiqxwAARuZ7AAEv0wYAAASlPQ References: <35BCE99A477D6A4986FB2216D8CF2CFD067EECD7@XMB-BGL-417.cisco.com> From: "Parthasarathi R (partr)" To: "Elwell, John" , "Charles Eckel (eckelcu)" , "Ram Mohan R (rmohanr)" , X-OriginalArrivalTime: 25 May 2011 07:47:36.0079 (UTC) FILETIME=[036AA9F0:01CC1AB0] Subject: Re: [siprec] Can an MS object span several CSs in a CSG? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 25 May 2011 07:47:41 -0000 John, =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 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). There is no update on RS1, CSG1, MS1,=20 > MS2. MS2 will become MS2 with the new association and in terms of=20 > format, it will associate with tag [JRE] What harm is done (what do we lose) if, following transfer, A's media stream is called MS3 and C's media stream is called MS4?=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D To indicate MS1 as MS3, MS1 media block has to be stopped in the partial-update and start MS3 separate which is not required in case there is a means to have common MS1. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D MS3 can reference the same SDP m-line (through a=3Dlabel) as MS1, and likewise MS4 could reference the same SDP m-line as MS2, if we are concerned about recycling media descriptions in RS SDP. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D As you mentioned, we will lose recycling of media description in RS SDP without common value in media stream object for this scenario. AFAIK, Your proposal needs enhancement in RFC 4574 as label attribute scope is within single SIP message and not required to be unique in all SIP messages of a given dialog. =20 Thanks Partha John (as individual) >=20 > Thanks > Partha =20 >=20 > -----Original Message----- > From: Charles Eckel (eckelcu)=20 > Sent: Wednesday, May 25, 2011 1:39 AM > To: Ram Mohan R (rmohanr); Parthasarathi R (partr); 'Elwell, John'; > 'siprec@ietf.org' > Subject: RE: [siprec] Can an MS object span several CSs in a CSG? >=20 > Hi Ram, >=20 > I think that is many cases, they will be treated as separate=20 > MSs due to > the complexities you mention. However, I am trying to understand if > Partha feels allowing an SRC to treat them as a single MS is still > required. If not, then what is a use case? A concrete example=20 > would help > me, and potentially others, to better understand the motivation behind > Partha's requirement for modeling media from multiple CSs as a single > MS. >=20 > Cheers, > Charles >=20 > > -----Original Message----- > > From: Ram Mohan R (rmohanr) > > Sent: Tuesday, May 24, 2011 9:36 AM > > To: Charles Eckel (eckelcu); Parthasarathi R (partr); Elwell, John;=20 > > siprec@ietf.org > > Subject: RE: [siprec] Can an MS object span several CSs in a CSG? > >=20 > > Charles, > >=20 > > I did bring about this specific usecase of MMOH/MOH stream being=20 > > played to different participants earlier and suggested that=20 > they have=20 > > to treated as a same MS across multiple CSs (potentially recorded > using multiple RSs). > > Refer=20 > > http://www.ietf.org/mail-archive/web/siprec/current/msg01886.html > >=20 > > We had several discussions on it and it and several folks were in=20 > > favor of treating it as separate MS as there would be=20 > complexity in DB > design. > >=20 > > Regards, > > Ram > >=20 > >=20 > > > -----Original Message----- > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > > > Behalf Of Charles Eckel (eckelcu) > > > Sent: Tuesday, May 24, 2011 9:11 PM > > > To: Parthasarathi R (partr); Elwell, John; siprec@ietf.org > > > Subject: Re: [siprec] Can an MS object span several CSs in a CSG? > > > > > > Hi Partha, > > > > > > Is an example of this the same music on hold audio stream=20 > existing=20 > > > as the same MS within multiple CSs? If so, then I understand your=20 > > > requirement to be that the SRC be able to indicate multiple=20 > > > instances of this audio stream within several CSs as=20 > being the same=20 > > > MS. Is that correct? > > > > > > Thanks, > > > Charles > > > > > > > -----Original Message----- > > > > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On > > > Behalf Of Parthasarathi R (partr) > > > > Sent: Tuesday, May 24, 2011 4:26 AM > > > > To: Elwell, John; siprec@ietf.org > > > > Subject: Re: [siprec] Can an MS object span several CSs=20 > in a CSG? > > > > > > > > John, > > > > > > > > I agree that it is not mandatory to consider recorded=20 > stream of a=20 > > > > specific participant in several CS within the same CSG as one > > > recorded > > > > stream but SIPREC protocol design MUST NOT restrict a=20 > SRC in case=20 > > > > it wishes to design in such a way. > > > > > > > > Thanks > > > > Partha > > > > > > > > -----Original Message----- > > > > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On > > > Behalf > > > > Of Elwell, John > > > > Sent: Tuesday, May 24, 2011 1:06 PM > > > > To: siprec@ietf.org > > > > Subject: [siprec] Can an MS object span several CSs in a CSG? > > > > > > > > We seem to have consensus that a Media Stream object=20 > represents a=20 > > > > recorded media stream, contributed to by one, several or all=20 > > > > Participants. However, Partha also wrote: > > > > > > > > "2) Each MS lifetime related to CSG because participant=20 > may move=20 > > > > from one CS to another CS within single CSG and also=20 > CSG will span >=20 > > > > across multiple RS." > > > > > > > > I am not sure we had resolved this during earlier=20 > discussions on=20 > > > > the scope of an MS object. Although the same Participant can=20 > > > > participate > > > in > > > > several CSs within the same CSG, I don't think the=20 > recorded media=20 > > > > streams need to be considered the same. Any other views? > > > > > > > > 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 >=20 From john.elwell@siemens-enterprise.com Wed May 25 06:39: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 642F4E080C for ; Wed, 25 May 2011 06:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.173 X-Spam-Level: X-Spam-Status: No, score=-106.173 tagged_above=-999 required=5 tests=[AWL=-0.174, BAYES_00=-2.599, J_CHICKENPOX_17=0.6, 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 2TTvegRY7M0B for ; Wed, 25 May 2011 06:39:12 -0700 (PDT) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfa.amsl.com (Postfix) with SMTP id 688DCE080D for ; Wed, 25 May 2011 06:39:04 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1306330735!33041875!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 26250 invoked from network); 25 May 2011 13:38:55 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-10.tower-27.messagelabs.com with SMTP; 25 May 2011 13:38:55 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id E6D0B1EB83D3; Wed, 25 May 2011 15:39:02 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 25 May 2011 15:39:03 +0200 From: "Elwell, John" To: Paul Kyzivat , "Parthasarathi R (partr)" Date: Wed, 25 May 2011 15:39:01 +0200 Thread-Topic: [siprec] What does an MS object represent? Can we pick one of theseoptions? Thread-Index: AcwaWLs2pbmoNquTRJ2y6IhGpVs4dgAh9s9Q Message-ID: References: <4DDA89F2.50706@cisco.com> <4DDACA63.3010507@cisco.com><4DDBAB1F.8090505@cisco.com><4DDBC711.5090205@cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD067EECE1@XMB-BGL-417.cisco.com> <4DDBE5D1.7030704@cisco.com> <4DDC2166.6040502@cisco.com> In-Reply-To: <4DDC2166.6040502@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] What does an MS object represent? Can we pick one of theseoptions? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 25 May 2011 13:39:13 -0000 I don't see a need for yet another object class for this. I think a separat= e object for such a group is needed only if the group can have its own attr= ibutes, and I don't see a need for that. I had expected it to be just anoth= er attribute of the MS class. I am struggling for a name for the attribute,= but perhaps just "content" would suffice. MS objects having the same value= for this attribute would be implicitly grouped. John (as individual) > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 24 May 2011 22:22 > To: Parthasarathi R (partr) > Cc: siprec@ietf.org > Subject: Re: [siprec] What does an MS object represent? Can=20 > we pick one of theseoptions? >=20 >=20 >=20 > On 5/24/2011 2:17 PM, Parthasarathi R (partr) wrote: > > I agree with John that there is a need for relationship=20 > between MS for > > grouping. Also, I'm of the same opinion as Paul that=20 > "content" attribute > > may not serve this requirement. > > > > I had offline discussion with Ram, we think that new "media stream > > content group" metadata object may solve this issue. > > > > The half-baked idea is to > > > > 1) Create new optional "Media Stream Content Group" (MSCG) metadata > > object > > 2) MSCG is related to MS as [0..*]-[1..*] > > 3) MSCG is relate to CS as [0..*]- [1..*] > > > > Please let me know your opinion on the same. >=20 > This will presumably be used *a lot*, so its best if its not=20 > cumbersome. >=20 > It could be simpler if its limited to describing pairs of=20 > streams that=20 > are "mated". Then they could simply refer to one another. >=20 > It is perhaps more complex if you consider a conference, where each=20 > participant has a "pair", where one side is what it sends towards the=20 > focus and the other side is what it receives from the focus. Then the=20 > relationship is more complex. >=20 > We also *perhaps* need a way to represent the a=3Dcontent things in the=20 > CS. But that can be considered a separate problem. >=20 > Thanks, > Paul >=20 > > Thanks > > Partha > > > > > > -----Original Message----- > > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf > > Of Paul Kyzivat (pkyzivat) > > Sent: Tuesday, May 24, 2011 10:37 PM > > To: Ram Mohan R (rmohanr) > > Cc: siprec@ietf.org > > Subject: Re: [siprec] What does an MS object represent? Can=20 > we pick one > > of theseoptions? > > > > > > > > On 5/24/2011 12:52 PM, Ram Mohan R (rmohanr) wrote: > >> Paul/ John, > >> > >> I am ok to add attribute "content" in MS block of the model. > >> > >> The question is do we want to map this attribute in the model to > >> 1) The Session Description Protocol (SDP) Content=20 > Attribute defined in > > > >> RFC 4796 OR 2)define our own content in the metadata XML which can > >> take values as "audio" / "main video" / "presentation video" / > >> "current speaker video" > >> as suggested by John. > > > > Well... > > > > ISTM that if there is already an a=3Dcontent in the CS SDP,=20 > then we would > > want to report that in the metadata. > > > > If there is a pair (one from offer, one from answer, same=20 > m-line offset) > > and there is *not* an a=3Dcontent that pairs them, then we=20 > would want to > > report it anyway. > > > > But if we do that we have a problem with names and=20 > conflicts. rfc4796 > > doesn't define a lot of names, nor does it say whether corresponding > > streams in offer& answer must have the same names. > > > > So I think we have something similar but not quite the=20 > same, and we need > > to define something new. It must permit identifying streams=20 > even though > > we know nothing of their purpose. > > > > 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 john.elwell@siemens-enterprise.com Wed May 25 06:46: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 2B17BE07FC for ; Wed, 25 May 2011 06:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.468 X-Spam-Level: X-Spam-Status: No, score=-106.468 tagged_above=-999 required=5 tests=[AWL=0.131, 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 w7VApVe-rSC0 for ; Wed, 25 May 2011 06:46:45 -0700 (PDT) Received: from mail216.messagelabs.com (mail216.messagelabs.com [85.158.143.99]) by ietfa.amsl.com (Postfix) with SMTP id CBDCBE072C for ; Wed, 25 May 2011 06:46:44 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1306331203!6081133!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 18893 invoked from network); 25 May 2011 13:46:43 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-13.tower-216.messagelabs.com with SMTP; 25 May 2011 13:46:43 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 28CC41EB83D3; Wed, 25 May 2011 15:46: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, 25 May 2011 15:46:43 +0200 From: "Elwell, John" To: "Parthasarathi R (partr)" , "Charles Eckel (eckelcu)" , "Ram Mohan R (rmohanr)" , "siprec@ietf.org" Date: Wed, 25 May 2011 15:46:41 +0200 Thread-Topic: [siprec] Can an MS object span several CSs in a CSG? Thread-Index: AcwZ5UbR730mQiXZRGSqd4Xx2cnzHgAHpFKQAAkglcAAAc/qEAAHiqxwAARuZ7AAEv0wYAAASlPQAA0tNiA= Message-ID: References: <35BCE99A477D6A4986FB2216D8CF2CFD067EECD7@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 Subject: Re: [siprec] Can an MS object span several CSs in a CSG? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 25 May 2011 13:46:46 -0000 =20 > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com]=20 > Sent: 25 May 2011 08:48 > To: Elwell, John; Charles Eckel (eckelcu); Ram Mohan R=20 > (rmohanr); siprec@ietf.org > Subject: RE: [siprec] Can an MS object span several CSs in a CSG? >=20 > John, >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > 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). There is no update on RS1,=20 > CSG1, MS1,=20 > > MS2. MS2 will become MS2 with the new association and in terms of=20 > > format, it will associate with tag > [JRE] What harm is done (what do we lose) if, following transfer, A's > media stream is called MS3 and C's media stream is called MS4?=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > To indicate MS1 as MS3, MS1 media block has to be stopped in > the partial-update and start MS3 separate which is not=20 > required in case > there is a means to have common MS1. [JRE] It seems this distorts the model in order to give some minor efficien= cy improvement during metadata updates. I doubt that this alone is sufficie= nt justification for having the MS persist from one CS to another CS. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > MS3 can reference the same SDP m-line (through a=3Dlabel) as MS1, and > likewise MS4 could reference the same SDP m-line as MS2, if we are > concerned about recycling media descriptions in RS SDP. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > As you mentioned, we will lose recycling of media description > in RS SDP without common value in media stream object for=20 > this scenario. [JRE] I don't understand your point. With my proposal we can still recycle = RS SDP m-lines. > AFAIK, Your proposal needs enhancement in RFC 4574 as label attribute > scope is within single SIP message and not required to be=20 > unique in all > SIP messages of a given dialog. =20 [JRE] But I think we could nail that down as a requirement of the SIPREC pr= otocol. John (as individual) >=20 > Thanks > Partha >=20 > John (as individual) >=20 > >=20 > > Thanks > > Partha =20 > >=20 > > -----Original Message----- > > From: Charles Eckel (eckelcu)=20 > > Sent: Wednesday, May 25, 2011 1:39 AM > > To: Ram Mohan R (rmohanr); Parthasarathi R (partr); 'Elwell, John'; > > 'siprec@ietf.org' > > Subject: RE: [siprec] Can an MS object span several CSs in a CSG? > >=20 > > Hi Ram, > >=20 > > I think that is many cases, they will be treated as separate=20 > > MSs due to > > the complexities you mention. However, I am trying to understand if > > Partha feels allowing an SRC to treat them as a single MS is still > > required. If not, then what is a use case? A concrete example=20 > > would help > > me, and potentially others, to better understand the=20 > motivation behind > > Partha's requirement for modeling media from multiple CSs=20 > as a single > > MS. > >=20 > > Cheers, > > Charles > >=20 > > > -----Original Message----- > > > From: Ram Mohan R (rmohanr) > > > Sent: Tuesday, May 24, 2011 9:36 AM > > > To: Charles Eckel (eckelcu); Parthasarathi R (partr);=20 > Elwell, John;=20 > > > siprec@ietf.org > > > Subject: RE: [siprec] Can an MS object span several CSs in a CSG? > > >=20 > > > Charles, > > >=20 > > > I did bring about this specific usecase of MMOH/MOH stream being=20 > > > played to different participants earlier and suggested that=20 > > they have=20 > > > to treated as a same MS across multiple CSs (potentially recorded > > using multiple RSs). > > > Refer=20 > > > http://www.ietf.org/mail-archive/web/siprec/current/msg01886.html > > >=20 > > > We had several discussions on it and it and several folks were in=20 > > > favor of treating it as separate MS as there would be=20 > > complexity in DB > > design. > > >=20 > > > Regards, > > > Ram > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On=20 > > > > Behalf Of Charles Eckel (eckelcu) > > > > Sent: Tuesday, May 24, 2011 9:11 PM > > > > To: Parthasarathi R (partr); Elwell, John; siprec@ietf.org > > > > Subject: Re: [siprec] Can an MS object span several CSs=20 > in a CSG? > > > > > > > > Hi Partha, > > > > > > > > Is an example of this the same music on hold audio stream=20 > > existing=20 > > > > as the same MS within multiple CSs? If so, then I=20 > understand your=20 > > > > requirement to be that the SRC be able to indicate multiple=20 > > > > instances of this audio stream within several CSs as=20 > > being the same=20 > > > > MS. Is that correct? > > > > > > > > Thanks, > > > > Charles > > > > > > > > > -----Original Message----- > > > > > From: siprec-bounces@ietf.org=20 > > [mailto:siprec-bounces@ietf.org] On > > > > Behalf Of Parthasarathi R (partr) > > > > > Sent: Tuesday, May 24, 2011 4:26 AM > > > > > To: Elwell, John; siprec@ietf.org > > > > > Subject: Re: [siprec] Can an MS object span several CSs=20 > > in a CSG? > > > > > > > > > > John, > > > > > > > > > > I agree that it is not mandatory to consider recorded=20 > > stream of a=20 > > > > > specific participant in several CS within the same CSG as one > > > > recorded > > > > > stream but SIPREC protocol design MUST NOT restrict a=20 > > SRC in case=20 > > > > > it wishes to design in such a way. > > > > > > > > > > Thanks > > > > > Partha > > > > > > > > > > -----Original Message----- > > > > > From: siprec-bounces@ietf.org=20 > > [mailto:siprec-bounces@ietf.org] On > > > > Behalf > > > > > Of Elwell, John > > > > > Sent: Tuesday, May 24, 2011 1:06 PM > > > > > To: siprec@ietf.org > > > > > Subject: [siprec] Can an MS object span several CSs in a CSG? > > > > > > > > > > We seem to have consensus that a Media Stream object=20 > > represents a=20 > > > > > recorded media stream, contributed to by one, several or all=20 > > > > > Participants. However, Partha also wrote: > > > > > > > > > > "2) Each MS lifetime related to CSG because participant=20 > > may move=20 > > > > > from one CS to another CS within single CSG and also=20 > > CSG will span > >=20 > > > > > across multiple RS." > > > > > > > > > > I am not sure we had resolved this during earlier=20 > > discussions on=20 > > > > > the scope of an MS object. Although the same Participant can=20 > > > > > participate > > > > in > > > > > several CSs within the same CSG, I don't think the=20 > > recorded media=20 > > > > > streams need to be considered the same. Any other views? > > > > > > > > > > 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 > >=20 > = From partr@cisco.com Thu May 26 07:55:29 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09FE1E06B2 for ; Thu, 26 May 2011 07:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.407 X-Spam-Level: X-Spam-Status: No, score=-10.407 tagged_above=-999 required=5 tests=[AWL=0.192, 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 2lqM9Znup5PY for ; Thu, 26 May 2011 07:55:27 -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 19B12E0657 for ; Thu, 26 May 2011 07:55:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=9972; q=dns/txt; s=iport; t=1306421727; x=1307631327; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=7RHdT7rpoKWJTwTDAVekUPRxNDsgeHJHSJuWds0wynw=; b=eiWL1zOTDPhN5TkHHCqIRuO8HVLYSo/lZhPN8hJxfFPcD5cH13Ca7Ouw amjufz/MX1RjMP70YSGWsbE+DfIxGiwWctjtmkKhCqZsICF01LaDQmcQe RGFeElp/geLnBJEZTTseZpeZSO7VfVW8yEqaVEanBVOq+TmALm5WsYgkW I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8BALFo3k1Io8UQ/2dsb2JhbABUl2aOSniIcKAcnViGHASGX44cilY X-IronPort-AV: E=Sophos;i="4.65,273,1304294400"; d="scan'208";a="32452541" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-2.cisco.com with ESMTP; 26 May 2011 14:55:25 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4QEtNbg026036; Thu, 26 May 2011 14:55: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); Thu, 26 May 2011 20:25:23 +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, 26 May 2011 20:25:21 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Can an MS object span several CSs in a CSG? Thread-Index: AcwZ5UbR730mQiXZRGSqd4Xx2cnzHgAHpFKQAAkglcAAAc/qEAAHiqxwAARuZ7AAEv0wYAAASlPQAA0tNiAAM/kssA== References: <35BCE99A477D6A4986FB2216D8CF2CFD067EECD7@XMB-BGL-417.cisco.com> From: "Parthasarathi R (partr)" To: "Elwell, John" , "Charles Eckel (eckelcu)" , "Ram Mohan R (rmohanr)" , X-OriginalArrivalTime: 26 May 2011 14:55:23.0310 (UTC) FILETIME=[F0B10CE0:01CC1BB4] Subject: Re: [siprec] Can an MS object span several CSs in a CSG? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 14:55:29 -0000 John, The callflow mentioned by me is the basic primitive in the call center scenario wherein customer (participant) is same throughout the session and agents are changed using transfer service and B2BUA acts as SRC. IMO, it is one of key requirement to be considered in case we support for partial-update. This may not be the only callflow where MS partial-update is required in this fashion. During -00 format draft, I thought that the partial-update is not required but lot of folks raised the concern that partial update is important. Current, -01 format draft is designed to support partial-update. Now, You propose to restrict MS partial-update across CS. IMO, it is a not good idea to restrict in the protocol level. Anyway, I think that we need others opinion before conclude here. Enhancing label attribute across the multiple SIP message to tie between Metadata XML and RS SDP m-line is possible. SRC has to ensure that label for the given RS SDP m-line should have same label throughout single CSG even though it span across multiple CS and multiple RS. Even then, it will not meet partial-update requirement as mentioned below in this mail thread. At this moment, I'm favoring URN UUID and not label attribute enhancement. =20 Please read inline Thanks Partha -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 Sent: Wednesday, May 25, 2011 7:17 PM To: Parthasarathi R (partr); Charles Eckel (eckelcu); Ram Mohan R (rmohanr); siprec@ietf.org Subject: RE: [siprec] Can an MS object span several CSs in a CSG? =20 > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > Sent: 25 May 2011 08:48 > To: Elwell, John; Charles Eckel (eckelcu); Ram Mohan R (rmohanr);=20 > siprec@ietf.org > Subject: RE: [siprec] Can an MS object span several CSs in a CSG? >=20 > John, >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > 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). 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 > [JRE] What harm is done (what do we lose) if, following transfer, A's=20 > media stream is called MS3 and C's media stream is called MS4? > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > To indicate MS1 as MS3, MS1 media block has to be stopped in=20 > the partial-update and start MS3 separate which is not required in=20 > case there is a means to have common MS1. [JRE] It seems this distorts the model in order to give some minor efficiency improvement during metadata updates. I doubt that this alone is sufficient justification for having the MS persist from one CS to another CS. >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > MS3 can reference the same SDP m-line (through a=3Dlabel) as MS1, and > likewise MS4 could reference the same SDP m-line as MS2, if we are > concerned about recycling media descriptions in RS SDP. > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > As you mentioned, we will lose recycling of media description > in RS SDP without common value in media stream object for=20 > this scenario. [JRE] I don't understand your point. With my proposal we can still recycle RS SDP m-lines. Agreed that Recycle is possible with your proposal. I indicated the need for unique-id in this requirement > AFAIK, Your proposal needs enhancement in RFC 4574 as label attribute > scope is within single SIP message and not required to be=20 > unique in all > SIP messages of a given dialog. =20 [JRE] But I think we could nail that down as a requirement of the SIPREC protocol. John (as individual) >=20 > Thanks > Partha >=20 > John (as individual) >=20 > >=20 > > Thanks > > Partha =20 > >=20 > > -----Original Message----- > > From: Charles Eckel (eckelcu)=20 > > Sent: Wednesday, May 25, 2011 1:39 AM > > To: Ram Mohan R (rmohanr); Parthasarathi R (partr); 'Elwell, John'; > > 'siprec@ietf.org' > > Subject: RE: [siprec] Can an MS object span several CSs in a CSG? > >=20 > > Hi Ram, > >=20 > > I think that is many cases, they will be treated as separate=20 > > MSs due to > > the complexities you mention. However, I am trying to understand if > > Partha feels allowing an SRC to treat them as a single MS is still > > required. If not, then what is a use case? A concrete example=20 > > would help > > me, and potentially others, to better understand the=20 > motivation behind > > Partha's requirement for modeling media from multiple CSs=20 > as a single > > MS. > >=20 > > Cheers, > > Charles > >=20 > > > -----Original Message----- > > > From: Ram Mohan R (rmohanr) > > > Sent: Tuesday, May 24, 2011 9:36 AM > > > To: Charles Eckel (eckelcu); Parthasarathi R (partr);=20 > Elwell, John;=20 > > > siprec@ietf.org > > > Subject: RE: [siprec] Can an MS object span several CSs in a CSG? > > >=20 > > > Charles, > > >=20 > > > I did bring about this specific usecase of MMOH/MOH stream being=20 > > > played to different participants earlier and suggested that=20 > > they have=20 > > > to treated as a same MS across multiple CSs (potentially recorded > > using multiple RSs). > > > Refer=20 > > > http://www.ietf.org/mail-archive/web/siprec/current/msg01886.html > > >=20 > > > We had several discussions on it and it and several folks were in=20 > > > favor of treating it as separate MS as there would be=20 > > complexity in DB > > design. > > >=20 > > > Regards, > > > Ram > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On=20 > > > > Behalf Of Charles Eckel (eckelcu) > > > > Sent: Tuesday, May 24, 2011 9:11 PM > > > > To: Parthasarathi R (partr); Elwell, John; siprec@ietf.org > > > > Subject: Re: [siprec] Can an MS object span several CSs=20 > in a CSG? > > > > > > > > Hi Partha, > > > > > > > > Is an example of this the same music on hold audio stream=20 > > existing=20 > > > > as the same MS within multiple CSs? If so, then I=20 > understand your=20 > > > > requirement to be that the SRC be able to indicate multiple=20 > > > > instances of this audio stream within several CSs as=20 > > being the same=20 > > > > MS. Is that correct? > > > > > > > > Thanks, > > > > Charles > > > > > > > > > -----Original Message----- > > > > > From: siprec-bounces@ietf.org=20 > > [mailto:siprec-bounces@ietf.org] On > > > > Behalf Of Parthasarathi R (partr) > > > > > Sent: Tuesday, May 24, 2011 4:26 AM > > > > > To: Elwell, John; siprec@ietf.org > > > > > Subject: Re: [siprec] Can an MS object span several CSs=20 > > in a CSG? > > > > > > > > > > John, > > > > > > > > > > I agree that it is not mandatory to consider recorded=20 > > stream of a=20 > > > > > specific participant in several CS within the same CSG as one > > > > recorded > > > > > stream but SIPREC protocol design MUST NOT restrict a=20 > > SRC in case=20 > > > > > it wishes to design in such a way. > > > > > > > > > > Thanks > > > > > Partha > > > > > > > > > > -----Original Message----- > > > > > From: siprec-bounces@ietf.org=20 > > [mailto:siprec-bounces@ietf.org] On > > > > Behalf > > > > > Of Elwell, John > > > > > Sent: Tuesday, May 24, 2011 1:06 PM > > > > > To: siprec@ietf.org > > > > > Subject: [siprec] Can an MS object span several CSs in a CSG? > > > > > > > > > > We seem to have consensus that a Media Stream object=20 > > represents a=20 > > > > > recorded media stream, contributed to by one, several or all=20 > > > > > Participants. However, Partha also wrote: > > > > > > > > > > "2) Each MS lifetime related to CSG because participant=20 > > may move=20 > > > > > from one CS to another CS within single CSG and also=20 > > CSG will span > >=20 > > > > > across multiple RS." > > > > > > > > > > I am not sure we had resolved this during earlier=20 > > discussions on=20 > > > > > the scope of an MS object. Although the same Participant can=20 > > > > > participate > > > > in > > > > > several CSs within the same CSG, I don't think the=20 > > recorded media=20 > > > > > streams need to be considered the same. Any other views? > > > > > > > > > > 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 > >=20 >=20 From john.elwell@siemens-enterprise.com Fri May 27 02:25: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 0A419E065B for ; Fri, 27 May 2011 02:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.486 X-Spam-Level: X-Spam-Status: No, score=-106.486 tagged_above=-999 required=5 tests=[AWL=0.113, 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 2KmWGGdKU5IZ for ; Fri, 27 May 2011 02:25:50 -0700 (PDT) Received: from mail182.messagelabs.com (mail182.messagelabs.com [85.158.139.83]) by ietfa.amsl.com (Postfix) with SMTP id 17F78E07BB for ; Fri, 27 May 2011 02:25:49 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1306488348!7016223!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 26139 invoked from network); 27 May 2011 09:25:48 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-15.tower-182.messagelabs.com with SMTP; 27 May 2011 09:25:48 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id A87F423F03E6; Fri, 27 May 2011 11:25:48 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 27 May 2011 11:25:48 +0200 From: "Elwell, John" To: "Parthasarathi R (partr)" , "Charles Eckel (eckelcu)" , "Ram Mohan R (rmohanr)" , "siprec@ietf.org" Date: Fri, 27 May 2011 11:25:47 +0200 Thread-Topic: [siprec] Can an MS object span several CSs in a CSG? Thread-Index: AcwZ5UbR730mQiXZRGSqd4Xx2cnzHgAHpFKQAAkglcAAAc/qEAAHiqxwAARuZ7AAEv0wYAAASlPQAA0tNiAAM/kssAAEs2ag Message-ID: References: <35BCE99A477D6A4986FB2216D8CF2CFD067EECD7@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 Subject: Re: [siprec] Can an MS object span several CSs in a CSG? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 09:25:52 -0000 =20 > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com]=20 > Sent: 26 May 2011 15:55 > To: Elwell, John; Charles Eckel (eckelcu); Ram Mohan R=20 > (rmohanr); siprec@ietf.org > Subject: RE: [siprec] Can an MS object span several CSs in a CSG? >=20 > John, >=20 > The callflow mentioned by me is the basic primitive in the call center > scenario wherein customer (participant) is same throughout the session > and agents are changed using transfer service and B2BUA acts as SRC. > IMO, it is one of key requirement to be considered in case we support > for partial-update.=20 [JRE] Agreed the Participant remains the same, but we are discussing MS. > This may not be the only callflow where MS > partial-update is required in this fashion. During -00 format draft, I > thought that the partial-update is not required but lot of=20 > folks raised > the concern that partial update is important. Current, -01=20 > format draft > is designed to support partial-update. Now, You propose to restrict MS > partial-update across CS. IMO, it is a not good idea to=20 > restrict in the > protocol level. Anyway, I think that we need others opinion before > conclude here. [JRE] I am not opposed to partial update, but I would like to avoid distort= ing the model just to gain some efficiency improvements in certain cases. T= o me it is not intuitive that a MS on one CS and an MS on another CS are th= e same object, just because one of the Participants is common to both CSs. = In the transfer-between-agents example, although one of the Participants is= common to the two CSs, this is not true for the other Participants. Let's try to quantify the efficiency improvement. In the blind transfer cas= e, the partial updates would at least have to include: - the removal of P1 from CS1 (where P1 is the first agent and CS1 is the fi= rst CS); - the removal of P2 from CS1 (where P2 is the transferred participant); - the termination of CS1; - the removal of CS1 from CSG1; - the creation of CS2 (the CS that results from transfer); - the addition to of CS2 to CSG1; - the addition of P2 to CSG1; - the addition of P3 to CS2 (where P3 is the second agent); - the removal of P1 as a sender of MS1 (MS1 is from P1 to P2); - the removal of P2 as a recipient of MS1; - the termination of MS1; - the creation of MS3; - the addition of P3 as a sender of MS3; - the addition of P2 as a recipient of MS3. So all we are arguing about is whether we also include in the partial updat= es EITHER (this I think is your proposal): - the removal of P1 as a recipient of MS2; - the addition of P3 as a recipient of MS2; OR - the removal of P1 as recipient of MS2; - the removal of P2 as a sender of MS2; - the termination MS2; - the creation of MS4; - the addition of P3 as a recipient of MS4; - the addition of P2 as a sender of MS4. So with the first option the total number of deltas is 14+2=3D16. For the second option the total number of deltas is 14+6=3D20. Some of the details might be wrong, but I hope you can see the point I am g= etting at. Looked at this way, the efficiency saving by recycling MS2 for u= se in consecutive CSs is relatively small. Or perhaps your intention is als= o to recycle MS1 (this time, the recipient remaining the same but the sende= r changing). That would reduce the number of deltas slightly further. The i= mpact on XML size might not be quite in proportion to the reduction in the = number of deltas, since by recycling MS2 it has to have a global identifier= , not an identifier local to a CS. Or perhaps it could have an identifier l= ocal to a CSG. I also see that with your proposal it doesn't force the MS to be recycled -= an SRC could still choose to model it as separate MSs. However, in that ca= se it would still need to use global identifiers for MSs. I am not necessarily opposed to your proposal for recycling MS objects outs= ide the context of a single CS - I can see advantages and disadvantages. I = just want to make sure the group makes an informed decision. John (as individual) >=20 > Enhancing label attribute across the multiple SIP message to=20 > tie between > Metadata XML and RS SDP m-line is possible. SRC has to ensure=20 > that label > for the given RS SDP m-line should have same label throughout=20 > single CSG > even though it span across multiple CS and multiple RS. Even then, it > will not meet partial-update requirement as mentioned below=20 > in this mail > thread. At this moment, I'm favoring URN UUID and not label attribute > enhancement. =20 >=20 > Please read inline >=20 > Thanks > Partha >=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > Sent: Wednesday, May 25, 2011 7:17 PM > To: Parthasarathi R (partr); Charles Eckel (eckelcu); Ram Mohan R > (rmohanr); siprec@ietf.org > Subject: RE: [siprec] Can an MS object span several CSs in a CSG? >=20 > =20 >=20 > > -----Original Message----- > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > Sent: 25 May 2011 08:48 > > To: Elwell, John; Charles Eckel (eckelcu); Ram Mohan R (rmohanr);=20 > > siprec@ietf.org > > Subject: RE: [siprec] Can an MS object span several CSs in a CSG? > >=20 > > John, > >=20 > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > 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). 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 > > [JRE] What harm is done (what do we lose) if, following=20 > transfer, A's=20 > > media stream is called MS3 and C's media stream is called MS4? > >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > To indicate MS1 as MS3, MS1 media block has to be=20 > stopped in=20 > > the partial-update and start MS3 separate which is not required in=20 > > case there is a means to have common MS1. > [JRE] It seems this distorts the model in order to give some minor > efficiency improvement during metadata updates. I doubt that=20 > this alone > is sufficient justification for having the MS persist from one CS to > another CS. >=20 > >=20 > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > MS3 can reference the same SDP m-line (through a=3Dlabel) as MS1, and > > likewise MS4 could reference the same SDP m-line as MS2, if we are > > concerned about recycling media descriptions in RS SDP. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > As you mentioned, we will lose recycling of media=20 > description > > in RS SDP without common value in media stream object for=20 > > this scenario. > [JRE] I don't understand your point. With my proposal we can still > recycle RS SDP m-lines. >=20 > Agreed that Recycle is possible with your proposal.=20 > I indicated > the need for unique-id in this requirement >=20 > > AFAIK, Your proposal needs enhancement in RFC 4574 as label=20 > attribute > > scope is within single SIP message and not required to be=20 > > unique in all > > SIP messages of a given dialog. =20 > [JRE] But I think we could nail that down as a requirement of=20 > the SIPREC > protocol. >=20 > John (as individual) >=20 > >=20 > > Thanks > > Partha > >=20 > > John (as individual) > >=20 > > >=20 > > > Thanks > > > Partha =20 > > >=20 > > > -----Original Message----- > > > From: Charles Eckel (eckelcu)=20 > > > Sent: Wednesday, May 25, 2011 1:39 AM > > > To: Ram Mohan R (rmohanr); Parthasarathi R (partr);=20 > 'Elwell, John'; > > > 'siprec@ietf.org' > > > Subject: RE: [siprec] Can an MS object span several CSs in a CSG? > > >=20 > > > Hi Ram, > > >=20 > > > I think that is many cases, they will be treated as separate=20 > > > MSs due to > > > the complexities you mention. However, I am trying to=20 > understand if > > > Partha feels allowing an SRC to treat them as a single MS is still > > > required. If not, then what is a use case? A concrete example=20 > > > would help > > > me, and potentially others, to better understand the=20 > > motivation behind > > > Partha's requirement for modeling media from multiple CSs=20 > > as a single > > > MS. > > >=20 > > > Cheers, > > > Charles > > >=20 > > > > -----Original Message----- > > > > From: Ram Mohan R (rmohanr) > > > > Sent: Tuesday, May 24, 2011 9:36 AM > > > > To: Charles Eckel (eckelcu); Parthasarathi R (partr);=20 > > Elwell, John;=20 > > > > siprec@ietf.org > > > > Subject: RE: [siprec] Can an MS object span several CSs=20 > in a CSG? > > > >=20 > > > > Charles, > > > >=20 > > > > I did bring about this specific usecase of MMOH/MOH=20 > stream being=20 > > > > played to different participants earlier and suggested that=20 > > > they have=20 > > > > to treated as a same MS across multiple CSs=20 > (potentially recorded > > > using multiple RSs). > > > > Refer=20 > > > >=20 > http://www.ietf.org/mail-archive/web/siprec/current/msg01886.html > > > >=20 > > > > We had several discussions on it and it and several=20 > folks were in=20 > > > > favor of treating it as separate MS as there would be=20 > > > complexity in DB > > > design. > > > >=20 > > > > Regards, > > > > Ram > > > >=20 > > > >=20 > > > > > -----Original Message----- > > > > > From: siprec-bounces@ietf.org=20 > > [mailto:siprec-bounces@ietf.org] On=20 > > > > > Behalf Of Charles Eckel (eckelcu) > > > > > Sent: Tuesday, May 24, 2011 9:11 PM > > > > > To: Parthasarathi R (partr); Elwell, John; siprec@ietf.org > > > > > Subject: Re: [siprec] Can an MS object span several CSs=20 > > in a CSG? > > > > > > > > > > Hi Partha, > > > > > > > > > > Is an example of this the same music on hold audio stream=20 > > > existing=20 > > > > > as the same MS within multiple CSs? If so, then I=20 > > understand your=20 > > > > > requirement to be that the SRC be able to indicate multiple=20 > > > > > instances of this audio stream within several CSs as=20 > > > being the same=20 > > > > > MS. Is that correct? > > > > > > > > > > Thanks, > > > > > Charles > > > > > > > > > > > -----Original Message----- > > > > > > From: siprec-bounces@ietf.org=20 > > > [mailto:siprec-bounces@ietf.org] On > > > > > Behalf Of Parthasarathi R (partr) > > > > > > Sent: Tuesday, May 24, 2011 4:26 AM > > > > > > To: Elwell, John; siprec@ietf.org > > > > > > Subject: Re: [siprec] Can an MS object span several CSs=20 > > > in a CSG? > > > > > > > > > > > > John, > > > > > > > > > > > > I agree that it is not mandatory to consider recorded=20 > > > stream of a=20 > > > > > > specific participant in several CS within the same=20 > CSG as one > > > > > recorded > > > > > > stream but SIPREC protocol design MUST NOT restrict a=20 > > > SRC in case=20 > > > > > > it wishes to design in such a way. > > > > > > > > > > > > Thanks > > > > > > Partha > > > > > > > > > > > > -----Original Message----- > > > > > > From: siprec-bounces@ietf.org=20 > > > [mailto:siprec-bounces@ietf.org] On > > > > > Behalf > > > > > > Of Elwell, John > > > > > > Sent: Tuesday, May 24, 2011 1:06 PM > > > > > > To: siprec@ietf.org > > > > > > Subject: [siprec] Can an MS object span several CSs=20 > in a CSG? > > > > > > > > > > > > We seem to have consensus that a Media Stream object=20 > > > represents a=20 > > > > > > recorded media stream, contributed to by one,=20 > several or all=20 > > > > > > Participants. However, Partha also wrote: > > > > > > > > > > > > "2) Each MS lifetime related to CSG because participant=20 > > > may move=20 > > > > > > from one CS to another CS within single CSG and also=20 > > > CSG will span > > >=20 > > > > > > across multiple RS." > > > > > > > > > > > > I am not sure we had resolved this during earlier=20 > > > discussions on=20 > > > > > > the scope of an MS object. Although the same=20 > Participant can=20 > > > > > > participate > > > > > in > > > > > > several CSs within the same CSG, I don't think the=20 > > > recorded media=20 > > > > > > streams need to be considered the same. Any other views? > > > > > > > > > > > > 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 > > >=20 > >=20 > = From Leon.Portman@nice.com Sun May 29 06:28:50 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68DE2E070E for ; Sun, 29 May 2011 06:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.648 X-Spam-Level: X-Spam-Status: No, score=-0.648 tagged_above=-999 required=5 tests=[AWL=-1.250, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_25=0.6] 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 kyU3tgxWgsJo for ; Sun, 29 May 2011 06:28:41 -0700 (PDT) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id 1464AE0681 for ; Sun, 29 May 2011 06:28:40 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.15]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Sun, 29 May 2011 16:28:38 +0300 From: Leon Portman To: "siprec@ietf.org" , "Elwell, John" , "Ken Rehor (krehor) (krehor@cisco.com)" , "andrew.hutton@siemens-enterprise.com" , "rajnish.jain@ipc.com" Date: Sun, 29 May 2011 16:28:37 +0300 Thread-Topic: [siprec] IESG review for requirement draft - ver 11 Thread-Index: Acwd+349TCB5wzK6S36z2oNOVcrHrQ== Message-ID: <07465C1D981ABC41A344374066AE1A2C38AC24E597@TLVMBX01.nice.com> Accept-Language: en-US, he-IL Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US, he-IL Content-Type: multipart/mixed; boundary="_004_07465C1D981ABC41A344374066AE1A2C38AC24E597TLVMBX01nicec_" MIME-Version: 1.0 Subject: [siprec] IESG review for requirement draft - ver 11 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2011 13:28:50 -0000 --_004_07465C1D981ABC41A344374066AE1A2C38AC24E597TLVMBX01nicec_ Content-Type: multipart/alternative; boundary="_000_07465C1D981ABC41A344374066AE1A2C38AC24E597TLVMBX01nicec_" --_000_07465C1D981ABC41A344374066AE1A2C38AC24E597TLVMBX01nicec_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Please see below list of main changes following IESG review. We need to rec= eive comments or objection as fast as possible. 1. Removed REQ-25 because it is confusing and does not provide any sp= ecific requirements for RS and CS keys relationship (all configurations sho= uld be supported). It is too solution oriented. REQ-31 is generic enough f= or ensuring RS confidentiality. 2. Added text to REQ-017 in order to cover also how UA will know rega= rding success of failure of recording preferences requests: REQ-017: The mechanism MUST support a means for a recording-aware UA involv= ed in a CS to request during a session that the recording of t= he CS should be started, paused, resumed or stopped, the honoring of such a request = being dependent on policy. Such recording-aware UA MUST be notified about outcome of s= uch requests. 3. Removed "non-repudiation" examples from "Privacy Consideration" an= d "Security Considerations" sections, because it is not clear what are spec= ific requirements. 4. Removed second "integrity" from the last paragraph of "Security Co= nsiderations" section in order to remove confusion that we are talking abou= t protection of SRC and not data on the wire. 5. Minor rephrase of a paragraph in "Introduction" (starting with "= Furthemore..") 6. REQ-005 - Add reference to RS in loss of media sentence 7. REQ-012 - change "indentities" to " identifiers " 8. Added RFC 4949 reference for security considerations 9. Added timelines to figures Attached updated draft ver-11 Leon --_000_07465C1D981ABC41A344374066AE1A2C38AC24E597TLVMBX01nicec_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello=

 

Please s= ee below list of main changes following IESG review. We need to receive com= ments or objection as fast as possible.

=  

1.   &nbs= p;   Removed REQ-2= 5 because it is confusing and does not pro= vide any specific requirements for RS and CS keys relationship (all configu= rations should be supported). It is too solution oriented.  REQ-31 is = generic enough for ensuring RS confidentiality.

2.       Added text to REQ-017 in order = to cover also how UA will know regarding success of failure of recording pr= eferences requests:

REQ-017: The mechanism MUST support a means for a recording-aw= are UA involved

           =      in a CS to request during a session that the recor= ding of the CS  should be started,

       =          paused, resumed or stopped= , the honoring of such a request being dependent on policy.

<= p class=3DMsoPlainText style=3D'margin-left:36.0pt'>    = ;            Such recording-aware UA MUST be notified about outcome o= f such requests.

3.       Removed "non-repudiation" examples from "= Privacy Consideration" and "Security Considerations" section= s, because it is not clear what are specific requirements.

<= p class=3DMsoPlainText style=3D'margin-left:36.0pt;text-indent:-18.0pt;mso-= list:l1 level1 lfo1'>4= .     = ;  Removed second "= ;integrity" from the last paragraph of "Security Considerations&q= uot; section in order to remove confusion that we are talking about protect= ion of SRC and not data on the wire.

5.       <= ![endif]>Minor rephrase of  a paragraph in &quo= t;Introduction"  (starting with "Furthemore..")

6.   &nb= sp;    REQ-00= 5 – Add reference to RS in loss of media sentence

7.     &nb= sp; REQ-012 – change &= quot;indentities" to " identifiers "

8.      = Added RFC 4949 reference fo= r security considerations

9.       Added timelines to figures

 

Attached updated draft ve= r-11

 

 

Leon

= --_000_07465C1D981ABC41A344374066AE1A2C38AC24E597TLVMBX01nicec_-- --_004_07465C1D981ABC41A344374066AE1A2C38AC24E597TLVMBX01nicec_ Content-Type: text/plain; name="draft-ietf-siprec-req-11.txt" Content-Description: draft-ietf-siprec-req-11.txt Content-Disposition: attachment; filename="draft-ietf-siprec-req-11.txt"; size=33496; creation-date="Sun, 29 May 2011 13:24:42 GMT"; modification-date="Sun, 29 May 2011 13:24:42 GMT" Content-Transfer-Encoding: base64 CgoKU0lQUkVDICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBLLiBSZWhvciwgRWQuCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgQ2lzY28gU3lzdGVtcwpJbnRlbmRlZCBzdGF0dXM6IEluZm9y bWF0aW9uYWwgICAgICAgICAgICAgICAgICAgICAgICAgICBMLiBQb3J0bWFuLCBFZC4KRXhwaXJl czogTm92ZW1iZXIgMzAsIDIwMTEgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTklD RSBTeXN0ZW1zCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIEEuIEh1dHRvbgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBTaWVtZW5zIEVudGVycHJpc2UKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIENvbW11bmljYXRpb25z CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgUi4gSmFpbgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgSVBDIFN5c3RlbXMKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTWF5IDI5LCAyMDExCgoKICAgVXNl IENhc2VzIGFuZCBSZXF1aXJlbWVudHMgZm9yIFNJUC1iYXNlZCBNZWRpYSBSZWNvcmRpbmcgKFNJ UFJFQykKICAgICAgICAgICAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1zaXByZWMtcmVxLTExCgpB YnN0cmFjdAoKICAgU2Vzc2lvbiByZWNvcmRpbmcgaXMgYSBjcml0aWNhbCByZXF1aXJlbWVudCBp biBtYW55IGJ1c2luZXNzCiAgIGNvbW11bmljYXRpb25zIGVudmlyb25tZW50cyBzdWNoIGFzIGNh bGwgY2VudGVycyBhbmQgZmluYW5jaWFsCiAgIHRyYWRpbmcgZmxvb3JzLiAgSW4gc29tZSBvZiB0 aGVzZSBlbnZpcm9ubWVudHMsIGFsbCBjYWxscyBtdXN0IGJlCiAgIHJlY29yZGVkIGZvciByZWd1 bGF0b3J5IGFuZCBjb21wbGlhbmNlIHJlYXNvbnMuICBJbiBvdGhlcnMsIGNhbGxzIG1heQogICBi ZSByZWNvcmRlZCBmb3IgcXVhbGl0eSBjb250cm9sIG9yIGJ1c2luZXNzIGFuYWx5dGljcy4KCiAg IFJlY29yZGluZyBpcyB0eXBpY2FsbHkgcGVyZm9ybWVkIGJ5IHNlbmRpbmcgYSBjb3B5IG9mIHRo ZSBzZXNzaW9uCiAgIG1lZGlhIHRvIHRoZSByZWNvcmRpbmcgZGV2aWNlcy4gIFRoaXMgZG9jdW1l bnQgc3BlY2lmaWVzIHJlcXVpcmVtZW50cwogICBmb3IgZXh0ZW5zaW9ucyB0byBTSVAgdGhhdCB3 aWxsIG1hbmFnZSBkZWxpdmVyeSBvZiBSVFAgbWVkaWEgdG8gYQogICByZWNvcmRpbmcgZGV2aWNl LiAgVGhpcyBpcyBiZWluZyByZWZlcnJlZCB0byBhcyBTSVAtYmFzZWQgTWVkaWEKICAgUmVjb3Jk aW5nLgoKU3RhdHVzIG9mIHRoaXMgTWVtbwoKICAgVGhpcyBJbnRlcm5ldC1EcmFmdCBpcyBzdWJt aXR0ZWQgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoIHRoZQogICBwcm92aXNpb25zIG9mIEJDUCA3 OCBhbmQgQkNQIDc5LgoKICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBv ZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcKICAgVGFzayBGb3JjZSAoSUVURikuICBOb3RlIHRo YXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUKICAgd29ya2luZyBkb2N1bWVudHMg YXMgSW50ZXJuZXQtRHJhZnRzLiAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC0KICAgRHJh ZnRzIGlzIGF0IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kcmFmdHMvY3VycmVudC8uCgog ICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVt IG9mIHNpeCBtb250aHMKICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xl dGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkKICAgdGltZS4gIEl0IGlzIGluYXBwcm9wcmlh dGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UKICAgbWF0ZXJpYWwgb3IgdG8g Y2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIgoKICAgVGhpcyBJbnRl cm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBOb3ZlbWJlciAzMCwgMjAxMS4KCkNvcHlyaWdodCBO b3RpY2UKCgoKClJlaG9yLCBldCBhbC4gICAgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMzAsIDIw MTEgICAgICAgICAgICAgICBbUGFnZSAxXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICBSZXF1 aXJlbWVudHMgZm9yIFNJUFJFQyAgICAgICAgICAgICAgICBNYXkgMjAxMQoKCiAgIENvcHlyaWdo dCAoYykgMjAxMSBJRVRGIFRydXN0IGFuZCB0aGUgcGVyc29ucyBpZGVudGlmaWVkIGFzIHRoZQog ICBkb2N1bWVudCBhdXRob3JzLiAgQWxsIHJpZ2h0cyByZXNlcnZlZC4KCiAgIFRoaXMgZG9jdW1l bnQgaXMgc3ViamVjdCB0byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3MgTGVnYWwKICAgUHJv dmlzaW9ucyBSZWxhdGluZyB0byBJRVRGIERvY3VtZW50cwogICAoaHR0cDovL3RydXN0ZWUuaWV0 Zi5vcmcvbGljZW5zZS1pbmZvKSBpbiBlZmZlY3Qgb24gdGhlIGRhdGUgb2YKICAgcHVibGljYXRp b24gb2YgdGhpcyBkb2N1bWVudC4gIFBsZWFzZSByZXZpZXcgdGhlc2UgZG9jdW1lbnRzCiAgIGNh cmVmdWxseSwgYXMgdGhleSBkZXNjcmliZSB5b3VyIHJpZ2h0cyBhbmQgcmVzdHJpY3Rpb25zIHdp dGggcmVzcGVjdAogICB0byB0aGlzIGRvY3VtZW50LiAgQ29kZSBDb21wb25lbnRzIGV4dHJhY3Rl ZCBmcm9tIHRoaXMgZG9jdW1lbnQgbXVzdAogICBpbmNsdWRlIFNpbXBsaWZpZWQgQlNEIExpY2Vu c2UgdGV4dCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA0LmUgb2YKICAgdGhlIFRydXN0IExlZ2Fs IFByb3Zpc2lvbnMgYW5kIGFyZSBwcm92aWRlZCB3aXRob3V0IHdhcnJhbnR5IGFzCiAgIGRlc2Ny aWJlZCBpbiB0aGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZS4KCgpUYWJsZSBvZiBDb250ZW50cwoK ICAgMS4gIEludHJvZHVjdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICAzCiAgIDIuICBSZXF1aXJlbWVudHMgbm90YXRpb24gIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNAogICAzLiAgRGVmaW5pdGlvbnMgIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDQKICAgNC4gIFVz ZSBDYXNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICA2CiAgIDUuICBSZXF1aXJlbWVudHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAxMAogICA2LiAgUHJpdmFjeSBDb25zaWRlcmF0aW9ucyAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTMKICAgNy4gIFNlY3VyaXR5IENv bnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE0CiAg IDguICBJQU5BIENvbnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAxNQogICA5LiAgQWNrbm93bGVkZ2VtZW50cyAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTUKICAgMTAuIE5vcm1hdGl2ZSBSZWZlcmVuY2Vz IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE1CiAgIEF1dGhvcnMn IEFkZHJlc3NlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAxNQoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpSZWhvciwgZXQgYWwuICAgICAgICAgICBFeHBp cmVzIE5vdmVtYmVyIDMwLCAyMDExICAgICAgICAgICAgICAgW1BhZ2UgMl0KDApJbnRlcm5ldC1E cmFmdCAgICAgICAgICAgUmVxdWlyZW1lbnRzIGZvciBTSVBSRUMgICAgICAgICAgICAgICAgTWF5 IDIwMTEKCgoxLiAgSW50cm9kdWN0aW9uCgogICBTZXNzaW9uIHJlY29yZGluZyBpcyBhIGNyaXRp Y2FsIG9wZXJhdGlvbmFsIHJlcXVpcmVtZW50IGluIG1hbnkKICAgYnVzaW5lc3NlcywgZXNwZWNp YWxseSB3aGVyZSB2b2ljZSBpcyB1c2VkIGFzIGEgbWVkaXVtIGZvciBjb21tZXJjZQogICBhbmQg Y3VzdG9tZXIgc3VwcG9ydC4gIEEgcHJpbWUgZXhhbXBsZSB3aGVyZSB2b2ljZSBpcyB1c2VkIGZv ciB0cmFkZQogICBpcyB0aGUgZmluYW5jaWFsIGluZHVzdHJ5LiAgVGhlIGNhbGwgcmVjb3JkaW5n IHJlcXVpcmVtZW50cyBpbiB0aGlzCiAgIGluZHVzdHJ5IGFyZSBxdWl0ZSBzdHJpbmdlbnQuICBU aGUgcmVjb3JkZWQgY2FsbHMgYXJlIHVzZWQgZm9yCiAgIGRpc3B1dGUgcmVzb2x1dGlvbiBhbmQg Y29tcGxpYW5jZS4gIE90aGVyIGJ1c2luZXNzZXMgc3VjaCBhcyBjdXN0b21lcgogICBzdXBwb3J0 IGNhbGwgY2VudGVycyB0eXBpY2FsbHkgZW1wbG95IGNhbGwgcmVjb3JkaW5nIGZvciBxdWFsaXR5 CiAgIGNvbnRyb2wgb3IgYnVzaW5lc3MgYW5hbHl0aWNzLCB3aXRoIGRpZmZlcmVudCByZXF1aXJl bWVudHMuCgogICBEZXBlbmRpbmcgb24gdGhlIGNvdW50cnkgYW5kIGl0cyByZWd1bGF0b3J5IHJl cXVpcmVtZW50cywgZmluYW5jaWFsCiAgIHRyYWRpbmcgZmxvb3JzIHR5cGljYWxseSBtdXN0IHJl Y29yZCBhbGwgY2FsbHMuICBJbiBjb250cmFzdCwgY2FsbAogICBjZW50ZXJzIHR5cGljYWxseSBv bmx5IHJlY29yZCBhIHN1YnNldCBvZiB0aGUgY2FsbHMsIGFuZCBjYWxscyBtdXN0CiAgIG5vdCBm YWlsIHJlZ2FyZGxlc3Mgb2YgdGhlIGF2YWlsYWJpbGl0eSBvZiB0aGUgcmVjb3JkaW5nIGRldmlj ZS4KCiAgIFJlc3BlY3RpbmcgdGhlIHByaXZhY3kgcmlnaHRzIGFuZCB3aXNoZXMgb2YgdXNlcnMg ZW5nYWdlZCBpbiBhIGNhbGwKICAgaXMgb2YgcGFyYW1vdW50IGltcG9ydGFuY2UuICBJbiBtYW55 IGp1cmlzZGljdGlvbnMgcGFydGljaXBhbnRzIGhhdmUKICAgYSByaWdodCB0byBrbm93IHRoYXQg dGhlIHNlc3Npb24gaXMgYmVpbmcgcmVjb3JkZWQgb3IgbWlnaHQgYmUKICAgcmVjb3JkZWQsIGFu ZCBoYXZlIGEgcmlnaHQgdG8gb3B0IG91dCwgZWl0aGVyIGJ5IHRlcm1pbmF0aW5nIHRoZSBjYWxs CiAgIG9yIGJ5IGRlbWFuZGluZyB0aGF0IHRoZSBjYWxsIG5vdCBiZSByZWNvcmRlZC4gIFRoZXJl Zm9yZSB0aGlzCiAgIGRvY3VtZW50IGNvbnRhaW5zIHJlcXVpcmVtZW50cyBmb3IgYmVpbmcgYWJs ZSB0byBub3RpZnkgdXNlcnMgdGhhdCBhCiAgIGNhbGwgaXMgYmVpbmcgcmVjb3JkZWQgYW5kIGZv ciB1c2VycyB0byBiZSBhYmxlIHRvIHJlcXVlc3QgdGhhdCBhCiAgIGNhbGwgbm90IGJlIHJlY29y ZGVkLiAgVXNlIGNhc2VzIHdoZXJlIHVzZXJzIHBhcnRpY2lwYXRpbmcgaW4gYSBjYWxsCiAgIGFy ZSBub3QgaW5mb3JtZWQgdGhhdCB0aGUgY2FsbCBpcyBvciBtaWdodCBiZSByZWNvcmRlZCBhcmUg b3V0c2lkZQogICB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4gIEluIHBhcnRpY3VsYXIsIGxh d2Z1bCBpbnRlcmNlcHQgaXMKICAgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4K CiAgIEZ1cnRoZXJtb3JlLCBvbmUtc2l6ZS1maXRzLWFsbCBtb2RlbCB3aWxsIG5vdCBmaXQgYWxs IG1hcmtldHMgd2hlcmUKICAgdGhlIHNjYWxlIGFuZCBjb3N0IGJ1cmRlbnMgdmFyeSB3aWRlbHkg aGF2aW5nIGRpZmZlcmVudCBuZWVkcyBmb3IKICAgc29sdXRpb24gY2FwYWJpbGl0aWVzIHN1Y2gg YXMgbWVkaWEgaW5qZWN0aW9uLCB0cmFuc2NvZGluZywgYW5kCiAgIHNlY3VyaXR5LiAgSWYgYSBz dGFuZGFyZGl6ZWQgc29sdXRpb24gc3VwcG9ydHMgYWxsIG9mIHRoZQogICByZXF1aXJlbWVudHMg ZnJvbSBldmVyeSByZWNvcmRpbmcgbWFya2V0LCBidXQgZG9pbmcgc28gd291bGQgYmUKICAgZXhw ZW5zaXZlIGZvciBtYXJrZXRzIHdpdGggbGVzc2VyIG5lZWRzLCB0aGVuIHByb3ByaWV0YXJ5IHNv bHV0aW9ucwogICBmb3IgdGhvc2UgbWFya2V0cyB3aWxsIGNvbnRpbnVlIHRvIHByb3BhZ2F0ZS4g IENhcmUgbXVzdCBiZSB0YWtlbiwKICAgdGhlcmVmb3JlLCB0byBtYWtlIGEgc3RhbmRhcmRzLWJh c2VkIHNvbHV0aW9uIHN1cHBvcnQgb3B0aW9uYWxpdHkgYW5kCiAgIGZsZXhpYmlsaXR5LgoKICAg VGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgcmVxdWlyZW1lbnRzIGZvciB1c2luZyBTSVAgW1JGQzMy NjFdIGJldHdlZW4KICAgYSBTZXNzaW9uIFJlY29yZGluZyBDbGllbnQgYW5kIGEgU2Vzc2lvbiBS ZWNvcmRpbmcgU2VydmVyIHRvIGNvbnRyb2wKICAgdGhlIHJlY29yZGluZyBvZiBtZWRpYSB0aGF0 IGhhcyBiZWVuIHRyYW5zbWl0dGVkIGluIHRoZSBjb250ZXh0IG9mIGEKICAgQ29tbXVuaWNhdGlv biBTZXNzaW9uLiAgQSBDb21tdW5pY2F0aW9uIFNlc3Npb24gaXMgdGhlICJjYWxsIiBiZXR3ZWVu CiAgIHBhcnRpY2lwYW50cy4gIFRoZSBTZXNzaW9uIFJlY29yZGluZyBDbGllbnQgaXMgdGhlIHNv dXJjZSBvZiB0aGUKICAgcmVjb3JkZWQgbWVkaWEuICBUaGUgU2Vzc2lvbiBSZWNvcmRpbmcgU2Vy dmVyIGlzIHRoZSBzaW5rIG9mIHJlY29yZGVkCiAgIG1lZGlhLiAgSXQgc2hvdWxkIGJlIG5vdGVk IHRoYXQgdGhlIHJlcXVpcmVtZW50cyBmb3IgdGhlIHByb3RvY29sCiAgIGJldHdlZW4gYSBTZXNz aW9uIFJlY29yZGluZyBTZXJ2ZXIgYW5kIFNlc3Npb24gUmVjb3JkaW5nIENsaWVudCBoYXZlCiAg IHZlcnkgc2ltaWxhciByZXF1aXJlbWVudHMgKHN1Y2ggYXMgY29kZWMgYW5kIHRyYW5zcG9ydCBu ZWdvdGlhdGlvbiwKICAgZW5jcnlwdGlvbiBrZXkgaW50ZXJjaGFuZ2UsIGZpcmV3YWxsIHRyYXZl cnNhbCkgYXMgY29tcGFyZWQgdG8KCgoKUmVob3IsIGV0IGFsLiAgICAgICAgICAgRXhwaXJlcyBO b3ZlbWJlciAzMCwgMjAxMSAgICAgICAgICAgICAgIFtQYWdlIDNdCgwKSW50ZXJuZXQtRHJhZnQg ICAgICAgICAgIFJlcXVpcmVtZW50cyBmb3IgU0lQUkVDICAgICAgICAgICAgICAgIE1heSAyMDEx CgoKICAgcmVndWxhciBTSVAgbWVkaWEgc2Vzc2lvbnMuICBUaGUgY2hvaWNlIG9mIFNJUCBmb3Ig c2Vzc2lvbiByZWNvcmRpbmcKICAgcHJvdmlkZXMgcmV1c2Ugb2YgYW4gZXhpc3RpbmcgcHJvdG9j b2wuCgogICBUaGUgcmVjb3JkZWQgc2Vzc2lvbnMgY2FuIGJlIGFueSBSVFAgbWVkaWEgc2Vzc2lv bnMgaW5jbHVkaW5nIHZvaWNlLAogICBEVE1GIChhcyBkZWZpbmVkIGJ5IFtSRkM0NzMzXSksIHZp ZGVvLCBhbmQgdGV4dCAoYXMgZGVmaW5lZCBieQogICBbUkZDNDEwM10pLgoKICAgQW4gYXJjaGl2 ZWQgc2Vzc2lvbiByZWNvcmRpbmcgaXMgdHlwaWNhbGx5IGNvbXByaXNlZCBvZiB0aGUKICAgQ29t bXVuaWNhdGlvbiBTZXNzaW9uIG1lZGlhIGNvbnRlbnQgYW5kIHRoZSBDb21tdW5pY2F0aW9uIFNl c3Npb24KICAgTWV0YWRhdGEuICBUaGUgQ29tbXVuaWNhdGlvbiBTZXNzaW9uIE1ldGFkYXRhIGFs bG93cyByZWNvcmRpbmcKICAgYXJjaGl2ZXMgdG8gYmUgc2VhcmNoZWQgYW5kIGZpbHRlcmVkIGF0 IGEgbGF0ZXIgdGltZSBhbmQgYWxsb3dzIGEKICAgc2Vzc2lvbiB0byBiZSBwbGF5ZWQgYmFjayBp biBhIG1lYW5pbmdmdWwgd2F5LCBlLmcuLCB3aXRoIGNvcnJlY3QKICAgc3luY2hyb25pemF0aW9u IGJldHdlZW4gdGhlIG1lZGlhLiAgVGhlIENvbW11bmljYXRpb24gU2Vzc2lvbgogICBNZXRhZGF0 YSBuZWVkcyB0byBiZSBjb252ZXllZCBmcm9tIHRoZSBTZXNzaW9uIFJlY29yZGluZyBDbGllbnQg dG8KICAgdGhlIFNlc3Npb24gUmVjb3JkaW5nIFNlcnZlci4KCiAgIFRoaXMgZG9jdW1lbnQgb25s eSBjb25zaWRlcnMgYWN0aXZlIHJlY29yZGluZywgd2hlcmUgdGhlIFNlc3Npb24KICAgUmVjb3Jk aW5nIENsaWVudCBwdXJwb3NlZnVsbHkgc3RyZWFtcyBtZWRpYSB0byBhIFNlc3Npb24gUmVjb3Jk aW5nCiAgIFNlcnZlci4gIFBhc3NpdmUgcmVjb3JkaW5nLCB3aGVyZSBhIHJlY29yZGluZyBkZXZp Y2UgZGV0ZWN0cyBtZWRpYQogICBkaXJlY3RseSBmcm9tIHRoZSBuZXR3b3JrLCBpcyBvdXRzaWRl IHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50LgoKCjIuICBSZXF1aXJlbWVudHMgbm90YXRpb24K CiAgIFRoZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwi LCAiU0hBTEwgTk9UIiwKICAgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwg Ik1BWSIsIGFuZCAiT1BUSU9OQUwiIGluIHRoaXMKICAgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVy cHJldGVkIGFzIGRlc2NyaWJlZCBpbiBbUkZDMjExOV0gYW5kIGluZGljYXRlCiAgIHJlcXVpcmVt ZW50IGxldmVscyBmb3IgY29tcGxpYW50IG1lY2hhbmlzbXMuCgoKMy4gIERlZmluaXRpb25zCgog ICBTZXNzaW9uIFJlY29yZGluZyBTZXJ2ZXIgKFNSUyk6IEEgU2Vzc2lvbiBSZWNvcmRpbmcgU2Vy dmVyIChTUlMpIGlzIGEKICAgU0lQIFVzZXIgQWdlbnQgKFVBKSB0aGF0IGlzIGEgc3BlY2lhbGl6 ZWQgbWVkaWEgc2VydmVyIG9yIGNvbGxlY3RvcgogICB0aGF0IGFjdHMgYXMgdGhlIHNpbmsgb2Yg dGhlIHJlY29yZGVkIG1lZGlhLiAgQW4gU1JTIGlzIHR5cGljYWxseQogICBpbXBsZW1lbnRlZCBh cyBhIG11bHRpLXBvcnQgZGV2aWNlIHRoYXQgaXMgY2FwYWJsZSBvZiByZWNlaXZpbmcgbWVkaWEK ICAgZnJvbSBtdWx0aXBsZSBzb3VyY2VzIHNpbXVsdGFuZW91c2x5LiAgQW4gU1JTIGlzIHRoZSBz aW5rIG9mIHRoZQogICByZWNvcmRlZCBzZXNzaW9uIG1ldGFkYXRhLgoKICAgU2Vzc2lvbiBSZWNv cmRpbmcgQ2xpZW50IChTUkMpOiBBIFNlc3Npb24gUmVjb3JkaW5nIENsaWVudCAoU1JDKSBpcyBh CiAgIFNJUCBVc2VyIEFnZW50IChVQSkgdGhhdCBhY3RzIGFzIHRoZSBzb3VyY2Ugb2YgdGhlIHJl Y29yZGVkIG1lZGlhLAogICBzZW5kaW5nIGl0IHRvIHRoZSBTUlMuICBBbiBTUkMgaXMgYSBsb2dp Y2FsIGZ1bmN0aW9uLiAgSXRzCiAgIGNhcGFiaWxpdGllcyBtYXkgYmUgaW1wbGVtZW50ZWQgYWNy b3NzIG9uZSBvciBtb3JlIHBoeXNpY2FsIGRldmljZXMuCiAgIEluIHByYWN0aWNlLCBhbiBTUkMg Y291bGQgYmUgYSBwZXJzb25hbCBkZXZpY2UgKHN1Y2ggYXMgYSBTSVAgcGhvbmUpLAogICBhIFNJ UCBNZWRpYSBHYXRld2F5IChNRyksIGEgU2Vzc2lvbiBCb3JkZXIgQ29udHJvbGxlciAoU0JDKSBv ciBhIFNJUAogICBNZWRpYSBTZXJ2ZXIgKE1TKSBpbnRlZ3JhdGVkIHdpdGggYW4gQXBwbGljYXRp b24gU2VydmVyIChBUykuICBUaGlzCiAgIHNwZWNpZmljYXRpb24gZGVmaW5lcyB0aGUgdGVybSBT UkMgc3VjaCB0aGF0IGFsbCBzdWNoIFNJUCBlbnRpdGllcwogICBjYW4gYmUgZ2VuZXJpY2FsbHkg YWRkcmVzc2VkIHVuZGVyIG9uZSBkZWZpbml0aW9uLiAgVGhlIFNSQyBwcm92aWRlcwoKCgpSZWhv ciwgZXQgYWwuICAgICAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDMwLCAyMDExICAgICAgICAgICAg ICAgW1BhZ2UgNF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgUmVxdWlyZW1lbnRzIGZvciBT SVBSRUMgICAgICAgICAgICAgICAgTWF5IDIwMTEKCgogICBtZXRhZGF0YSB0byB0aGUgU1JTLgoK ICAgQ29tbXVuaWNhdGlvbiBTZXNzaW9uIChDUyk6IEEgc2Vzc2lvbiBjcmVhdGVkIGJldHdlZW4g dHdvIG9yIG1vcmUgU0lQCiAgIFVzZXIgQWdlbnRzIChVQXMpIHRoYXQgaXMgdGhlIHN1YmplY3Qg b2YgcmVjb3JkaW5nLgoKICAgUmVjb3JkaW5nIFNlc3Npb24gKFJTKTogVGhlIFNJUCBzZXNzaW9u IGNyZWF0ZWQgYmV0d2VlbiBhbiBTUkMgYW5kCiAgIFNSUyBmb3IgdGhlIHB1cnBvc2Ugb2YgcmVj b3JkaW5nIGEgQ29tbXVuaWNhdGlvbiBTZXNzaW9uLgoKICAgRmlndXJlIDEgcGljdG9yaWFsbHkg cmVwcmVzZW50cyB0aGUgcmVsYXRpb25zaGlwIGJldHdlZW4gYSBSZWNvcmRpbmcKICAgU2Vzc2lv biBhbmQgQ29tbXVuaWNhdGlvbiBTZXNzaW9uLgoKCgogICAgICstLS0tLS0tLS0tLS0tKyAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tKwogICAgIHwgICAg ICAgICAgICAgfCAgICAgICAgQ29tbXVuaWNhdGlvbiBTZXNzaW9uICAgICAgICAgfCAgICAgICAg ICAgfAogICAgIHwgICAgIEEgICAgICAgfDwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0+fCAgICAgQiAgICAgfAogICAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgfAogICAgICstLS0tLS0tLS0tLS0tKyAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tKwogICAgIC4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLgogICAgIC4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIFNlc3Npb24gICAgICAg ICAgICAgICAgICAgICAgICAgICAgLgogICAgIC4gICAgICAgICAgICAgICAgICAgICAgICAgICAg UmVjb3JkaW5nICAgICAgICAgICAgICAgICAgICAgICAgICAgLgogICAgIC4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgIENsaWVudCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLgogICAg IC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IFJlY29yZGluZwogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwgU2Vzc2lvbgogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB2 CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tKwogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfCAgIFNlc3Npb24gIHwKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwgIFJlY29yZGluZyB8CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 ICAgU2VydmVyICAgfAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0t LSsKCgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUgMQoKICAgTWV0YWRh dGE6IEluZm9ybWF0aW9uIHRoYXQgZGVzY3JpYmVzIHJlY29yZGVkIG1lZGlhIGFuZCB0aGUgQ1Mg dG8KICAgd2hpY2ggdGhleSByZWxhdGUuCgogICBQYXVzZSBhbmQgUmVzdW1lIGR1cmluZyBhIENv bW11bmljYXRpb24gU2Vzc2lvbjogUGF1c2U6IFRoZSBhY3Rpb24gb2YKICAgdGVtcG9yYXJpbHkg ZGlzY29udGludWluZyB0aGUgdHJhbnNtaXNzaW9uIGFuZCBjb2xsZWN0aW9uIG9mIFJTIG1lZGlh CiAgIFJlc3VtZTogVGhlIGFjdGlvbiBvZiByZWNvbW1lbmNpbmcgdGhlIHRyYW5zbWlzc2lvbiBh bmQgY29sbGVjdGlvbiBvZgogICBSUyBtZWRpYQoKICAgTW9zdCBzZWN1cml0eS1yZWxhdGVkIHRl cm1zIGluIHRoaXMgZG9jdW1lbnQgYXJlIHRvIGJlIHVuZGVyc3Rvb2QgaW4KICAgdGhlIHNlbnNl IGRlZmluZWQgaW4gW1JGQzQ5NDldOyBzdWNoIHRlcm1zIGluY2x1ZGUsIGJ1dCBhcmUgbm90CiAg IGxpbWl0ZWQgdG8sICJhdXRoZW50aWNhdGlvbiIsICJjb25maWRlbnRpYWxpdHkiLCAiZW5jcnlw dGlvbiIsCgoKClJlaG9yLCBldCBhbC4gICAgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMzAsIDIw MTEgICAgICAgICAgICAgICBbUGFnZSA1XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICBSZXF1 aXJlbWVudHMgZm9yIFNJUFJFQyAgICAgICAgICAgICAgICBNYXkgMjAxMQoKCiAgICJpZGVudGl0 eSIsIGFuZCAiaW50ZWdyaXR5Ii4KCgo0LiAgVXNlIENhc2VzCgogICBVc2UgQ2FzZSAxOiBGdWxs LXRpbWUgUmVjb3JkaW5nOiBPbmUgUmVjb3JkaW5nIFNlc3Npb24gZm9yIGVhY2gKICAgQ29tbXVu aWNhdGlvbiBTZXNzaW9uLgoKICAgRm9yIGV4YW1wbGUsIHRoZSBkaWFncmFtIGJlbG93IHNob3dz IHRoZSBsaWZlY3ljbGUgb2YgQ29tbXVuaWNhdGlvbgogICBTZXNzaW9ucyAoQ1MpIGFuZCB0aGUg cmVsYXRpb25zaGlwIHRvIHRoZSBSZWNvcmRpbmcgU2Vzc2lvbnMgKFJTKQoKICAgQ1MgIHwtLS0g Q1MgMSAtLS18ICAgICAgfC0tLSBDUyAyIC0tLXwgICAgIHwtLS0gQ1MgMyAtLS18CgogICBSUyAg fC0tLSBSUyAxIC0tLXwgICAgICB8LS0tIFJTIDIgLS0tfCAgICAgfC0tLSBSUyAzIC0tLXwKICAg dC0tLT4KCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAyCgogICBSZWNv cmQgZXZlcnkgQ1MgZm9yIHNwZWNpZmljIGV4dGVuc2lvbi9wZXJzb24uCgogICBUaGUgbmVlZCB0 byByZWNvcmQgYWxsIGNhbGxzIGlzIHR5cGljYWxseSBkdWUgdG8gYnVzaW5lc3MgcHJvY2Vzcwog ICBwdXJwb3NlcyAoc3VjaCBhcyB0cmFuc2FjdGlvbiBjb25maXJtYXRpb24gb3IgZGlzcHV0ZSBy ZXNvbHV0aW9uKSBvcgogICB0byBlbnN1cmUgY29tcGxpYW5jZSB3aXRoIGdvdmVybm1lbnRhbCBy ZWd1bGF0aW9ucy4gIEFwcGxpY2F0aW9ucwogICBpbmNsdWRlIGVudGVycHJpc2UsIGNvbnRhY3Qg Y2VudGVyLCBhbmQgZmluYW5jaWFsIHRyYWRpbmcgZmxvb3JzLgoKICAgQWxzbyBjb21tb25seSBr bm93biBhcyBUb3RhbCBSZWNvcmRpbmcuCgogICBVc2UgQ2FzZSAyOiBTZWxlY3RpdmUgUmVjb3Jk aW5nOiBTdGFydCBhIFJlY29yZGluZyBTZXNzaW9uIHdoZW4gYQogICBDb21tdW5pY2F0aW9uIFNl c3Npb24gdG8gYmUgcmVjb3JkZWQgaXMgZXN0YWJsaXNoZWQuCgogICBJbiB0aGlzIGV4YW1wbGUs IENvbW11bmljYXRpb24gU2Vzc2lvbnMgMSBhbmQgMyBhcmUgcmVjb3JkZWQgYnV0IENTIDIKICAg aXMgbm90LgoKICAgQ1MgIHwtLS0gQ1MgMSAtLS18ICAgICAgfC0tLSBDUyAyIC0tLXwgICAgIHwt LS0gQ1MgMyAtLS18CgogICBSUyAgfC0tLSBSUyAxLS0tLXwgICAgICAgICAgICAgICAgICAgICAg ICAgfC0tLSBSUyAyIC0tLXwKICAgdC0tLT4KCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIEZpZ3VyZSAzCgogICBVc2UgQ2FzZSAzOiBTdGFydC9TdG9wIGEgUmVjb3JkaW5nIFNlc3Np b24gZHVyaW5nIGEgQ29tbXVuaWNhdGlvbgogICBTZXNzaW9uLgoKICAgVGhlIFJlY29yZGluZyBT ZXNzaW9uIHN0YXJ0cyBkdXJpbmcgYSBDb21tdW5pY2F0aW9uIFNlc3Npb24sIGVpdGhlcgogICBt YW51YWxseSB2aWEgYSB1c2VyLWNvbnRyb2xsZWQgbWVjaGFuaXNtIChlLmcuIGJ1dHRvbiBvbiB1 c2VyJ3MKICAgcGhvbmUpIG9yIGF1dG9tYXRpY2FsbHkgdmlhIGFuIGFwcGxpY2F0aW9uIChlLmcu IGEgQ29udGFjdCBDZW50ZXIKICAgY3VzdG9tZXIgc2VydmljZSBhcHBsaWNhdGlvbikgb3IgYnVz aW5lc3MgZXZlbnQuICBBIFJlY29yZGluZyBTZXNzaW9uCiAgIGVpdGhlciBlbmRzIGR1cmluZyB0 aGUgQ29tbXVuaWNhdGlvbiBTZXNzaW9uLCBvciB3aGVuIHRoZQoKCgpSZWhvciwgZXQgYWwuICAg ICAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDMwLCAyMDExICAgICAgICAgICAgICAgW1BhZ2UgNl0K DApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgUmVxdWlyZW1lbnRzIGZvciBTSVBSRUMgICAgICAg ICAgICAgICAgTWF5IDIwMTEKCgogICBDb21tdW5pY2F0aW9uIFNlc3Npb24gZW5kcy4gIE9uZSBv ciBtb3JlIFJlY29yZGluZyBTZXNzaW9ucyBtYXkKICAgcmVjb3JkIGVhY2ggQ29tbXVuaWNhdGlv biBTZXNzaW9uLgoKCiAgIENTICB8LS0tLS0tLS0tLS0tLSBDb21tdW5pY2F0aW9uIFNlc3Npb24g LS0tLS0tLS0tLS18CgogICBSUyAgICAgICAgICAgfC0tLS0gUlMgMSAtLS0tfCAgfC0tLS0gUlMg MiAtLS0tLXwKICAgdC0tLT4KCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZpZ3Vy ZSA0CgogICBVc2UgQ2FzZSA0OiBQZXJzaXN0ZW50IFJlY29yZGluZzogQSBzaW5nbGUgUmVjb3Jk aW5nIFNlc3Npb24gY2FwdHVyZXMKICAgb25lIG9yIG1vcmUgQ29tbXVuaWNhdGlvbiBTZXNzaW9u cy4KCgogICAgICAgICAgICAgfC0tLSBDUyAxIC0tLXwgICAgICB8LS0tIENTIDIgLS0tfCAgICAg fC0tLSBDUyAzIC0tLXwKCiAgIFJTICB8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSBSZWNvcmRpbmcg U2Vzc2lvbiAtLS0tLS0tLS0tLS0tLS0tLS0tLS18CiAgIHQtLS0+CgogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBGaWd1cmUgNQoKICAgQSBSZWNvcmRpbmcgU2Vzc2lvbiByZWNvcmRz IGNvbnRpbnVvdXNseSB3aXRob3V0IGludGVycnVwdGlvbi4KICAgUGVyaW9kcyB3aGVuIHRoZXJl IGlzIG5vIENTIGluIHByb2dyZXNzIG11c3QgYmUgcmVwcm9kdWNlZCB1cG9uCiAgIHBsYXliYWNr IChlLmcuIGJ5IHJlY29yZGluZyBzaWxlbmNlIGR1cmluZyBzdWNoIHBlcmlvZHMgb3IgYnkgbm90 CiAgIHJlY29yZGluZyBzdWNoIHBlcmlvZHMgYnV0IG1hcmtpbmcgdGhlbSBieSBtZWFucyBvZiBt ZXRhZGF0YSBmb3IKICAgdXRpbGl6YXRpb24gb24gcGxheWJhY2ssIGV0Yy4pLiAgQXBwbGljYXRp b25zIGluY2x1ZGUgZmluYW5jaWFsCiAgIHRyYWRpbmcgZGVza3MgYW5kIGVtZXJnZW5jeSAoZmly c3QtcmVzcG9uZGVyKSBzZXJ2aWNlIGJ1cmVhdXMuICBUaGUKICAgbGVuZ3RoIG9mIGEgUGVyc2lz dGVudCBSZWNvcmRpbmcgU2Vzc2lvbiBpcyBpbmRlcGVuZGVudCBmcm9tIHRoZQogICBsZW5ndGgg b2YgdGhlIGFjdHVhbCBDb21tdW5pY2F0aW9uIFNlc3Npb25zLiAgUGVyc2lzdGVudCBSZWNvcmRp bmcKICAgU2Vzc2lvbnMgYXZvaWQgaXNzdWVzIHN1Y2ggYXMgbWVkaWEgY2xpcHBpbmcgdGhhdCBj YW4gb2NjdXIgZHVlIHRvCiAgIGRlbGF5cyBpbiBSZWNvcmRpbmcgU2Vzc2lvbiBlc3RhYmxpc2ht ZW50LgoKICAgVGhlIGNvbm5lY3Rpb24gYW5kIGF0dHJpYnV0ZXMgb2YgbWVkaWEgaW4gdGhlIFJl Y29yZGluZyBTZXNzaW9uIGFyZQogICBub3QgZHluYW1pY2FsbHkgc2lnbmFsZWQgZm9yIGVhY2gg Q29tbXVuaWNhdGlvbiBTZXNzaW9uIGJlZm9yZSBpdCBjYW4KICAgYmUgcmVjb3JkZWQ7IGhvd2V2 ZXIsIGNvZGVjIHJlLW5lZ290aWF0aW9uIGlzIHBvc3NpYmxlLgoKCgoKCgoKCgoKCgoKCgpSZWhv ciwgZXQgYWwuICAgICAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDMwLCAyMDExICAgICAgICAgICAg ICAgW1BhZ2UgN10KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgUmVxdWlyZW1lbnRzIGZvciBT SVBSRUMgICAgICAgICAgICAgICAgTWF5IDIwMTEKCgogICBJbiBzb21lIGNhc2VzLCBtb3JlIHRo YW4gb25lIGNvbmN1cnJlbnQgQ29tbXVuaWNhdGlvbiBTZXNzaW9uIChvbiBhCiAgIHNpbmdsZSBl bmQtdXNlciBhcHBhcmF0dXMsIGUuZy4gdHJhZGluZyBmbG9vciB0dXJyZXQpIGlzIG1peGVkIGlu dG8KICAgb25lIFJlY29yZGluZyBTZXNzaW9uOgoKICAgICAgICAgICAgICAgICB8LS0tLS0tLS0g Q1MgMSAtLS0tLS0tfAogICAgICAgICAgICAgICAgICAgIHwtLS0tLS0tLSBDUyAyIC0tLS0tLS18 CiAgICAgICAgICAgICAgIHwtLS0tLS0tLSBDUyAzIC0tLS0tLS18CgogICBSUyAgfC0tLS0tLS0t LS0tIFJlY29yZGluZyBTZXNzaW9uIC0tLS0tLS0tLS0tLS0tfAogICB0LS0tPgoKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDYKCiAgIFVzZSBDYXNlIDU6IFJlYWwtdGlt ZSBSZWNvcmRpbmcgQ29udHJvbHMuCgogICBGb3IgYW4gYWN0aXZlIFJlY29yZGluZyBTZXNzaW9u LCBwcml2YWN5IG9yIHNlY3VyaXR5IHJlYXNvbnMgbWF5CiAgIGRlbWFuZCBub3QgY2FwdHVyaW5n IGEgc3BlY2lmaWMgcG9ydGlvbiBvZiBhIGNvbnZlcnNhdGlvbi4gIEFuCiAgIGV4YW1wbGUgaXMg Zm9yIFBDSSAocGF5bWVudCBjYXJkIGluZHVzdHJ5KSBjb21wbGlhbmNlIHdoZXJlIGNyZWRpdAog ICBjYXJkIGluZm8gbXVzdCBiZSBwcm90ZWN0ZWQuICBPbmUgc29sdXRpb24gaXMgdG8gbm90IHJl Y29yZCBhIGNhbGxlcgogICBzcGVha2luZyB0aGVpciBjcmVkaXQgY2FyZCBpbmZvcm1hdGlvbi4K CiAgIEFuIGV4YW1wbGUgb2YgYSByZWFsLXRpbWUgY29udHJvbHMgaXMgUGF1c2UvUmVzdW1lLgoK ICAgVXNlIENhc2UgNjogSVZSIC8gVm9pY2UgUG9ydGFsIFJlY29yZGluZy4KCiAgIFNlbGYtc2Vy dmljZSBJbnRlcmFjdGl2ZSBWb2ljZSBSZXNwb25zZSBhcHBsaWNhdGlvbnMgbWF5IG5lZWQgdG8g YmUKICAgcmVjb3JkZWQgZm9yIGFwcGxpY2F0aW9uIHBlcmZvcm1hbmNlIHR1bmluZyBvciB0byBt ZWV0IGNvbXBsaWFuY2UKICAgcmVxdWlyZW1lbnRzLgoKICAgTWV0YWRhdGEgYWJvdXQgYW4gSVZS IHNlc3Npb24gcmVjb3JkaW5nIG11c3QgaW5jbHVkZSBzZXNzaW9uCiAgIGluZm9ybWF0aW9uIGFu ZCBtYXkgaW5jbHVkZSBhcHBsaWNhdGlvbiBjb250ZXh0IGluZm9ybWF0aW9uIChlLmcuCiAgIFZv aWNlWE1MIHNlc3Npb24gdmFyaWFibGVzLCBkaWFsb2cgbmFtZXMsIGV0Yy4pCgogICBVc2UgQ2Fz ZSA3OiBFbnRlcnByaXNlIE1vYmlsaXR5IFJlY29yZGluZy4KCiAgIE1hbnkgYWdlbnRzIGFuZCBl bnRlcnByaXNlIHdvcmtlcnMgd2hvc2UgY2FsbHMgYXJlIHRvIGJlIHJlY29yZGVkIGFyZQogICBu b3QgbG9jYXRlZCBvbiBjb21wYW55IHByZW1pc2VzLgoKICAgRXhhbXBsZXM6CgogICBvIEhvbWUt YmFzZWQgYWdlbnRzIG9yIGVudGVycHJpc2Ugd29ya2Vycy4KCiAgIG8gTW9iaWxlIHBob25lcyBv ZiBrbm93bGVkZ2Ugd29ya2VycyB3aGVuIHRoZXkgY29uZHVjdCB3b3JrIHJlbGF0ZWQKICAgKGFu ZCBsZWdhbGx5IHJlcXVpcmVkIHJlY29yZGluZykgY2FsbHMuIGUuZy4gaW5zdXJhbmNlIGFnZW50 cywKICAgYnJva2VycywgcGh5c2ljaWFucy4KCiAgIFVzZSBDYXNlIDg6IEdlb2dyYXBoaWNhbGx5 IGRpc3RyaWJ1dGVkIG9yIGNlbnRyYWxpemVkIHJlY29yZGluZy4KCgoKClJlaG9yLCBldCBhbC4g ICAgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMzAsIDIwMTEgICAgICAgICAgICAgICBbUGFnZSA4 XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICBSZXF1aXJlbWVudHMgZm9yIFNJUFJFQyAgICAg ICAgICAgICAgICBNYXkgMjAxMQoKCiAgIEVudGVycHJpc2VzIHN1Y2ggYXMgYmFua3MsIGluc3Vy YW5jZSBhZ2VuY2llcywgYW5kIHJldGFpbCBzdG9yZXMgbWF5CiAgIGhhdmUgbWFueSBsb2NhdGlv bnMsIHBvc3NpYmx5IHVwIHRvIHRob3VzYW5kcyBvZiBzbWFsbCBzaXRlcy4KICAgRnJlcXVlbnRs eSBvbmx5IHBob25lcyBhbmQgbmV0d29yayBpbmZyYXN0cnVjdHVyZSBhcmUgaW5zdGFsbGVkIGlu CiAgIGJyYW5jaGVzLCB3aXRob3V0IGxvY2FsIHJlY29yZGluZyBzZXJ2aWNlcy4gIEluIGNhc2Vz IHdoZXJlIGNhbGxzCiAgIGluc2lkZSBvciBiZXR3ZWVuIGJyYW5jaGVzIG11c3QgYmUgcmVjb3Jk ZWQsIGEgY2VudHJhbGl6ZWQgcmVjb3JkaW5nCiAgIHN5c3RlbSBpbiBkYXRhIGNlbnRlcnMgdG9n ZXRoZXIgd2l0aCB0ZWxlcGhvbnkgaW5mcmFzdHJ1Y3R1cmUgKGUuZy4KICAgUEJYKSBtYXkgYmUg ZGVwbG95ZWQuCgogICBVc2UgQ2FzZSA5OiBSZWNvcmQgY29tcGxleCBjYWxsIHNjZW5hcmlvcy4K CiAgIFRoZSBmb2xsb3dpbmcgaXMgYW4gZXhhbXBsZSBvZiBhIHNjZW5hcmlvIHdoZXJlIG9uZSBj YWxsIHRoYXQgaXMKICAgcmVjb3JkZWQgbXVzdCBiZSBhc3NvY2lhdGVkIHdpdGggYSByZWxhdGVk IGNhbGwgdGhhdCBhbHNvIG11c3QgYmUKICAgcmVjb3JkZWQuCgogICBvIEEgQ3VzdG9tZXIgaXMg aW4gYSBjb252ZXJzYXRpb24gd2l0aCBhIEN1c3RvbWVyIFNlcnZpY2UgQWdlbnQuCgogICBvIEFn ZW50IHB1dHMgQ3VzdG9tZXIgb24gaG9sZCBpbiBvcmRlciB0byBjb25zdWx0IHdpdGggYSBTdXBl cnZpc29yLgoKICAgbyBBZ2VudCBlbnRlcnMgaW50byBhIGNvbnZlcnNhdGlvbiB3aXRoIFN1cGVy dmlzb3IuCgogICBvIEFnZW50IGRpc2Nvbm5lY3RzIGZyb20gU3VwZXJ2aXNvciwgdGhlbiByZWNv bm5lY3RzIHdpdGggQ3VzdG9tZXIuCgogICBvIFRoZSBTdXBlcnZpc29yIGNhbGwgbXVzdCBiZSBh c3NvY2lhdGVkIHdpdGggdGhlIG9yaWdpbmFsIGN1c3RvbWVyCiAgIGNhbGwuCgogICBVc2UgY2Fz ZSAxMDogSGlnaCBhdmFpbGFiaWxpdHkgYW5kIGNvbnRpbnVvdXMgcmVjb3JkaW5nLgoKICAgU3Bl Y2lmaWMgZGVwbG95bWVudCBzY2VuYXJpb3MgcHJlc2VudCBkaWZmZXJlbnQgcmVxdWlyZW1lbnRz IGZvcgogICBzeXN0ZW0gYXZhaWxhYmlsaXR5LCBlcnJvciBoYW5kbGluZywgZXRjLiBpbmNsdWRp bmc6CgogICBvIEFuIFNSUyBtdXN0IGFsd2F5cyBiZSBhdmFpbGFibGUgYXQgY2FsbCBzZXR1cCB0 aW1lLgoKICAgbyBObyBsb3NzIG9mIG1lZGlhIHJlY29yZGluZywgaW5jbHVkaW5nIGR1cmluZyBm YWlsdXJlIG9mIGFuIFNSUy4KCiAgIG8gVGhlIENvbW11bmljYXRpb24gU2Vzc2lvbiBtdXN0IGJl IHRlcm1pbmF0ZWQgKG9yIHN1aXRhYmxlCiAgIG5vdGlmaWNhdGlvbiBnaXZlbiB0byBwYXJ0aWVz KSBpbiB0aGUgZXZlbnQgb2YgYSByZWNvcmRpbmcgZmFpbHVyZS4KCiAgIFVzZSBDYXNlIDExOiBS ZWNvcmQgbXVsdGktY2hhbm5lbCwgbXVsdGktbWVkaWEgc2Vzc2lvbi4KCiAgIFNvbWUgYXBwbGlj YXRpb25zIHJlcXVpcmUgdGhlIHJlY29yZGluZyBvZiBtb3JlIHRoYW4gb25lIG1lZGlhCiAgIHN0 cmVhbSwgcG9zc2libHkgb2YgZGlmZmVyZW50IHR5cGVzLiAgTWVkaWEgYXJlIHN5bmNocm9uaXpl ZCwgZWl0aGVyCiAgIGF0IHN0b3JhZ2Ugb3IgYXQgcGxheWJhY2suCgogICBTcGVlY2ggYW5hbHl0 aWNzIHRlY2hub2xvZ2llcyAoZS5nLiB3b3JkIHNwb3R0aW5nLCBlbW90aW9uIGRldGVjdGlvbiwK ICAgc3BlYWtlciBpZGVudGlmaWNhdGlvbikgbWF5IHJlcXVpcmUgc3BlYWtlci1zZXBhcmF0ZWQg cmVjb3JkaW5ncyBmb3IKICAgb3B0aW11bSBwZXJmb3JtYW5jZS4KCiAgIE11bHRpLW1vZGFsIENv bnRhY3QgQ2VudGVycyBtYXkgaW5jbHVkZSBhdWRpbywgdmlkZW8sIElNIG9yIG90aGVyCgoKClJl aG9yLCBldCBhbC4gICAgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMzAsIDIwMTEgICAgICAgICAg ICAgICBbUGFnZSA5XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICBSZXF1aXJlbWVudHMgZm9y IFNJUFJFQyAgICAgICAgICAgICAgICBNYXkgMjAxMQoKCiAgIGludGVyYWN0aW9uIG1vZGFsaXRp ZXMuCgogICBJbiB0cmFkaW5nIGZsb29ycyBlbnZpcm9ubWVudHMsIGluIG9yZGVyIHRvIG1pbmlt aXplIHN0b3JhZ2UgYW5kCiAgIHJlY29yZGluZyBzeXN0ZW0gcmVzb3VyY2VzLCBpdCBtYXkgYmUg cHJlZmVyYWJsZSB0byBtaXggbXVsdGlwbGUKICAgY29uY3VycmVudCBjYWxscyAoQ29tbXVuaWNh dGlvbiBTZXNzaW9ucykgb24gZGlmZmVyZW50IGhhbmRzZXRzLwogICBzcGVha2VycyBvbiB0aGUg c2FtZSB0dXJyZXQgaW50byBzaW5nbGUgcmVjb3JkaW5nIHNlc3Npb24uCgogICBVc2UgQ2FzZSAx MjogUmVhbC10aW1lIG1lZGlhIHByb2Nlc3NpbmcuCgogICBJdCBtdXN0IGJlIHBvc3NpYmxlIGZv ciBhbiBTUlMgdG8gc3VwcG9ydCByZWFsLXRpbWUgbWVkaWEgcHJvY2Vzc2luZywKICAgc3VjaCBh cyBzcGVlY2ggYW5hbHl0aWNzIG9mIHRyYWRpbmcgZmxvb3IgaW50ZXJhY3Rpb25zLiAgUmVhbC10 aW1lCiAgIGFuYWx5dGljcyBtYXkgYmUgZW1wbG95ZWQgZm9yIGF1dG9tYXRpYyBpbnRlcnZlbnRp b24gKHN0b3BwaW5nCiAgIGludGVyYWN0aW9uIG9yIGFsZXJ0aW5nKSBpZiBmb3IgZXhhbXBsZSwg YSB0cmFkZXIgaXMgbm90IGZvbGxvd2luZwogICByZWd1bGF0aW9ucy4KCiAgIFNwZWFrZXIgc2Vw YXJhdGlvbiBpcyByZXF1aXJlZCBpbiBvcmRlciB0byByZWxpYWJseSBkZXRlY3Qgd2hvIGlzCiAg IHNheWluZyBzcGVjaWZpYyBwaHJhc2VzLgoKCjUuICBSZXF1aXJlbWVudHMKCiAgIFRoZSBmb2xs b3dpbmcgYXJlIHJlcXVpcmVtZW50cyBmb3IgU0lQLWJhc2VkIE1lZGlhIFJlY29yZGluZzoKCiAg IG8gUkVRLTAwMSBUaGUgbWVjaGFuaXNtIE1VU1QgcHJvdmlkZSBhIG1lYW5zIGZvciB1c2luZyB0 aGUgU0lQCiAgIHByb3RvY29sIGZvciBlc3RhYmxpc2hpbmcsIG1haW50YWluaW5nIGFuZCB0ZXJt aW5hdGluZyBSZWNvcmRpbmcKICAgU2Vzc2lvbnMgYmV0d2VlbiBhIFNlc3Npb24gUmVjb3JkaW5n IENsaWVudCBhbmQgYSBTZXNzaW9uIFJlY29yZGluZwogICBTZXJ2ZXIuCgogICBvIFJFUS0wMDIg VGhlIG1lY2hhbmlzbSBNVVNUIHN1cHBvcnQgdGhlIGFiaWxpdHkgdG8gcmVjb3JkIGFsbCBDU3Mg aW4KICAgdGhlaXIgZW50aXJldHkuCgogICBvIFJFUS0wMDMgVGhlIG1lY2hhbmlzbSBNVVNUIHN1 cHBvcnQgdGhlIGFiaWxpdHkgdG8gcmVjb3JkIHNlbGVjdGVkCiAgIENTcyBpbiB0aGVpciBlbnRp cmV0eSwgYWNjb3JkaW5nIHRvIHBvbGljeS4KCiAgIG8gUkVRLTAwNCBUaGUgbWVjaGFuaXNtIE1V U1Qgc3VwcG9ydCB0aGUgYWJpbGl0eSB0byByZWNvcmQgc2VsZWN0ZWQKICAgcGFydHMgb2Ygc2Vs ZWN0ZWQgQ1NzLgoKICAgbyBSRVEtMDA1IFRoZSBtZWNoYW5pc20gTVVTVCBzdXBwb3J0IHRoZSBh YmlsaXR5IHRvIHJlY29yZCBhIENTCiAgIHdpdGhvdXQgbG9zcyBvZiBtZWRpYSBvZiBSUyAoZm9y IGV4YW1wbGUsIGNsaXBwaW5nIG1lZGlhIGF0IHRoZQogICBiZWdpbm5pbmcgb2YgdGhlIENTKSBk dWUgdG8gUlMgcmVjb3JkaW5nIHByZXBhcmF0aW9uIGFuZCBhbHNvLAogICB3aXRob3V0IGltcGFj dGluZyB0aGUgcXVhbGl0eSBvciB0aW1pbmcgb2YgdGhlIENTIChmb3IgZXhhbXBsZSwKICAgZGVs YXlpbmcgdGhlIHN0YXJ0IG9mIHRoZSBDUyB3aGlsZSBwcmVwYXJhdGlvbiBmb3IgcmVjb3JkaW5n CiAgIHNlc3Npb24pLiAgU2VlIFVzZSBDYXNlIDQgaW4gU2VjdGlvbiA0IGZvciBtb3JlIGRldGFp bHMuCgogICBvIFJFUS0wMDYgVGhlIG1lY2hhbmlzbSBNVVNUIHN1cHBvcnQgdGhlIHJlY29yZGlu ZyBvZiBJVlIgc2Vzc2lvbnMuCgogICBvIFJFUS0wMDcgVGhlIG1lY2hhbmlzbSBNVVNUIHN1cHBv cnQgdGhlIHJlY29yZGluZyBvZiBSVFAgbWVkaWEgdHlwZXMKICAgdm9pY2UsIERUTUYgKGFzIGRl ZmluZWQgYnkgW1JGQzQ3MzNdKSwgdmlkZW8sIGFuZCB0ZXh0IChhcyBkZWZpbmVkIGJ5CgoKClJl aG9yLCBldCBhbC4gICAgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMzAsIDIwMTEgICAgICAgICAg ICAgIFtQYWdlIDEwXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICBSZXF1aXJlbWVudHMgZm9y IFNJUFJFQyAgICAgICAgICAgICAgICBNYXkgMjAxMQoKCiAgIFtSRkM0MTAzXSkuCgogICBvIFJF US0wMDggVGhlIG1lY2hhbmlzbSBNVVNUIHN1cHBvcnQgdGhlIGFiaWxpdHkgZm9yIGFuIFNSQyB0 bwogICBkZWxpdmVyIG1peGVkIGF1ZGlvIHN0cmVhbXMgZnJvbSBtdWx0aXBsZSBDb21tdW5pY2F0 aW9uIFNlc3Npb25zIHRvCiAgIGFuIFNSUy4KCiAgIE5vdGU6IEEgbWl4ZWQgYXVkaW8gc3RyZWFt IGlzIHdoZXJlIHNldmVyYWwgcmVsYXRlZCBDb21tdW5pY2F0aW9uCiAgIFNlc3Npb25zIGFyZSBj YXJyaWVkIGluIGEgc2luZ2xlIFJlY29yZGluZyBTZXNzaW9uLiAgQSBtaXhlZCBtZWRpYQogICBz dHJlYW0gaXMgdHlwaWNhbGx5IHByb2R1Y2VkIGJ5IGEgbWl4ZXIgZnVuY3Rpb24uICBUaGUgUlMg TUFZIGJlCiAgIGluZm9ybWVkIGFib3V0IHRoZSBjb21wb3NpdGlvbiBvZiB0aGUgbWl4ZWQgc3Ry ZWFtcyB0aHJvdWdoIHNlc3Npb24KICAgbWV0YWRhdGEuCgogICBvIFJFUS0wMDk6IFRoZSBtZWNo YW5pc20gTVVTVCBzdXBwb3J0IHRoZSBhYmlsaXR5IGZvciBhbiBTUkMgdG8KICAgZGVsaXZlciBt aXhlZCBhdWRpbyBzdHJlYW1zIGZyb20gZGlmZmVyZW50IHBhcnRpZXMgb2YgYSBnaXZlbgogICBD b21tdW5pY2F0aW9uIFNlc3Npb24gdG8gYW4gU1JTLgoKICAgbyBSRVEtMDEwIFRoZSBtZWNoYW5p c20gTVVTVCBzdXBwb3J0IHRoZSBhYmlsaXR5IHRvIGRlbGl2ZXIgdG8gdGhlCiAgIFNSUyBtdWx0 aXBsZSBtZWRpYSBzdHJlYW1zIGZvciBhIGdpdmVuIENTLgoKICAgbyBSRVEtMDExIFRoZSBtZWNo YW5pc20gTVVTVCBzdXBwb3J0IHRoZSBhYmlsaXR5IHRvIHBhdXNlIGFuZCByZXN1bWUKICAgdGhl IHRyYW5zbWlzc2lvbiBhbmQgY29sbGVjdGlvbiBvZiBSUyBtZWRpYS4KCiAgIG8gUkVRLTAxMiBU aGUgbWVjaGFuaXNtIE1VU1QgaW5jbHVkZSBhIG1lYW5zIGZvciBwcm92aWRpbmcgdGhlIFNSUwog ICB3aXRoIG1ldGFkYXRhIGRlc2NyaWJpbmcgQ1NzIHRoYXQgYXJlIGJlaW5nIHJlY29yZGVkLCBp bmNsdWRpbmcgdGhlCiAgIG1lZGlhIGJlaW5nIHVzZWQgYW5kIHRoZSBpZGVudGlmaWVycyBvZiBw YXJ0aWVzIGludm9sdmVkLgoKICAgbyBSRVEtMDEzIFRoZSBtZWNoYW5pc20gTVVTVCBpbmNsdWRl IGEgbWVhbnMgZm9yIHRoZSBTUlMgdG8gYmUgYWJsZQogICB0byBjb3JyZWxhdGUgUlMgbWVkaWEg d2l0aCBDUyBwYXJ0aWNpcGFudCBtZWRpYS4KCiAgIG8gUkVRLTAxNCBNZXRhZGF0YSBmb3JtYXQg bXVzdCBiZSBhZ25vc3RpYyBvZiB0aGUgdHJhbnNwb3J0IHByb3RvY29sLgoKICAgbyBSRVEtMDE1 OiBUaGUgbWVjaGFuaXNtIE1VU1Qgc3VwcG9ydCBhIG1lYW5zIHRvIHN0b3AgdGhlIHJlY29yZGlu Zy4KCiAgIG8gUkVRLTAxNjogVGhlIG1lY2hhbmlzbSBNVVNUIHN1cHBvcnQgYSBtZWFucyBmb3Ig YSByZWNvcmRpbmctYXdhcmUKICAgVUEgaW52b2x2ZWQgaW4gYSBDUyB0byByZXF1ZXN0IGF0IHNl c3Npb24gZXN0YWJsaXNobWVudCB0aW1lIHRoYXQgdGhlCiAgIENTIHNob3VsZCBiZSByZWNvcmRl ZCBvciBzaG91bGQgbm90IGJlIHJlY29yZGVkLCB0aGUgaG9ub3Jpbmcgb2Ygc3VjaAogICBhIHJl cXVlc3QgYmVpbmcgZGVwZW5kZW50IG9uIHBvbGljeS4KCiAgIG8gUkVRLTAxNzogVGhlIG1lY2hh bmlzbSBNVVNUIHN1cHBvcnQgYSBtZWFucyBmb3IgYSByZWNvcmRpbmctYXdhcmUKICAgVUEgaW52 b2x2ZWQgaW4gYSBDUyB0byByZXF1ZXN0IGR1cmluZyBhIHNlc3Npb24gdGhhdCB0aGUgcmVjb3Jk aW5nIG9mCiAgIHRoZSBDUyBzaG91bGQgYmUgc3RhcnRlZCwgcGF1c2VkLCByZXN1bWVkIG9yIHN0 b3BwZWQsIHRoZSBob25vcmluZyBvZgogICBzdWNoIGEgcmVxdWVzdCBiZWluZyBkZXBlbmRlbnQg b24gcG9saWN5LiAgU3VjaCByZWNvcmRpbmctYXdhcmUgVUEKICAgTVVTVCBiZSBub3RpZmllZCBh Ym91dCBvdXRjb21lIG9mIHN1Y2ggcmVxdWVzdHMuCgogICBvIFJFUS0wMTggVGhlIG1lY2hhbmlz bSBNVVNUIE5PVCBwcmV2ZW50IHRoZSBhcHBsaWNhdGlvbiBvZiB0b25lcyBvcgogICBhbm5vdW5j ZW1lbnRzIGR1cmluZyByZWNvcmRpbmcgb3IgYXQgdGhlIHN0YXJ0IG9mIGEgQ1MgdG8gc3VwcG9y dAogICBub3RpZmljYXRpb24gdG8gcGFydGljaXBhbnRzIHRoYXQgdGhlIGNhbGwgaXMgYmVpbmcg cmVjb3JkZWQgb3IgbWF5CiAgIGJlIHJlY29yZGVkLgoKCgpSZWhvciwgZXQgYWwuICAgICAgICAg ICBFeHBpcmVzIE5vdmVtYmVyIDMwLCAyMDExICAgICAgICAgICAgICBbUGFnZSAxMV0KDApJbnRl cm5ldC1EcmFmdCAgICAgICAgICAgUmVxdWlyZW1lbnRzIGZvciBTSVBSRUMgICAgICAgICAgICAg ICAgTWF5IDIwMTEKCgogICBvIFJFUS0wMTkgVGhlIG1lY2hhbmlzbSBNVVNUIHByb3ZpZGUgYSBt ZWFucyBvZiBpbmRpY2F0aW5nIHRvCiAgIHJlY29yZGluZy1hd2FyZSBVQXMgd2hldGhlciByZWNv cmRpbmcgaXMgdGFraW5nIHBsYWNlLCBmb3IKICAgYXBwcm9wcmlhdGUgcmVuZGVyaW5nIGF0IHRo ZSB1c2VyIGludGVyZmFjZS4KCiAgIG8gUkVRLTAyMCBUaGUgbWVjaGFuaXNtIE1VU1QgcHJvdmlk ZSBhIHdheSBmb3IgbWV0YWRhdGEgdG8gYmUKICAgY29udmV5ZWQgdG8gdGhlIFNSUyBpbmNyZW1l bnRhbGx5IGR1cmluZyB0aGUgQ1MuCgogICBvIFJFUS0wMjEgVGhlIG1lY2hhbmlzbSBNVVNUIE5P VCBwcmV2ZW50IGhpZ2ggYXZhaWxhYmlsaXR5CiAgIGRlcGxveW1lbnRzLgoKICAgbyBSRVEtMDIy IFRoZSBtZWNoYW5pc20gTVVTVCBwcm92aWRlIG1lYW5zIGZvciBmYWNpbGl0YXRpbmcKICAgc3lu Y2hyb25pemF0aW9uIG9mIHRoZSByZWNvcmRlZCBtZWRpYSBzdHJlYW1zIGFuZCBtZXRhZGF0YS4K CiAgIG8gUkVRLTAyMyBUaGUgbWVjaGFuaXNtIE1VU1QgcHJvdmlkZSBtZWFucyBmb3IgZmFjaWxp dGF0aW5nCiAgIHN5bmNocm9uaXphdGlvbiBhbW9uZyB0aGUgcmVjb3JkZWQgbWVkaWEgc3RyZWFt cy4KCiAgIG8gUkVRLTAyNCBUaGUgbWVjaGFuaXNtIE1VU1QgcHJvdmlkZSBtZWFucyB0byByZWxh dGUgcmVjb3JkaW5nIGFuZAogICByZWNvcmRpbmcgY29udHJvbHMgc3VjaCBhcyBzdGFydC9zdG9w L3BhdXNlL3Jlc3VtZSB0byB0aGUgd2FsbCBjbG9jawogICB0aW1lLgoKICAgbyBSRVEtMDI1IFRo ZSBtZWNoYW5pc20gTVVTVCBwcm92aWRlIG1lYW5zIGZvciBhbiBTUlMgdG8gYXV0aGVudGljYXRl CiAgIHRoZSBTUkMgb24gUlMgaW5pdGlhdGlvbi4KCiAgIG8gUkVRLTAyNiBUaGUgbWVjaGFuaXNt IE1VU1QgcHJvdmlkZSBtZWFucyBmb3IgYW4gU1JDIHRvIGF1dGhlbnRpY2F0ZQogICB0aGUgU1JT IG9uIFJTIGluaXRpYXRpb24uCgogICBvIFJFUS0wMjcgVGhlIG1lY2hhbmlzbSBNVVNUIGluY2x1 ZGUgYSBtZWFucyBmb3IgZW5zdXJpbmcgdGhhdCB0aGUKICAgaW50ZWdyaXR5IG9mIHRoZSBtZXRh ZGF0YSBzZW50IGZyb20gU1JDIHRvIFNSUyBpcyBhbiBhY2N1cmF0ZQogICByZXByZXNlbnRhdGlv biBvZiB0aGUgb3JpZ2luYWwgQ1MgbWV0YWRhdGEuCgogICBvIFJFUS0wMjggVGhlIG1lY2hhbmlz bSBNVVNUIGluY2x1ZGUgYSBtZWFucyBmb3IgZW5zdXJpbmcgdGhhdCB0aGUKICAgaW50ZWdyaXR5 IG9mIHRoZSBtZWRpYSBzZW50IGZyb20gU1JDIHRvIFNSUyBpcyBhbiBhY2N1cmF0ZQogICByZXBy ZXNlbnRhdGlvbiBvZiB0aGUgb3JpZ2luYWwgQ1MgbWVkaWEuCgogICBvIFJFUS0wMjkgVGhlIG1l Y2hhbmlzbSBNVVNUIGluY2x1ZGUgYSBtZWFucyBmb3IgZW5zdXJpbmcgdGhlCiAgIGNvbmZpZGVu dGlhbGl0eSBvZiB0aGUgTWV0YWRhdGEgc2VudCBmcm9tIFNSQyB0byBTUlMuCgogICBvIFJFUS0w MzAgVGhlIG1lY2hhbmlzbSBNVVNUIHByb3ZpZGUgYSBtZWFucyB0byBzdXBwb3J0IFJTCiAgIGNv bmZpZGVudGlhbGl0eS4KCiAgIG8gUkVRLTAzMSBUaGUgbWVjaGFuaXNtIE1VU1Qgc3VwcG9ydCB0 aGUgYWJpbGl0eSB0byBkZWxpdmVyIHRvIHRoZQogICBTUlMgbXVsdGlwbGUgbWVkaWEgc3RyZWFt cyBvZiB0aGUgc2FtZSBtZWRpYSB0eXBlIChlLmcuIGF1ZGlvLAogICB2aWRlbykuICBGb3IgZXhh bXBsZSBpbiB0aGUgY2FzZSBvZiBkZWxpdmVyaW5nIHVubWl4ZWQgYXVkaW8gZm9yIGVhY2gKICAg cGFydGljaXBhbnQgaW4gdGhlIENTLgoKCgoKCgoKUmVob3IsIGV0IGFsLiAgICAgICAgICAgRXhw aXJlcyBOb3ZlbWJlciAzMCwgMjAxMSAgICAgICAgICAgICAgW1BhZ2UgMTJdCgwKSW50ZXJuZXQt RHJhZnQgICAgICAgICAgIFJlcXVpcmVtZW50cyBmb3IgU0lQUkVDICAgICAgICAgICAgICAgIE1h eSAyMDExCgoKNi4gIFByaXZhY3kgQ29uc2lkZXJhdGlvbnMKCiAgIFJlc3BlY3RpbmcgdGhlIHBy aXZhY3kgcmlnaHRzIGFuZCB3aXNoZXMgb2YgdXNlcnMgZW5nYWdlZCBpbiBhIGNhbGwKICAgaXMg b2YgcGFyYW1vdW50IGltcG9ydGFuY2UuICBJbiBtYW55IGp1cmlzZGljdGlvbnMgcGFydGljaXBh bnRzIGhhdmUKICAgYSByaWdodCB0byBrbm93IHRoYXQgdGhlIHNlc3Npb24gaXMgYmVpbmcgcmVj b3JkZWQgb3IgbWlnaHQgYmUKICAgcmVjb3JkZWQsIGFuZCBoYXZlIGEgcmlnaHQgdG8gb3B0IG91 dCwgZWl0aGVyIGJ5IHRlcm1pbmF0aW5nIHRoZSBjYWxsCiAgIG9yIGJ5IGRlbWFuZGluZyB0aGF0 IHRoZSBjYWxsIG5vdCBiZSByZWNvcmRlZC4gIFRoZXJlZm9yZSB0aGlzCiAgIGRvY3VtZW50IGNv bnRhaW5zIHJlcXVpcmVtZW50cyBmb3IgYmVpbmcgYWJsZSB0byBub3RpZnkgdXNlcnMgdGhhdCBh CiAgIGNhbGwgaXMgYmVpbmcgcmVjb3JkZWQgYW5kIGZvciB1c2VycyB0byBiZSBhYmxlIHRvIHJl cXVlc3QgdGhhdCBhCiAgIGNhbGwgbm90IGJlIHJlY29yZGVkLiAgVXNlIGNhc2VzIHdoZXJlIHVz ZXJzIHBhcnRpY2lwYXRpbmcgaW4gYSBjYWxsCiAgIGFyZSBub3QgaW5mb3JtZWQgdGhhdCB0aGUg Y2FsbCBpcyBvciBtaWdodCBiZSByZWNvcmRlZCBhcmUgb3V0c2lkZQogICB0aGUgc2NvcGUgb2Yg dGhpcyBkb2N1bWVudC4gIEluIHBhcnRpY3VsYXIsIGxhd2Z1bCBpbnRlcmNlcHQgaXMKICAgb3V0 c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4KCiAgIFJlcXVpcmVtZW50cyBmb3IgcGFy dGljaXBhbnQgbm90aWZpY2F0aW9uIG9mIHJlY29yZGluZyB2YXJ5IHdpZGVseSBieQogICBqdXJp c2RpY3Rpb24uICBJbiBhIGdpdmVuIGRlcGxveW1lbnQsIG5vdCBhbGwgdXNlcnMgd2lsbCBiZQog ICBhdXRob3JpemVkIHRvIHN0b3AgdGhlIHJlY29yZGluZyBvZiBhIENTIChhbHRob3VnaCBhbnkg dXNlciBjYW4KICAgdGVybWluYXRlIGl0cyBwYXJ0aWNpcGF0aW9uIGluIGEgQ1MpLiAgVHlwaWNh bGx5IHVzZXJzIHdpdGhpbiB0aGUKICAgZG9tYWluIHRoYXQgaXMgY2Fycnlpbmcgb3V0IHRoZSBy ZWNvcmRpbmcgd2lsbCBiZSBzdWJqZWN0IHRvIHBvbGljaWVzCiAgIG9mIHRoYXQgZG9tYWluIGNv bmNlcm5pbmcgd2hldGhlciBDU3MgYXJlIHJlY29yZGVkLiAgRm9yIGV4YW1wbGUsIGluCiAgIGEg Y2FsbCBjZW50cmUsIGFnZW50cyB3aWxsIGJlIHN1YmplY3QgdG8gcG9saWNpZXMgb2YgdGhlIGNh bGwgY2VudHJlCiAgIGFuZCBtYXkgb3IgbWF5IG5vdCBoYXZlIHRoZSByaWdodCB0byBwcmV2ZW50 IHRoZSByZWNvcmRpbmcgb2YgYSBDUyBvcgogICBwYXJ0IG9mIGEgQ1MuICBVc2VycyBjYWxsaW5n IGludG8gdGhlIGNhbGwgY2VudHJlLCBvbiB0aGUgb3RoZXIgaGFuZCwKICAgd2lsbCB0eXBpY2Fs bHkgaGF2ZSB0byBhc2sgdGhlIGFnZW50IG5vdCB0byByZWNvcmQgdGhlIENTLiAgSWYgdGhlCiAg IGFnZW50IGlzIHVuYWJsZSB0byBwcmV2ZW50IHJlY29yZGluZywgb3IgaWYgdGhlIGNhbGxlciBk b2VzIG5vdCB0cnVzdAogICB0aGUgYWdlbnQsIHRoZSBvbmx5IG9wdGlvbiBnZW5lcmFsbHkgaXMg dG8gdGVybWluYXRlIHRoZSBDUy4KCiAgIFByaXZhY3kgY29uc2lkZXJhdGlvbnMgYWxzbyBleHRl bmQgdG8gd2hhdCBoYXBwZW5zIHRvIGEgcmVjb3JkaW5nCiAgIG9uY2UgaXQgaGFzIGJlZW4gY3Jl YXRlZC4gIFR5cGljYWwgaXNzdWVzIGFyZSB3aG8gY2FuIGFjY2VzcyB0aGUKICAgcmVjb3JkaW5n IChlLmcuLCByZWNlaXZlIGEgY29weSBvZiB0aGUgcmVjb3JkaW5nLCB2aWV3IHRoZSBtZXRhZGF0 YSwKICAgcGxheSBiYWNrIHRoZSBtZWRpYSwgZXRjLiksIGZvciB3aGF0IHB1cnBvc2UgdGhlIHJl Y29yZGluZyBjYW4gYmUKICAgdXNlZCAoZS5nLiwgZm9yIHRyYWluaW5nIHB1cnBvc2VzLCBmb3Ig cXVhbGl0eSBjb250cm9sIHB1cnBvc2VzLAogICBldGMuKSBhbmQgZm9yIGhvdyBsb25nIHRoZSBy ZWNvcmRpbmcgaXMgdG8gYmUgcmV0YWluZWQgYmVmb3JlCiAgIGRlbGV0aW9uLiAgVGhlc2UgYXJl IHR5cGljYWxseSBwb2xpY2llcyBvZiB0aGUgZG9tYWluIHRoYXQgbWFrZXMgdGhlCiAgIHJlY29y ZGluZywgcmF0aGVyIHRoYW4gcG9saWNpZXMgb2YgaW5kaXZpZHVhbCB1c2VycyBpbnZvbHZlZCBp biBhCiAgIHJlY29yZGVkIENTLCB3aGV0aGVyIHRob3NlIHVzZXJzIGJlIGluIHRoZSBzYW1lIGRv bWFpbiBvciBpbiBhCiAgIGRpZmZlcmVudCBkb21haW4uICBUYWtpbmcgdGhlIGNhbGwgY2VudHJl IGV4YW1wbGUgYWdhaW4sIGFnZW50cyBtaWdodAogICBiZSBtYWRlIGF3YXJlIG9mIGNhbGwgY2Vu dHJlIHBvbGljeSByZWdhcmRpbmcgcmV0ZW50aW9uIGFuZCB1c2Ugb2YKICAgcmVjb3JkaW5ncyBh cyBwYXJ0IG9mIHRoZWlyIGVtcGxveW1lbnQgY29udHJhY3QsIGFuZCBjYWxsZXJzIGZyb20KICAg b3V0c2lkZSB0aGUgY2FsbCBjZW50cmUgbWlnaHQgYmUgZ2l2ZW4gc29tZSBpbmZvcm1hdGlvbiBh Ym91dCBwb2xpY3kKICAgd2hlbiBub3RpZmllZCB0aGF0IGEgQ1Mgd2lsbCBiZSByZWNvcmRlZCAo ZS5nLiwgdGhyb3VnaCBhbgogICBhbm5vdW5jZW1lbnQgdGhhdCBzYXlzIHRoYXQgY2FsbHMgbWF5 IGJlIHJlY29yZGVkIGZvciBxdWFsaXR5CiAgIHB1cnBvc2VzKS4KCiAgIFRoaXMgZG9jdW1lbnQg ZG9lcyBub3Qgc3BlY2lmeSBhbnkgcmVxdWlyZW1lbnRzIGZvciBhIHVzZXIgZW5nYWdlZCBpbgog ICBhIENTIHRvIGJlIGFibGUgdG8gZGljdGF0ZSBwb2xpY3kgZm9yIHdoYXQgaGFwcGVucyB0byBh IHJlY29yZGluZywgb3IKICAgZm9yIHN1Y2ggaW5mb3JtYXRpb24gdG8gYmUgY29udmV5ZWQgZnJv bSBhbiBTUkMgdG8gYW4gU1JTLiAgSXQgaXMKICAgYXNzdW1lZCB0aGF0IHRoZSBTUlMgaGFzIGFj Y2VzcyB0byBwb2xpY3kgYXBwbGljYWJsZSB0byBpdHMKCgoKUmVob3IsIGV0IGFsLiAgICAgICAg ICAgRXhwaXJlcyBOb3ZlbWJlciAzMCwgMjAxMSAgICAgICAgICAgICAgW1BhZ2UgMTNdCgwKSW50 ZXJuZXQtRHJhZnQgICAgICAgICAgIFJlcXVpcmVtZW50cyBmb3IgU0lQUkVDICAgICAgICAgICAg ICAgIE1heSAyMDExCgoKICAgZW52aXJvbm1lbnQgYW5kIGNhbiBlbnN1cmUgdGhhdCByZWNvcmRp bmdzIGFyZSBzdG9yZWQgYW5kIHVzZWQgaW4KICAgYWNjb3JkYW5jZSB3aXRoIHRoYXQgcG9saWN5 LgoKCjcuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucwoKICAgU2Vzc2lvbiByZWNvcmRpbmcgaGFz IHN1YnN0YW50aWFsIHNlY3VyaXR5IGltcGxpY2F0aW9ucywgZm9yIHRoZSBTSVAKICAgVUEncyBi ZWluZyByZWNvcmRlZCwgdGhlIFNSQywgYW5kIHRoZSBTUlMuCgogICBGb3IgdGhlIFNJUCBVQSdz IGludm9sdmVkIGluIHRoZSBDb21tdW5pY2F0aW9uIFNlc3Npb24sIHRoZQogICByZXF1aXJlbWVu dHMgaW4gdGhpcyBkcmFmdCBlbmFibGUgdGhlIFVBIHRvIGlkZW50aWZ5IHRoYXQgYQogICBDb21t dW5pY2F0aW9uIFNlc3Npb24gaXMgYmVpbmcgcmVjb3JkZWQgYW5kIGZvciB0aGUgVUEgdG8gcmVx dWVzdAogICB0aGF0IGEgZ2l2ZW4gQ29tbXVuaWNhdGlvbiBTZXNzaW9uIGlzIG5vdCBzdWJqZWN0 IHRvIHJlY29yZGluZy4KCiAgIFNpbmNlIGh1bWFucyBkb24ndCB0eXBpY2FsbHkgbG9vayBhdCBv ciBrbm93IGFib3V0IHByb3RvY29sIHNpZ25hbGluZwogICBzdWNoIGFzIFNJUCwgYW5kIGluZGVl ZCB0aGUgU0lQIHNlc3Npb24gbWlnaHQgaGF2ZSBvcmlnaW5hdGVkIHRocm91Z2gKICAgYSBQU1RO IEdhdGV3YXkgd2l0aG91dCBhbnkgYWJpbGl0eSB0byBwYXNzIG9uIGluLXNpZ25hbGluZwogICBp bmRpY2F0aW9ucyBvZiByZWNvcmRpbmcsIHVzZXJzIGNhbiBiZSBub3RpZmllZCBvZiByZWNvcmRp bmcgaW4gdGhlCiAgIG1lZGlhIGl0c2VsZiB0aHJvdWdoIHZvaWNlIGFubm91bmNlbWVudHMsIGEg dmlzdWFsIGluZGljYXRvciBvbiB0aGUKICAgZW5kcG9pbnQsIG9yIG90aGVyIG1lYW5zLgoKICAg V2l0aCByZWdhcmRzIHRvIHNlY3VyaXR5IGltcGxpY2F0aW9ucyBvZiB0aGUgcHJvdG9jb2wocyks IGNsZWFybHkKICAgdGhlcmUgaXMgYSBuZWVkIGZvciBhdXRoZW50aWNhdGlvbiwgYXV0aG9yaXph dGlvbiwgZWF2ZXNkcm9wcGluZywgYW5kCiAgIHByb3RlY3Rpb24gZm9yIHRoZSBzb2x1dGlvbi4g IFRoZSBTUkMgbmVlZHMgdG8ga25vdyB0aGUgU1JTIGl0IGlzCiAgIGNvbW11bmljYXRpbmcgd2l0 aCBpcyBsZWdpdGltYXRlLCBhbmQgdmljZS12ZXJzYSwgZXZlbiBpZiB0aGV5IGFyZSBpbgogICBk aWZmZXJlbnQgZG9tYWlucy4gIEJvdGggdGhlIHNpZ25hbGluZyBhbmQgbWVkaWEgZm9yIHRoZSBS ZWNvcmRpbmcKICAgU2Vzc2lvbiBuZWVkIHRoZSBhYmlsaXR5IHRvIGJlIGF1dGhlbnRpY2F0ZWQg YW5kIHByb3RlY3RlZCBmcm9tCiAgIGVhdmVzZHJvcHBpbmcuICBSZXF1aXJlbWVudHMgYXJlIGRl dGFpbGVkIGluIHRoZSByZXF1aXJlbWVudHMKICAgc2VjdGlvbi4KCiAgIENvbW11bmljYXRpb24g U2Vzc2lvbnMgYW5kIFJlY29yZGluZyBTZXNzaW9ucyBjYW4gcmVxdWlyZSBkaWZmZXJlbnQKICAg c2VjdXJpdHkgbGV2ZWxzIGJvdGggZm9yIHNpZ25hbGluZyBhbmQgbWVkaWEsIGRlcGVuZGluZyBv biBkZXBsb3ltZW50CiAgIGNvbmZpZ3VyYXRpb25zLiAgRm9yIHNvbWUgZW52aXJvbm1lbnRzLCBm b3IgZXhhbXBsZSwgU1JTIGFuZCBTUkMgd2lsbAogICBiZSBjb2xsb2NhdGVkIGluIGEgc2VjdXJl IG5ldHdvcmsgcmVnaW9uIGFuZCB0aGVyZWZvcmUgdGhlIFJTIHdpbGwKICAgbm90IHJlcXVpcmUg dGhlIHNhbWUgcHJvdGVjdGlvbiBsZXZlbCBhcyBhIENTIHRoYXQgZXh0ZW5kcyBvdmVyIGEKICAg cHVibGljIG5ldHdvcmssIGZvciBleGFtcGxlLiAgRm9yIG90aGVyIGVudmlyb25tZW50cywgdGhl IFNSUyBjYW4gYmUKICAgbG9jYXRlZCBpbiBhIHB1YmxpYyBjbG91ZCwgZm9yIGV4YW1wbGUsIGFu ZCB0aGUgUlMgd2lsbCByZXF1aXJlIGEKICAgaGlnaGVyIHByb3RlY3Rpb24gbGV2ZWwgdGhhbiB0 aGUgQ1MuICBGb3IgdGhlc2UgcmVhc29ucywgdGhlcmUgaXMgbm90CiAgIGEgZGlyZWN0IHJlbGF0 aW9uc2hpcCBiZXR3ZWVuIHRoZSBzZWN1cml0eSBsZXZlbCBvZiBDb21tdW5pY2F0aW9uCiAgIFNl c3Npb25zIGFuZCB0aGUgc2VjdXJpdHkgbGV2ZWwgb2YgUmVjb3JkaW5nIFNlc3Npb25zLgoKICAg QSBtYWxpY2lvdXMgb3IgY29ycnVwdCBTUkMgY2FuIHRhbXBlciB3aXRoIG1lZGlhIGFuZCBtZXRh ZGF0YQogICByZWxhdGluZyB0byBhIENTIGJlZm9yZSBzZW5kaW5nIHRvIGFuIFNSUy4gIEFsc28g Q1MgbWVkaWEgYW5kCiAgIHNpZ25hbGluZyBjYW4gYmUgdGFtcGVyZWQgd2l0aCBpbiB0aGUgbmV0 d29yayBwcmlvciB0byByZWFjaGluZyBhbgogICBTUkMsIHVubGVzcyBwcm9wZXIgbWVhbnMgYXJl IHByb3ZpZGVkIHRvIGVuc3VyZSBpbnRlZ3JpdHkgcHJvdGVjdGlvbgogICBkdXJpbmcgdHJhbnNt aXNzaW9uIG9uIHRoZSBDUy4gIE1lYW5zIGZvciBlbnN1cmluZyB0aGUgY29ycmVjdG5lc3Mgb2YK ICAgbWVkaWEgYW5kIG1ldGFkYXRhIGVtaXR0ZWQgYnkgYW4gU1JDIGFyZSBvdXRzaWRlIHRoZSBz Y29wZSBvZiB0aGlzCiAgIHdvcmsuICBPdGhlciBvcmdhbml6YXRpb25hbCBhbmQgdGVjaG5pY2Fs IGNvbnRyb2xzIHdpbGwgbmVlZCB0byBiZQoKCgpSZWhvciwgZXQgYWwuICAgICAgICAgICBFeHBp cmVzIE5vdmVtYmVyIDMwLCAyMDExICAgICAgICAgICAgICBbUGFnZSAxNF0KDApJbnRlcm5ldC1E cmFmdCAgICAgICAgICAgUmVxdWlyZW1lbnRzIGZvciBTSVBSRUMgICAgICAgICAgICAgICAgTWF5 IDIwMTEKCgogICB1c2VkIHRvIHByZXZlbnQgdGFtcGVyaW5nLgoKCjguICBJQU5BIENvbnNpZGVy YXRpb25zCgogICBUaGlzIGRvY3VtZW50IGhhcyBubyBJQU5BIGFjdGlvbnMuCgoKOS4gIEFja25v d2xlZGdlbWVudHMKCiAgIFRoYW5rcyB0byBEYW4gV2luZywgQWxhbiBKb2huc29uLCBWaWpheSBH dXJiYW5pLCBDdWxsZW4gSmVubmluZ3MsCiAgIEhhZHJpZWwgS2FwbGFuLCBIZW5yeSBMdW0sIERh dmUgU21pdGgsIE1hcnRpbiBQYWxtZXIsIEFsaXNzYSBDb29wZXIsCiAgIERlZXBhbnNodSBHYXV0 YW0sIFBhdWwgS3l6aXZhdCwgUGFydGhhc2FyYXRoaSBSLCBSYW0gTW9oYW4gUiwgYW5kCiAgIENo YXJsZXMgRWNrZWwgZm9yIHRoZWlyIHNpZ25pZmljYW50IGNvbnRyaWJ1dGlvbnMgYW5kIGFzc2lz dGFuY2Ugd2l0aAogICB0aGlzIGRvY3VtZW50IGFuZCBXb3JraW5nIEdyb3VwLCBhbmQgdG8gYWxs IHRoZSBtZW1iZXJzIG9mIHRoZQogICBESVNQQVRDSCBXRyBhbmQgU0lQUkVDIFdHIG1haWxpbmcg bGlzdHMgZm9yIHByb3ZpZGluZyB2YWx1YWJsZSBpbnB1dAogICB0byB0aGlzIHdvcmsuCgoKMTAu ICBOb3JtYXRpdmUgUmVmZXJlbmNlcwoKICAgW1JGQzIxMTldICBCcmFkbmVyLCBTLiwgIktleSB3 b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNhdGUKICAgICAgICAgICAgICBSZXF1aXJlbWVu dCBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5LCBNYXJjaCAxOTk3LgoKICAgW1JGQzMyNjFdICBS b3NlbmJlcmcsIEouLCBTY2h1bHpyaW5uZSwgSC4sIENhbWFyaWxsbywgRy4sIEpvaG5zdG9uLAog ICAgICAgICAgICAgIEEuLCBQZXRlcnNvbiwgSi4sIFNwYXJrcywgUi4sIEhhbmRsZXksIE0uLCBh bmQgRS4KICAgICAgICAgICAgICBTY2hvb2xlciwgIlNJUDogU2Vzc2lvbiBJbml0aWF0aW9uIFBy b3RvY29sIiwgUkZDIDMyNjEsCiAgICAgICAgICAgICAgSnVuZSAyMDAyLgoKICAgW1JGQzQxMDNd ICBIZWxsc3Ryb20sIEcuIGFuZCBQLiBKb25lcywgIlJUUCBQYXlsb2FkIGZvciBUZXh0CiAgICAg ICAgICAgICAgQ29udmVyc2F0aW9uIiwgUkZDIDQxMDMsIEp1bmUgMjAwNS4KCiAgIFtSRkM0NzMz XSAgU2NodWx6cmlubmUsIEguIGFuZCBULiBUYXlsb3IsICJSVFAgUGF5bG9hZCBmb3IgRFRNRgog ICAgICAgICAgICAgIERpZ2l0cywgVGVsZXBob255IFRvbmVzLCBhbmQgVGVsZXBob255IFNpZ25h bHMiLCBSRkMgNDczMywKICAgICAgICAgICAgICBEZWNlbWJlciAyMDA2LgoKICAgW1JGQzQ5NDld ICBTaGlyZXksIFIuLCAiSW50ZXJuZXQgU2VjdXJpdHkgR2xvc3NhcnksIFZlcnNpb24gMiIsCiAg ICAgICAgICAgICAgUkZDIDQ5NDksIEF1Z3VzdCAyMDA3LgoKCgoKCgoKCgoKCgoKUmVob3IsIGV0 IGFsLiAgICAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAzMCwgMjAxMSAgICAgICAgICAgICAgW1Bh Z2UgMTVdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgIFJlcXVpcmVtZW50cyBmb3IgU0lQUkVD ICAgICAgICAgICAgICAgIE1heSAyMDExCgoKQXV0aG9ycycgQWRkcmVzc2VzCgogICBLZW4gUmVo b3IgKGVkaXRvcikKICAgQ2lzY28gU3lzdGVtcwogICAxNzAgV2VzdCBUYXNtYW4gRHIuCiAgIE1h aWwgU3RvcCBTSkMzMC8yLwogICBTYW4gSm9zZSwgQ0EgIDk1MTM0CiAgIFVTQQoKICAgRW1haWw6 IGtyZWhvckBjaXNjby5jb20KCgogICBMZW9uIFBvcnRtYW4gKGVkaXRvcikKICAgTklDRSBTeXN0 ZW1zCiAgIDggSGFwbmluYQogICBSYSdhbmFuYSAgNDMwMTcKICAgSXNyYWVsCgogICBFbWFpbDog bGVvbi5wb3J0bWFuQG5pY2UuY29tCgoKICAgQW5kcmV3IEh1dHRvbgogICBTaWVtZW5zIEVudGVy cHJpc2UgQ29tbXVuaWNhdGlvbnMKCiAgIEVtYWlsOiBhbmRyZXcuaHV0dG9uQHNpZW1lbnMtZW50 ZXJwcmlzZS5jb20KICAgVVJJOiAgIGh0dHA6Ly93d3cuc2llbWVucy1lbnRlcnByaXNlLmNvbQoK CiAgIFJham5pc2ggSmFpbgogICBJUEMgU3lzdGVtcwogICA3NzcgQ29tbWVyY2UgRHJpdmUKICAg RmFpcmZpZWxkLCBDVCAgMDY4MjUKICAgVVNBCgogICBFbWFpbDogcmFqbmlzaC5qYWluQGlwYy5j b20KCgoKCgoKCgoKCgoKCgoKClJlaG9yLCBldCBhbC4gICAgICAgICAgIEV4cGlyZXMgTm92ZW1i ZXIgMzAsIDIwMTEgICAgICAgICAgICAgIFtQYWdlIDE2XQoMCg== --_004_07465C1D981ABC41A344374066AE1A2C38AC24E597TLVMBX01nicec_-- From Leon.Portman@nice.com Tue May 31 06:19: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 60FC0E07B7 for ; Tue, 31 May 2011 06:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.092 X-Spam-Level: X-Spam-Status: No, score=-2.092 tagged_above=-999 required=5 tests=[AWL=0.507, 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 YDdP4Cm5IZVE for ; Tue, 31 May 2011 06:19:10 -0700 (PDT) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id 7579AE0830 for ; Tue, 31 May 2011 06:19:09 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.15]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Tue, 31 May 2011 16:19:07 +0300 From: Leon Portman To: "Elwell, John" , "Parthasarathi R (partr)" , "Charles Eckel (eckelcu)" , "Ram Mohan R (rmohanr)" , "siprec@ietf.org" Date: Tue, 31 May 2011 16:19:05 +0300 Thread-Topic: [siprec] Can an MS object span several CSs in a CSG? Thread-Index: AcwZ5UbR730mQiXZRGSqd4Xx2cnzHgAHpFKQAAkglcAAAc/qEAAHiqxwAARuZ7AAEv0wYAAASlPQAA0tNiAAM/kssAAEs2agAPRFMhA= Message-ID: <07465C1D981ABC41A344374066AE1A2C38AC2C4A5E@TLVMBX01.nice.com> References: <35BCE99A477D6A4986FB2216D8CF2CFD067EECD7@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 Subject: Re: [siprec] Can an MS object span several CSs in a CSG? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 13:19:13 -0000 Hello I also having a problem even without a quantification of number of update m= essages that CS MS is remains same between different CS. So I do prefer to= keep it simple and keep it per CS. Leon -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Elwell, John Sent: Friday, May 27, 2011 12:26 PM To: Parthasarathi R (partr); Charles Eckel (eckelcu); Ram Mohan R (rmohanr)= ; siprec@ietf.org Subject: Re: [siprec] Can an MS object span several CSs in a CSG? =20 > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > Sent: 26 May 2011 15:55 > To: Elwell, John; Charles Eckel (eckelcu); Ram Mohan R (rmohanr);=20 > siprec@ietf.org > Subject: RE: [siprec] Can an MS object span several CSs in a CSG? >=20 > John, >=20 > The callflow mentioned by me is the basic primitive in the call center=20 > scenario wherein customer (participant) is same throughout the session=20 > and agents are changed using transfer service and B2BUA acts as SRC. > IMO, it is one of key requirement to be considered in case we support=20 > for partial-update. [JRE] Agreed the Participant remains the same, but we are discussing MS. > This may not be the only callflow where MS partial-update is required=20 > in this fashion. During -00 format draft, I thought that the=20 > partial-update is not required but lot of folks raised the concern=20 > that partial update is important. Current, -01 format draft is=20 > designed to support partial-update. Now, You propose to restrict MS=20 > partial-update across CS. IMO, it is a not good idea to restrict in=20 > the protocol level. Anyway, I think that we need others opinion before=20 > conclude here. [JRE] I am not opposed to partial update, but I would like to avoid distort= ing the model just to gain some efficiency improvements in certain cases. T= o me it is not intuitive that a MS on one CS and an MS on another CS are th= e same object, just because one of the Participants is common to both CSs. = In the transfer-between-agents example, although one of the Participants is= common to the two CSs, this is not true for the other Participants. Let's try to quantify the efficiency improvement. In the blind transfer cas= e, the partial updates would at least have to include: - the removal of P1 from CS1 (where P1 is the first agent and CS1 is the fi= rst CS); - the removal of P2 from CS1 (where P2 is the transferred participant); - the termination of CS1; - the removal of CS1 from CSG1; - the creation of CS2 (the CS that results from transfer); - the addition to of CS2 to CSG1; - the addition of P2 to CSG1; - the addition of P3 to CS2 (where P3 is the second agent); - the removal of P1 as a sender of MS1 (MS1 is from P1 to P2); - the removal of P2 as a recipient of MS1; - the termination of MS1; - the creation of MS3; - the addition of P3 as a sender of MS3; - the addition of P2 as a recipient of MS3. So all we are arguing about is whether we also include in the partial updat= es EITHER (this I think is your proposal): - the removal of P1 as a recipient of MS2; - the addition of P3 as a recipient of MS2; OR - the removal of P1 as recipient of MS2; - the removal of P2 as a sender of MS2; - the termination MS2; - the creation of MS4; - the addition of P3 as a recipient of MS4; - the addition of P2 as a sender of MS4. So with the first option the total number of deltas is 14+2=3D16. For the second option the total number of deltas is 14+6=3D20. Some of the details might be wrong, but I hope you can see the point I am g= etting at. Looked at this way, the efficiency saving by recycling MS2 for u= se in consecutive CSs is relatively small. Or perhaps your intention is als= o to recycle MS1 (this time, the recipient remaining the same but the sende= r changing). That would reduce the number of deltas slightly further. The i= mpact on XML size might not be quite in proportion to the reduction in the = number of deltas, since by recycling MS2 it has to have a global identifier= , not an identifier local to a CS. Or perhaps it could have an identifier l= ocal to a CSG. I also see that with your proposal it doesn't force the MS to be recycled -= an SRC could still choose to model it as separate MSs. However, in that ca= se it would still need to use global identifiers for MSs. I am not necessarily opposed to your proposal for recycling MS objects outs= ide the context of a single CS - I can see advantages and disadvantages. I = just want to make sure the group makes an informed decision. John (as individual) >=20 > Enhancing label attribute across the multiple SIP message to tie=20 > between Metadata XML and RS SDP m-line is possible. SRC has to ensure=20 > that label for the given RS SDP m-line should have same label=20 > throughout single CSG even though it span across multiple CS and=20 > multiple RS. Even then, it will not meet partial-update requirement as=20 > mentioned below in this mail thread. At this moment, I'm favoring URN=20 > UUID and not label attribute > enhancement. =20 >=20 > Please read inline >=20 > Thanks > Partha >=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Wednesday, May 25, 2011 7:17 PM > To: Parthasarathi R (partr); Charles Eckel (eckelcu); Ram Mohan R=20 > (rmohanr); siprec@ietf.org > Subject: RE: [siprec] Can an MS object span several CSs in a CSG? >=20 > =20 >=20 > > -----Original Message----- > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > Sent: 25 May 2011 08:48 > > To: Elwell, John; Charles Eckel (eckelcu); Ram Mohan R (rmohanr);=20 > > siprec@ietf.org > > Subject: RE: [siprec] Can an MS object span several CSs in a CSG? > >=20 > > John, > >=20 > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > 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). 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 > > [JRE] What harm is done (what do we lose) if, following > transfer, A's > > media stream is called MS3 and C's media stream is called MS4? > >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > To indicate MS1 as MS3, MS1 media block has to be > stopped in > > the partial-update and start MS3 separate which is not required in=20 > > case there is a means to have common MS1. > [JRE] It seems this distorts the model in order to give some minor=20 > efficiency improvement during metadata updates. I doubt that this=20 > alone is sufficient justification for having the MS persist from one=20 > CS to another CS. >=20 > >=20 > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > MS3 can reference the same SDP m-line (through a=3Dlabel) as MS1, and=20 > > likewise MS4 could reference the same SDP m-line as MS2, if we are=20 > > concerned about recycling media descriptions in RS SDP. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > As you mentioned, we will lose recycling of media > description > > in RS SDP without common value in media stream object for this=20 > > scenario. > [JRE] I don't understand your point. With my proposal we can still=20 > recycle RS SDP m-lines. >=20 > Agreed that Recycle is possible with your proposal.=20 > I indicated > the need for unique-id in this requirement >=20 > > AFAIK, Your proposal needs enhancement in RFC 4574 as label > attribute > > scope is within single SIP message and not required to be unique in=20 > > all SIP messages of a given dialog. > [JRE] But I think we could nail that down as a requirement of the=20 > SIPREC protocol. >=20 > John (as individual) >=20 > >=20 > > Thanks > > Partha > >=20 > > John (as individual) > >=20 > > >=20 > > > Thanks > > > Partha > > >=20 > > > -----Original Message----- > > > From: Charles Eckel (eckelcu) > > > Sent: Wednesday, May 25, 2011 1:39 AM > > > To: Ram Mohan R (rmohanr); Parthasarathi R (partr); > 'Elwell, John'; > > > 'siprec@ietf.org' > > > Subject: RE: [siprec] Can an MS object span several CSs in a CSG? > > >=20 > > > Hi Ram, > > >=20 > > > I think that is many cases, they will be treated as separate MSs=20 > > > due to the complexities you mention. However, I am trying to > understand if > > > Partha feels allowing an SRC to treat them as a single MS is still=20 > > > required. If not, then what is a use case? A concrete example=20 > > > would help me, and potentially others, to better understand the > > motivation behind > > > Partha's requirement for modeling media from multiple CSs > > as a single > > > MS. > > >=20 > > > Cheers, > > > Charles > > >=20 > > > > -----Original Message----- > > > > From: Ram Mohan R (rmohanr) > > > > Sent: Tuesday, May 24, 2011 9:36 AM > > > > To: Charles Eckel (eckelcu); Parthasarathi R (partr); > > Elwell, John; > > > > siprec@ietf.org > > > > Subject: RE: [siprec] Can an MS object span several CSs > in a CSG? > > > >=20 > > > > Charles, > > > >=20 > > > > I did bring about this specific usecase of MMOH/MOH > stream being > > > > played to different participants earlier and suggested that > > > they have > > > > to treated as a same MS across multiple CSs > (potentially recorded > > > using multiple RSs). > > > > Refer > > > >=20 > http://www.ietf.org/mail-archive/web/siprec/current/msg01886.html > > > >=20 > > > > We had several discussions on it and it and several > folks were in > > > > favor of treating it as separate MS as there would be > > > complexity in DB > > > design. > > > >=20 > > > > Regards, > > > > Ram > > > >=20 > > > >=20 > > > > > -----Original Message----- > > > > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On > > > > > Behalf Of Charles Eckel (eckelcu) > > > > > Sent: Tuesday, May 24, 2011 9:11 PM > > > > > To: Parthasarathi R (partr); Elwell, John; siprec@ietf.org > > > > > Subject: Re: [siprec] Can an MS object span several CSs > > in a CSG? > > > > > > > > > > Hi Partha, > > > > > > > > > > Is an example of this the same music on hold audio stream > > > existing > > > > > as the same MS within multiple CSs? If so, then I > > understand your > > > > > requirement to be that the SRC be able to indicate multiple=20 > > > > > instances of this audio stream within several CSs as > > > being the same > > > > > MS. Is that correct? > > > > > > > > > > Thanks, > > > > > Charles > > > > > > > > > > > -----Original Message----- > > > > > > From: siprec-bounces@ietf.org > > > [mailto:siprec-bounces@ietf.org] On > > > > > Behalf Of Parthasarathi R (partr) > > > > > > Sent: Tuesday, May 24, 2011 4:26 AM > > > > > > To: Elwell, John; siprec@ietf.org > > > > > > Subject: Re: [siprec] Can an MS object span several CSs > > > in a CSG? > > > > > > > > > > > > John, > > > > > > > > > > > > I agree that it is not mandatory to consider recorded > > > stream of a > > > > > > specific participant in several CS within the same > CSG as one > > > > > recorded > > > > > > stream but SIPREC protocol design MUST NOT restrict a > > > SRC in case > > > > > > it wishes to design in such a way. > > > > > > > > > > > > Thanks > > > > > > Partha > > > > > > > > > > > > -----Original Message----- > > > > > > From: siprec-bounces@ietf.org > > > [mailto:siprec-bounces@ietf.org] On > > > > > Behalf > > > > > > Of Elwell, John > > > > > > Sent: Tuesday, May 24, 2011 1:06 PM > > > > > > To: siprec@ietf.org > > > > > > Subject: [siprec] Can an MS object span several CSs > in a CSG? > > > > > > > > > > > > We seem to have consensus that a Media Stream object > > > represents a > > > > > > recorded media stream, contributed to by one, > several or all > > > > > > Participants. However, Partha also wrote: > > > > > > > > > > > > "2) Each MS lifetime related to CSG because participant > > > may move > > > > > > from one CS to another CS within single CSG and also > > > CSG will span > > >=20 > > > > > > across multiple RS." > > > > > > > > > > > > I am not sure we had resolved this during earlier > > > discussions on > > > > > > the scope of an MS object. Although the same > Participant can > > > > > > participate > > > > > in > > > > > > several CSs within the same CSG, I don't think the > > > recorded media > > > > > > streams need to be considered the same. Any other views? > > > > > > > > > > > > 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 > > >=20 > >=20 >=20 _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From internet-drafts@ietf.org Tue May 31 23:45: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 73F1DE07BA; Tue, 31 May 2011 23:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMp0PkvKLr74; Tue, 31 May 2011 23:45:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5ADE06B3; Tue, 31 May 2011 23:45:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110601064513.26263.96097.idtracker@ietfa.amsl.com> Date: Tue, 31 May 2011 23:45:13 -0700 Cc: siprec@ietf.org Subject: [siprec] I-D Action: draft-ietf-siprec-req-11.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, 01 Jun 2011 06:45:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP Recording Working Group of the IE= TF. Title : Use Cases and Requirements for SIP-based Media Recording= (SIPREC) Author(s) : Ken Rehor Leon Portman Andrew Hutton Rajnish Jain Filename : draft-ietf-siprec-req-11.txt Pages : 16 Date : 2011-05-31 Session recording is a critical requirement in many business communications environments such as call centers and financial trading floors. In some of these environments, all calls must be recorded for regulatory and compliance reasons. In others, calls may be recorded for quality control or business analytics. Recording is typically performed by sending a copy of the session media to the recording devices. This document specifies requirements for extensions to SIP that will manage delivery of RTP media to a recording device. This is being referred to as SIP-based Media Recording. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-siprec-req-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-siprec-req-11.txt