From john.elwell@siemens-enterprise.com Fri Jul 1 01:15: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 1E55221F8885 for ; Fri, 1 Jul 2011 01:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.149 X-Spam-Level: X-Spam-Status: No, score=-106.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, 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 G4SVA19gfvjq for ; Fri, 1 Jul 2011 01:15:01 -0700 (PDT) Received: from mail174.messagelabs.com (mail174.messagelabs.com [85.158.138.51]) by ietfa.amsl.com (Postfix) with SMTP id A9AB421F8780 for ; Fri, 1 Jul 2011 01:15:00 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-14.tower-174.messagelabs.com!1309508098!23325018!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 10408 invoked from network); 1 Jul 2011 08:14:58 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-14.tower-174.messagelabs.com with SMTP; 1 Jul 2011 08:14:58 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 8D34023F03E2; Fri, 1 Jul 2011 10:14:58 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 1 Jul 2011 10:14:58 +0200 From: "Elwell, John" To: Paul Kyzivat , "siprec@ietf.org" Date: Fri, 1 Jul 2011 10:14:56 +0200 Thread-Topic: [siprec] SDP recording attribute usages Thread-Index: Acw2kOSL6QXU4MwuTuG6Z42hxaRsuQBNOzjg Message-ID: References: <059AF07365DC474393A19A3AF187DF74073E6CC6@NAHALD.us.int.genesyslab.com> <4E0B77B6.5050204@cisco.com> In-Reply-To: <4E0B77B6.5050204@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] SDP recording attribute usages X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 08:15:03 -0000 =20 > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 29 June 2011 20:06 > To: siprec@ietf.org > Subject: Re: [siprec] SDP recording attribute usages >=20 > inline >=20 > On 6/29/2011 12:42 PM, Elwell, John wrote: > >> -----Original Message----- > >> From: siprec-bounces@ietf.org > >> [mailto:siprec-bounces@ietf.org] On Behalf Of Henry Lum > >> Sent: 29 June 2011 02:34 > >> To: siprec@ietf.org > >> Subject: [siprec] SDP recording attribute usages > >> > >> Hi, > >> > >> I want to explain how I see the a=3Drecord SDP attribute to be > >> used to indicate recording. > >> > >> I see two main scenarios with party A and B where the SRC is > >> one of the parties or the SRC is a B2BUA: > >> > >> 1) party A is the SRC > >> > >> When party A as UAC is sending an offer, party A may indicate > >> that recording is enabled and provide a=3Drecord:on in the SDP > >> offer. Party B sees that Party A is declaring the media > >> stream is being recorded. Party B is not an SRC and will not > >> be recording so it sends an SDP answer with a=3Drecord:off. The > >> SDP answer is telling party A that party B is not recording > >> even though party A as an SRC will record. > >> > >> When a reINVITE is sent by party A or B, the offer/answer > >> should indicate which party is continuing recording. For > >> example, party B sends reINVITE for whatever reason, party B > >> sends offer with a=3Drecord:off; when party A answers, party A > >> will send a=3Drecord:on to indicate that recording is still=20 > in progress. >=20 > As a continuation to the scenario, where B is not an SRC,=20 > this seems fine. >=20 > It gets tricky if B is also capable of being an SRC. It might=20 > want to do=20 > its own recording, rather than relying on the recording A is=20 > doing. Or=20 > it might not. Does it respond based on whether it decides to=20 > record? Or=20 > based on whether it *could* record? >=20 > Assume it responds based on whether it does record. Then at the=20 > reinvite, does it respond with a=3Drecord:no on the assumption=20 > that A will=20 > continue recording? It has no way to know that. >=20 > This seems similar to the issues around o/a for comedia. >=20 >=20 > >> 2) SRC is a B2BUA between party A and B > >> > >> This is similar to the above scenario, except that when party > >> A is sending an SDP offer, party A sets a=3Drecord:off since > >> party A is not recording. When the B2BUA gets the request and > >> forwards to party B, the B2BUA is also trying to record as an > >> SRC, the B2BUA rewrites the offer with a=3Drecord:on towards > >> party B. Party B sees that the media stream is being recorded > >> and sends SDP answer with a=3Drecord:off since party B is not > >> recording. The B2BUA then passes the SDP answer but rewrites > >> a=3Drecord:on to indicate to party A that the call is being recorded. >=20 > Do we also have the possibility of a b2bua that *isn't* an SRC, but=20 > wants recording??? If so then we can get into situations more=20 > like what=20 > is done for session timer. >=20 > >> When the B2BUA needs to perform some 3rd party call control, > >> B2BUA initiates a reINVITE to party A with no offer. Party A > >> sends 200 OK answer with a=3Drecord:off to B2BUA. B2BUA sends > >> reINVITE SDP offer to party B and sets a=3Drecord:on to > >> indicate that the recording is still in progress. Party B > >> responds 200 OK with SDP answer a=3Drecord:off. B2BUA rewrites > >> the answer with a=3Drecord:on as ACK to party A. >=20 > This works ok as long as the b2bua is an src, and neither A nor B are. >=20 > If either A or B is a recorder, does the b2bua continue to record? Or=20 > does it adjust its behavior? If it wants to adjust its behavior, how=20 > does it get enough info to know that the recording being done by A=20 > and/or B is sufficient? >=20 > > [JRE] There is another use case. The B2BUA turns recording=20 > on or off for some reason during the course of the CS.=20 > Presumably it would do similar to above, i.e., issue an=20 > offerless INVITE request to one of the parties. >=20 > I don't think this last case adds anything fundamentally new to the=20 > conveyance of the record flag. >=20 > *If* the goal of this attribute is just to ensure that all are aware=20 > recording is proceeding, and not *who* is doing the=20 > recording, and not=20 > *negotiating* who is doing the recording, then something like=20 > the above=20 > is about right. >=20 > I think that must be the goal. If we want to introduce=20 > negotiation over=20 > who will do recording, things will be much more complex. [JRE] If different SRCs on the path all have the potential to record, I wou= ld suggest that the fact that one is recording should not cause others not = to record. The recording policy of each SRC should be independent of other = SRCs. The 'recording' attribute does not indicate anything about the record= ing destination, so the assumption has to be that all the SRCs are sending = to different SRSs. In many cases these will be in different domains (e.g., = different enterprises). Even if two SRCs send recordings to the same SRS, t= hey might need to be treated as different recordings (e.g., with different = 'owners', different retention policy, etc.). I don't think we should attemp= t to cater for any optimisations for the special case where two SRCs are se= nding recordings to the same SRS for treatment as the same recording. So I = think we are in agreement. John (as individual) >=20 > Thanks, > Paul > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > = From john.elwell@siemens-enterprise.com Fri Jul 1 01:17: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 50BB721F87E1 for ; Fri, 1 Jul 2011 01:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.432 X-Spam-Level: X-Spam-Status: No, score=-106.432 tagged_above=-999 required=5 tests=[AWL=0.167, 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 TJehznlOaWmo for ; Fri, 1 Jul 2011 01:17:14 -0700 (PDT) Received: from mail174.messagelabs.com (mail174.messagelabs.com [85.158.138.51]) by ietfa.amsl.com (Postfix) with SMTP id 6196921F87DC for ; Fri, 1 Jul 2011 01:17:14 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-5.tower-174.messagelabs.com!1309508233!21877250!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 14504 invoked from network); 1 Jul 2011 08:17:13 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-5.tower-174.messagelabs.com with SMTP; 1 Jul 2011 08:17:13 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 8B3771EB83ED for ; Fri, 1 Jul 2011 10:17:13 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 1 Jul 2011 10:17:13 +0200 From: "Elwell, John" To: "siprec@ietf.org" Date: Fri, 1 Jul 2011 10:17:12 +0200 Thread-Topic: Consensus calls arising from interim meeting - closes 2011-06-30 Thread-Index: AcwyVUA12HIIy9OESf+IyDInOZp1ZQFcchYQ Message-ID: Keywords: SIPREC Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Consensus calls arising from interim meeting - closes 2011-06-30 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 08:17:15 -0000 I saw no objections to these consensus calls. So I would ask the metadata d= raft editors please to incorporate in the next (merged) version.=20 John > -----Original Message----- > From: Elwell, John=20 > Sent: 24 June 2011 10:58 > To: siprec@ietf.org > Subject: Consensus calls arising from interim meeting -=20 > closes 2011-06-30 >=20 > On yesterday's call there was consensus on a number of items.=20 > These need to be confirmed. Please say by 2011-06-30 if you=20 > object to any of the following: >=20 > 1. We will use a globally unique identifier for a MS object.=20 > Although some people felt that an MS would not normally have=20 > a lifetime outside the lifetime of a CS, and therefore a=20 > local ID might suffice, some felt that there might be some=20 > corner cases that might benefit from a global ID. So the=20 > consensus on the call was for a global ID, although most=20 > anticipated uses of an MS element would be in the context of=20 > a single CS. Note that the nature of the globally unique ID=20 > is still open. >=20 > 2. The content of an MS object will be described in terms of=20 > value from the RFC 4796 registry. Note that how this is=20 > conveyed (in metadata XML or in RS SDP) is still open. Note=20 > also that if additional values are found to be necessary,=20 > these could be defined by the appropriate means. >=20 > 3. Extension data will be made part of the parent element,=20 > and not a separate element. Therefore it will not require its=20 > own unique ID. >=20 >=20 > John > = From eckelcu@cisco.com Fri Jul 1 10:13: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 3EEE81F0C8B for ; Fri, 1 Jul 2011 10:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_16=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 d0reMxAyZeiz for ; Fri, 1 Jul 2011 10:13:01 -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 A24B21F0CA6 for ; Fri, 1 Jul 2011 10:12:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=6639; q=dns/txt; s=iport; t=1309540328; x=1310749928; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=HT8EKrg411qqCocwtmulYIlcjWSulFrjy8ffkWPoed8=; b=guGQ1J1EJ0aSvjbQe52Lqkw8gOsoIbJ+2TO8Eh51FxtViFth3drrCMAb AxJDAUWouXkpjExYV7fivLJs5O3aXFTh+zvCo+nrgY+o+7Qd8IEgq9Fj1 4xLedb7c7wgZ+rv/PAokAkW3eQTcXfwMftWTuyikXbYSYqCPcyCyhBPXk o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEBAE3/DU6rRDoJ/2dsb2JhbABSmDOPNXerT511hjIEhz6Pc4tS X-IronPort-AV: E=Sophos;i="4.65,459,1304294400"; d="scan'208";a="351556326" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 01 Jul 2011 17:11:50 +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 p61HBooY020496; Fri, 1 Jul 2011 17:11:50 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, 1 Jul 2011 10:11: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: Fri, 1 Jul 2011 10:11:48 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] SDP recording attribute usages Thread-Index: Acw2kOSL6QXU4MwuTuG6Z42hxaRsuQBNOzjgABL144A= References: <059AF07365DC474393A19A3AF187DF74073E6CC6@NAHALD.us.int.genesyslab.com><4E0B77B6.5050204@cisco.com> From: "Charles Eckel (eckelcu)" To: "Elwell, John" , "Paul Kyzivat (pkyzivat)" , X-OriginalArrivalTime: 01 Jul 2011 17:11:49.0987 (UTC) FILETIME=[F733D330:01CC3811] Subject: Re: [siprec] SDP recording attribute usages X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 17:13:02 -0000 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > Sent: Friday, July 01, 2011 1:15 AM > To: Paul Kyzivat (pkyzivat); siprec@ietf.org > Subject: Re: [siprec] SDP recording attribute usages >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > > Sent: 29 June 2011 20:06 > > To: siprec@ietf.org > > Subject: Re: [siprec] SDP recording attribute usages > > > > inline > > > > On 6/29/2011 12:42 PM, Elwell, John wrote: > > >> -----Original Message----- > > >> From: siprec-bounces@ietf.org > > >> [mailto:siprec-bounces@ietf.org] On Behalf Of Henry Lum > > >> Sent: 29 June 2011 02:34 > > >> To: siprec@ietf.org > > >> Subject: [siprec] SDP recording attribute usages > > >> > > >> Hi, > > >> > > >> I want to explain how I see the a=3Drecord SDP attribute to be > > >> used to indicate recording. > > >> > > >> I see two main scenarios with party A and B where the SRC is > > >> one of the parties or the SRC is a B2BUA: > > >> > > >> 1) party A is the SRC > > >> > > >> When party A as UAC is sending an offer, party A may indicate > > >> that recording is enabled and provide a=3Drecord:on in the SDP > > >> offer. Party B sees that Party A is declaring the media > > >> stream is being recorded. Party B is not an SRC and will not > > >> be recording so it sends an SDP answer with a=3Drecord:off. The > > >> SDP answer is telling party A that party B is not recording > > >> even though party A as an SRC will record. > > >> > > >> When a reINVITE is sent by party A or B, the offer/answer > > >> should indicate which party is continuing recording. For > > >> example, party B sends reINVITE for whatever reason, party B > > >> sends offer with a=3Drecord:off; when party A answers, party A > > >> will send a=3Drecord:on to indicate that recording is still > > in progress. > > > > As a continuation to the scenario, where B is not an SRC, > > this seems fine. > > > > It gets tricky if B is also capable of being an SRC. It might > > want to do > > its own recording, rather than relying on the recording A is > > doing. Or > > it might not. Does it respond based on whether it decides to > > record? Or > > based on whether it *could* record? > > > > Assume it responds based on whether it does record. Then at the > > reinvite, does it respond with a=3Drecord:no on the assumption > > that A will > > continue recording? It has no way to know that. > > > > This seems similar to the issues around o/a for comedia. > > > > > > >> 2) SRC is a B2BUA between party A and B > > >> > > >> This is similar to the above scenario, except that when party > > >> A is sending an SDP offer, party A sets a=3Drecord:off since > > >> party A is not recording. When the B2BUA gets the request and > > >> forwards to party B, the B2BUA is also trying to record as an > > >> SRC, the B2BUA rewrites the offer with a=3Drecord:on towards > > >> party B. Party B sees that the media stream is being recorded > > >> and sends SDP answer with a=3Drecord:off since party B is not > > >> recording. The B2BUA then passes the SDP answer but rewrites > > >> a=3Drecord:on to indicate to party A that the call is being recorded. > > > > Do we also have the possibility of a b2bua that *isn't* an SRC, but > > wants recording??? If so then we can get into situations more > > like what > > is done for session timer. > > > > >> When the B2BUA needs to perform some 3rd party call control, > > >> B2BUA initiates a reINVITE to party A with no offer. Party A > > >> sends 200 OK answer with a=3Drecord:off to B2BUA. B2BUA sends > > >> reINVITE SDP offer to party B and sets a=3Drecord:on to > > >> indicate that the recording is still in progress. Party B > > >> responds 200 OK with SDP answer a=3Drecord:off. B2BUA rewrites > > >> the answer with a=3Drecord:on as ACK to party A. > > > > This works ok as long as the b2bua is an src, and neither A nor B are. > > > > If either A or B is a recorder, does the b2bua continue to record? Or > > does it adjust its behavior? If it wants to adjust its behavior, how > > does it get enough info to know that the recording being done by A > > and/or B is sufficient? > > > > > [JRE] There is another use case. The B2BUA turns recording > > on or off for some reason during the course of the CS. > > Presumably it would do similar to above, i.e., issue an > > offerless INVITE request to one of the parties. > > > > I don't think this last case adds anything fundamentally new to the > > conveyance of the record flag. > > > > *If* the goal of this attribute is just to ensure that all are aware > > recording is proceeding, and not *who* is doing the > > recording, and not > > *negotiating* who is doing the recording, then something like > > the above > > is about right. > > > > I think that must be the goal. If we want to introduce > > negotiation over > > who will do recording, things will be much more complex. > [JRE] If different SRCs on the path all have the potential to record, I would suggest that the fact > that one is recording should not cause others not to record. The recording policy of each SRC should > be independent of other SRCs. The 'recording' attribute does not indicate anything about the recording > destination, so the assumption has to be that all the SRCs are sending to different SRSs. In many > cases these will be in different domains (e.g., different enterprises). Even if two SRCs send > recordings to the same SRS, they might need to be treated as different recordings (e.g., with > different 'owners', different retention policy, etc.). I don't think we should attempt to cater for > any optimisations for the special case where two SRCs are sending recordings to the same SRS for > treatment as the same recording. So I think we are in agreement. >=20 > John (as individual) This was a use case I suggested previously, but it was deemed out of scope, so I agree with John that this should not be an issue given our limited scope of a SIPREC recording being limited to a single SRC and a single SRS. Cheers, Charles =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 Leon.Portman@nice.com Sun Jul 3 03:36: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 8D32A21F87A4 for ; Sun, 3 Jul 2011 03:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_16=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 7HdIJVrb-zEs for ; Sun, 3 Jul 2011 03:36:38 -0700 (PDT) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA4A21F87A0 for ; Sun, 3 Jul 2011 03:36:37 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Sun, 3 Jul 2011 13:36:36 +0300 From: Leon Portman To: "Charles Eckel (eckelcu)" , "Elwell, John" , "Paul Kyzivat (pkyzivat)" , "siprec@ietf.org" Date: Sun, 3 Jul 2011 13:36:35 +0300 Thread-Topic: [siprec] SDP recording attribute usages Thread-Index: Acw2kOSL6QXU4MwuTuG6Z42hxaRsuQBNOzjgABL144AAVsyg4A== Message-ID: <07465C1D981ABC41A344374066AE1A2C38AF6D40C1@TLVMBX01.nice.com> References: <059AF07365DC474393A19A3AF187DF74073E6CC6@NAHALD.us.int.genesyslab.com><4E0B77B6.5050204@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] SDP recording attribute usages X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 10:36:39 -0000 Hello I agree with the logic below. Recording flag is only indication and not neg= otiation of who will do recording.=20 Leon -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Charles Eckel (eckelcu) Sent: Friday, July 01, 2011 8:12 PM To: Elwell, John; Paul Kyzivat (pkyzivat); siprec@ietf.org Subject: Re: [siprec] SDP recording attribute usages > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > Sent: Friday, July 01, 2011 1:15 AM > To: Paul Kyzivat (pkyzivat); siprec@ietf.org > Subject: Re: [siprec] SDP recording attribute usages >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > > Sent: 29 June 2011 20:06 > > To: siprec@ietf.org > > Subject: Re: [siprec] SDP recording attribute usages > > > > inline > > > > On 6/29/2011 12:42 PM, Elwell, John wrote: > > >> -----Original Message----- > > >> From: siprec-bounces@ietf.org > > >> [mailto:siprec-bounces@ietf.org] On Behalf Of Henry Lum > > >> Sent: 29 June 2011 02:34 > > >> To: siprec@ietf.org > > >> Subject: [siprec] SDP recording attribute usages > > >> > > >> Hi, > > >> > > >> I want to explain how I see the a=3Drecord SDP attribute to be used= =20 > > >> to indicate recording. > > >> > > >> I see two main scenarios with party A and B where the SRC is one=20 > > >> of the parties or the SRC is a B2BUA: > > >> > > >> 1) party A is the SRC > > >> > > >> When party A as UAC is sending an offer, party A may indicate=20 > > >> that recording is enabled and provide a=3Drecord:on in the SDP=20 > > >> offer. Party B sees that Party A is declaring the media stream is=20 > > >> being recorded. Party B is not an SRC and will not be recording=20 > > >> so it sends an SDP answer with a=3Drecord:off. The SDP answer is=20 > > >> telling party A that party B is not recording even though party A=20 > > >> as an SRC will record. > > >> > > >> When a reINVITE is sent by party A or B, the offer/answer should=20 > > >> indicate which party is continuing recording. For example, party=20 > > >> B sends reINVITE for whatever reason, party B sends offer with=20 > > >> a=3Drecord:off; when party A answers, party A will send a=3Drecord:o= n=20 > > >> to indicate that recording is still > > in progress. > > > > As a continuation to the scenario, where B is not an SRC, this seems=20 > > fine. > > > > It gets tricky if B is also capable of being an SRC. It might want=20 > > to do its own recording, rather than relying on the recording A is=20 > > doing. Or it might not. Does it respond based on whether it decides=20 > > to record? Or based on whether it *could* record? > > > > Assume it responds based on whether it does record. Then at the=20 > > reinvite, does it respond with a=3Drecord:no on the assumption that A=20 > > will continue recording? It has no way to know that. > > > > This seems similar to the issues around o/a for comedia. > > > > > > >> 2) SRC is a B2BUA between party A and B > > >> > > >> This is similar to the above scenario, except that when party A=20 > > >> is sending an SDP offer, party A sets a=3Drecord:off since party A=20 > > >> is not recording. When the B2BUA gets the request and forwards to=20 > > >> party B, the B2BUA is also trying to record as an SRC, the B2BUA=20 > > >> rewrites the offer with a=3Drecord:on towards party B. Party B sees= =20 > > >> that the media stream is being recorded and sends SDP answer with=20 > > >> a=3Drecord:off since party B is not recording. The B2BUA then=20 > > >> passes the SDP answer but rewrites a=3Drecord:on to indicate to=20 > > >> party A that the call is being recorded. > > > > Do we also have the possibility of a b2bua that *isn't* an SRC, but=20 > > wants recording??? If so then we can get into situations more like=20 > > what is done for session timer. > > > > >> When the B2BUA needs to perform some 3rd party call control,=20 > > >> B2BUA initiates a reINVITE to party A with no offer. Party A=20 > > >> sends 200 OK answer with a=3Drecord:off to B2BUA. B2BUA sends=20 > > >> reINVITE SDP offer to party B and sets a=3Drecord:on to indicate=20 > > >> that the recording is still in progress. Party B responds 200 OK=20 > > >> with SDP answer a=3Drecord:off. B2BUA rewrites the answer with=20 > > >> a=3Drecord:on as ACK to party A. > > > > This works ok as long as the b2bua is an src, and neither A nor B are. > > > > If either A or B is a recorder, does the b2bua continue to record? Or > > does it adjust its behavior? If it wants to adjust its behavior, how=20 > > does it get enough info to know that the recording being done by A=20 > > and/or B is sufficient? > > > > > [JRE] There is another use case. The B2BUA turns recording > > on or off for some reason during the course of the CS. > > Presumably it would do similar to above, i.e., issue an offerless=20 > > INVITE request to one of the parties. > > > > I don't think this last case adds anything fundamentally new to the=20 > > conveyance of the record flag. > > > > *If* the goal of this attribute is just to ensure that all are aware=20 > > recording is proceeding, and not *who* is doing the recording, and=20 > > not > > *negotiating* who is doing the recording, then something like the=20 > > above is about right. > > > > I think that must be the goal. If we want to introduce negotiation=20 > > over who will do recording, things will be much more complex. > [JRE] If different SRCs on the path all have the potential to record, I would suggest that the fact > that one is recording should not cause others not to record. The recording policy of each SRC should > be independent of other SRCs. The 'recording' attribute does not indicate anything about the recording > destination, so the assumption has to be that all the SRCs are sending to different SRSs. In many > cases these will be in different domains (e.g., different enterprises). Even if two SRCs send > recordings to the same SRS, they might need to be treated as different recordings (e.g., with > different 'owners', different retention policy, etc.). I don't think we should attempt to cater for > any optimisations for the special case where two SRCs are sending recordings to the same SRS for > treatment as the same recording. So I think we are in agreement. >=20 > John (as individual) This was a use case I suggested previously, but it was deemed out of scope,= so I agree with John that this should not be an issue given our limited sc= ope of a SIPREC recording being limited to a single SRC and a single SRS. Cheers, Charles =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 _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From Leon.Portman@nice.com Sun Jul 3 03:37: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 DB80421F87A0 for ; Sun, 3 Jul 2011 03:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_110=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 k87tc5m5YbJz for ; Sun, 3 Jul 2011 03:37:53 -0700 (PDT) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id 14DBB21F878A for ; Sun, 3 Jul 2011 03:37:53 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Sun, 3 Jul 2011 13:37:52 +0300 From: Leon Portman To: "Elwell, John" , Henry Lum , "siprec@ietf.org" Date: Sun, 3 Jul 2011 13:37:51 +0300 Thread-Topic: a=recordpref:nopreference value? Thread-Index: Acw1/LwEw99bBbeYRn+z23aoGgpyRQAfwSegALxcySA= Message-ID: <07465C1D981ABC41A344374066AE1A2C38AF6D40C4@TLVMBX01.nice.com> References: <059AF07365DC474393A19A3AF187DF74073E6CCB@NAHALD.us.int.genesyslab.com> In-Reply-To: Accept-Language: en-US, he-IL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, he-IL Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] a=recordpref:nopreference value? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 10:37:54 -0000 I am ok with both. Adding nopreference can improve readability of the messa= ge Leon -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Elwell, John Sent: Wednesday, June 29, 2011 7:47 PM To: Henry Lum; siprec@ietf.org Subject: Re: [siprec] a=3Drecordpref:nopreference value? =20 > -----Original Message----- > From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On Behalf Of Henry Lum > Sent: 29 June 2011 02:48 > To: siprec@ietf.org > Subject: [siprec] a=3Drecordpref:nopreference value? >=20 > Hi, >=20 > =20 >=20 > One of the questions in the interim meeting is about whether we need a=20 > separate value in recording preference to indicate "no preference".=20 > Currently we are assuming the absence of such attribute a=3Drecordpref=20 > means there is no indication. In the meeting it was brought up that=20 > not putting the indication can also mean the UA is unaware of this=20 > attribute. >=20 > =20 >=20 > If we add the value no preference to the attribute, I think this=20 > implies that a recording-aware UA must always include this attribute=20 > to indicate that it is recording-aware plus it is including the=20 > preference in all offer/answer. I don't feel too strongly about=20 > requiring this because this makes SDP a bit too chatty to indicate no=20 > preference. [JRE] We will have a SIP option tag to indicate recording-aware, won't we? = So I don't think needing to distinguish between aware and unaware is a vali= d argument. Having said that, I don't object to having a 'no preference' va= lue, but I don't have a strong opinion. John (as individual) >=20 > =20 >=20 > What do others think? >=20 > =20 >=20 > Henry >=20 > =20 >=20 >=20 > CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain=20 > confidential and proprietary information of Alcatel-Lucent and/or its=20 > affiliated entities. Access by the intended recipient only is=20 > authorized. Any liability arising from any party acting, or refraining=20 > from acting, on any information contained in this e-mail is hereby=20 > excluded. If you are not the intended recipient, please notify the=20 > sender immediately, destroy the original transmission and its=20 > attachments and do not disclose the contents to any other person, use=20 > it for any purpose, or store or copy the information in any medium.=20 > Copyright in this e-mail and any attachments belongs to Alcatel-Lucent=20 > and/or its affiliated entities. >=20 _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From Leon.Portman@nice.com Sun Jul 3 03:43: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 86C4A1F0C37 for ; Sun, 3 Jul 2011 03:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[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 0wI37MJiQOYG for ; Sun, 3 Jul 2011 03:43:19 -0700 (PDT) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3B61F0C35 for ; Sun, 3 Jul 2011 03:43:18 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Sun, 3 Jul 2011 13:43:17 +0300 From: Leon Portman To: "Charles Eckel (eckelcu)" , "Elwell, John" , "Parthasarathi R (partr)" , "siprec@ietf.org" Date: Sun, 3 Jul 2011 13:43:16 +0300 Thread-Topic: [siprec] Content (RFC 4796) attribute in SDP or XML Thread-Index: Acw0mPHhxfeVJEDcQLSYWo3IAZGl7wABDbXgACpfOfAADTnVAAA/CH7wAL12yxA= Message-ID: <07465C1D981ABC41A344374066AE1A2C38AF6D40CC@TLVMBX01.nice.com> References: 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] Content (RFC 4796) attribute in SDP or XML X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 10:43:19 -0000 I do prefer that metadata XML will be as self-contained as possible and not= rely on conveying some data via RS SDP. RS SDP should only be used to reco= rding establishment and negotiation and not as a mechanism for metadata rep= orting. Otherwise we will not be able to reuse same format for reporting metadata v= ia web services or as dedicated SIP session. As for examples, the basic information as media type, labels, volume etc. A= ny application level data can be relevant. Even indication of encryption (f= or a case where RS is not encrypted) Leon -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Charles Eckel (eckelcu) Sent: Wednesday, June 29, 2011 7:17 PM To: Elwell, John; Parthasarathi R (partr); siprec@ietf.org Subject: Re: [siprec] Content (RFC 4796) attribute in SDP or XML I think it is sufficient, especially since we can assign new values if nece= ssary. Are there any examples of what people think they might want to capture in t= he SDP and/or metadata field? Cheers, Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > Sent: Tuesday, June 28, 2011 3:11 AM > To: Parthasarathi R (partr); siprec@ietf.org > Subject: Re: [siprec] Content (RFC 4796) attribute in SDP or XML >=20 > I would like other opinions on whether the SDP a=3Dcontent attribute in the RS SDP has the correct > semantics for representing the content type of the recorded CS media stream. >=20 > John >=20 > > -----Original Message----- > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > Sent: 28 June 2011 10:45 > > To: Elwell, John; siprec@ietf.org > > Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > Subject: RE: Content (RFC 4796) attribute in SDP or XML > > > > John, > > > > In case if it is the argument of whether CS MS content type or RS MS=20 > > content type in the metadata, it is better for us to re-open ticket=20 > > #71=20 > > (http://www.ietf.org/mail-archive/web/siprec/current/msg02106.html). > > Please let me know your opinion here. > > > > The basic idea in metadata format is to re-use as much as SDP=20 > > attribute (like direction, content) in media level for RS dialog=20 > > (using SDP label attribute as a pointer) until otherwise there is a=20 > > restriction in using in such manner. As per RFC 4796, there is no=20 > > such restriction and so, I prefer to reuse as content SDP attribute=20 > > rather than introducing the new element for this=20 > > purpose. > > > > Thanks > > Partha > > > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Monday, June 27, 2011 1:18 PM > > To: Parthasarathi R (partr); siprec@ietf.org > > Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > Subject: RE: Content (RFC 4796) attribute in SDP or XML > > > > > > > > > -----Original Message----- > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > Sent: 27 June 2011 08:08 > > > To: siprec@ietf.org; Elwell, John > > > Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > > Subject: Content (RFC 4796) attribute in SDP or XML > > > > > > Hi all, > > > > > > As per the last interim SIPREC meeting, there is a consensus to=20 > > > describe the content of an MS using RFC 4796 & its > > extension. As per > > > RFC 4796, the multiple instance of content attribute is possible to > > > exist in SDP which shall be used in RS SDP. SRS shall group > > the same > > > media content types by "content" attribute in RS SDP. We are=20 > > > interested in knowing any specfic reason for this attribute to be=20 > > > duplicated in Metadata XML. > > [JRE] I don't have a reason for **duplication**. However, I think=20 > > there is a valid question to be asked whether the content type of an=20 > > MS should be represented: > > A) in XML; or > > B) in RS SDP as a=3Dcontent. > > > > The content type we are talking about is an MS content type, i.e.,=20 > > relating to the CS. One could argue that the corresponding RS stream=20 > > is NOT the same content type. For example: > > - CS MS content type is "slides". > > - RS media stream content type is "recording of slides". > > > > On this basis, I think the correct option for conveying the MS content > > type "slides" is A) (in the XML). > > > > Note that this would not involve duplication. The SDP a=3Dcontent=20 > > attribute is optional, so we need not use it for the RS. > > > > Perhaps my distinction is too theoretical, but I do feel a little more > > comfortable using the XML rather than the RS SDP. > > > > John (as individual) > > > > > > > > > > Thanks > > > > > > Partha > > > > > > last Interim SIPREC meeting Note: > > > > > > Slide 7: On the question of how to describe the content of an MS,=20 > > > there was no objection to basing this on the types in the RFC 4796=20 > > > registry (new values could be specified via the appropriate > > means if > > > needed). Paul had a slight concern that you might be mixing > > multiple > > > CS MSs into a single RS media stream and whether this might > > result in > > > cases not describable in this way, but in the end accepted the=20 > > > consensus. It needs to be discussed on the list whether this is=20 > > > conveyed in XML or in the RS SDP a=3Dcontent attribute. > > > > > > > > > _______________________________________________ > siprec mailing 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 Sun Jul 3 03:50: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 43BC521F863F for ; Sun, 3 Jul 2011 03:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] 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 hvBAPYr27rhF for ; Sun, 3 Jul 2011 03:50:28 -0700 (PDT) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id 563CE21F841F for ; Sun, 3 Jul 2011 03:50:28 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Sun, 3 Jul 2011 13:50:27 +0300 From: Leon Portman To: Paul Kyzivat , "siprec@ietf.org" Date: Sun, 3 Jul 2011 13:50:26 +0300 Thread-Topic: [siprec] Format options for unique IDs Thread-Index: AcwyfFeySQ0KQgRkS2aughHAMQhc7gG8nSvQ Message-ID: <07465C1D981ABC41A344374066AE1A2C38AF6D40D7@TLVMBX01.nice.com> References: <4E04A13F.8090506@cisco.com> In-Reply-To: <4E04A13F.8090506@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] Format options for unique IDs X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 10:50:29 -0000 I am ok with all options. Actually the question is if from SRS point of vie= w, should it even care? It will be just string with identifier. Should it h= ave any assumptions about it expect uniqueness? Leon -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Paul Kyzivat Sent: Friday, June 24, 2011 5:38 PM To: siprec@ietf.org Subject: [siprec] Format options for unique IDs On 6/24/2011 5:58 AM, Elwell, John wrote: > - Options for globally unique IDs, along with pros and cons (Partha to=20 > initiate) I'm not Partha, but I'll comment. Some possibilities: A) A generic URN, with added constraint that equality is based only on lexical equivalence (as defined in rfc 2141) B) UUID URN (rfc 4122) C) UUID encoded more densely than the UUID URN (e.g. radix64 of the binary uuid form defined in 4122) Pros/cons of these: A) Pro: very flexible for the SRC. It has many options for how to create and encode IDs. Pro: ease of generation, assuming the SRC chooses wisely. Con: Difficult for the SRS. It must deal with variable unbounded length ID. Doesn't easily fit in databases. Con: Somewhat inefficient wire encoding: there is minimum length of "URN:" plus NID (namespace identifier). Pro/Con: Wire efficiency varies depending on SRC choices. Could be very good or very bad, depending on what NID is chosen. B) Pro: very flexible for the SRC. 4122 provides multiple ways of generating the UUID. One of them (the name based one) would allow generating a UUID from the same strings you might use for (A), so its at least as flexible as (A). Pro: easy of generation. Like (A), but then requires an SHA-1 computation. So not as easy as (A). Pro: Simple for SRS. The UUID can be easily extracted from the URN and converted to a fixed length (16 bytes) binary value. That value then can be stored in databases, compared, etc. Con: Somewhat inefficient wire encoding. The urn encoding is 45 bytes. Pro: Flexible to future extension to other sorts of URNs (e.g. (A)) due to the use of the URN syntax. C) Pro: very flexible for the SRC. (Identical to (B)) Pro: easy of generation. Virtually the same as (B). (The final textual formatting is different from (B), but similar (insignificant) computationally.) Pro: Simple for SRS. Virtually the same as (B). (The final textual formatting is different from (B), but similar (insignificant) computationally.) Pro: Efficient wire encoding. (Radix 64 takes 22 bytes to represent the 16 binary bytes.) For the metadata these would probably all be wrapped in XML in comparable w= ays, so none has an advantage over another in that respect. Please feel free to propose other alternatives. As a specific example, for the UUIDs, one could use the 4122 "name based" a= pproach, where the "name" is just a binary integer counter. Thanks, Paul _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From partr@cisco.com Sun Jul 3 09:49: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 E0F4B21F86EC for ; Sun, 3 Jul 2011 09:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.596 X-Spam-Level: X-Spam-Status: No, score=-9.596 tagged_above=-999 required=5 tests=[AWL=0.403, 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 9LOCRyAyWjqS for ; Sun, 3 Jul 2011 09:49:46 -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 3F69021F86FD for ; Sun, 3 Jul 2011 09:49:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=7215; q=dns/txt; s=iport; t=1309711786; x=1310921386; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=W356fqszvJG64VPp4u6En09F8Wy43LrOgvGC8/CAk0U=; b=fiMc31os0vnMBiwPWeHU/s3N3yhjyjqzME7BDAlGxDcZbAe+Or5aI0Zi Eb6aic9lCEPN6sxVuxDADQ3dqqSq0GCeZs882JMpmI/FGVmDKaTZMKOAD z6QAniir2fyXBiZ+iARbvWJkTNnT+8IWZ2PoK82enTYtrtAl8McZGbeR3 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvIAAL2cEE5Io8UT/2dsb2JhbABSmEiPNXeIeqNNnH6GNgSHPY96iz0 X-IronPort-AV: E=Sophos;i="4.65,468,1304294400"; d="scan'208";a="40357181" Received: from bgl-core-4.cisco.com ([72.163.197.19]) by ams-iport-2.cisco.com with ESMTP; 03 Jul 2011 16:49:43 +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 p63Gngms027312; Sun, 3 Jul 2011 16:49:42 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); Sun, 3 Jul 2011 22:19: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: Sun, 3 Jul 2011 22:19:35 +0530 Message-ID: In-Reply-To: <07465C1D981ABC41A344374066AE1A2C38AF6D40CC@TLVMBX01.nice.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Content (RFC 4796) attribute in SDP or XML Thread-Index: Acw0mPHhxfeVJEDcQLSYWo3IAZGl7wABDbXgACpfOfAADTnVAAA/CH7wAL12yxAADByJIA== References: <07465C1D981ABC41A344374066AE1A2C38AF6D40CC@TLVMBX01.nice.com> From: "Parthasarathi R (partr)" To: "Leon Portman" , "Charles Eckel (eckelcu)" , "Elwell, John" , X-OriginalArrivalTime: 03 Jul 2011 16:49:43.0033 (UTC) FILETIME=[351A3690:01CC39A1] Subject: Re: [siprec] Content (RFC 4796) attribute in SDP or XML X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 16:49:48 -0000 Leon, Please read inline. Thanks Partha=20 -----Original Message----- From: Leon Portman [mailto:Leon.Portman@nice.com]=20 Sent: Sunday, July 03, 2011 4:13 PM To: Charles Eckel (eckelcu); Elwell, John; Parthasarathi R (partr); siprec@ietf.org Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML I do prefer that metadata XML will be as self-contained as possible and not rely on conveying some data via RS SDP. RS SDP should only be used to recording establishment and negotiation and not as a mechanism for metadata reporting. In case Metadata XML has to be self-contained, the complete SDP has to be converted into XML format or else XML has to have sort of XML attribute which carries SDP. Creating mapping for each SDP attribute with metadata XML element does not seems to be feasible Otherwise we will not be able to reuse same format for reporting metadata via web services=20 As per IETF-80 and last interim meeting, there is no intent of reusing this metadata XML in other protocol. In case reusing same format for webservice or XMPP is the intent, the current metadata XML mechanism is not the appropriate. This was discussed in http://www.ietf.org/mail-archive/web/siprec/current/msg02151.html, http://www.ietf.org/mail-archive/web/siprec/current/msg02155.html(1st point in format slide). In case you have difference of opinion even after this multiple discussion, let us again discuss at IETF-81. =20 or as dedicated SIP session. In case Metadata is separate session from RS, RS attribute like RS-id MUST be included within XML. This was discussed at http://www.ietf.org/mail-archive/web/siprec/current/msg02013.html. Could you please explain reason for the dedicated SIP session for metadata. As for examples, the basic information as media type, labels, volume etc. Any application level data can be relevant. Even indication of encryption (for a case where RS is not encrypted) Leon -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Charles Eckel (eckelcu) Sent: Wednesday, June 29, 2011 7:17 PM To: Elwell, John; Parthasarathi R (partr); siprec@ietf.org Subject: Re: [siprec] Content (RFC 4796) attribute in SDP or XML I think it is sufficient, especially since we can assign new values if necessary. Are there any examples of what people think they might want to capture in the SDP and/or metadata field? Cheers, Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > Sent: Tuesday, June 28, 2011 3:11 AM > To: Parthasarathi R (partr); siprec@ietf.org > Subject: Re: [siprec] Content (RFC 4796) attribute in SDP or XML >=20 > I would like other opinions on whether the SDP a=3Dcontent attribute = in the RS SDP has the correct > semantics for representing the content type of the recorded CS media stream. >=20 > John >=20 > > -----Original Message----- > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > Sent: 28 June 2011 10:45 > > To: Elwell, John; siprec@ietf.org > > Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > Subject: RE: Content (RFC 4796) attribute in SDP or XML > > > > John, > > > > In case if it is the argument of whether CS MS content type or RS MS > > content type in the metadata, it is better for us to re-open ticket > > #71 > > (http://www.ietf.org/mail-archive/web/siprec/current/msg02106.html). > > Please let me know your opinion here. > > > > The basic idea in metadata format is to re-use as much as SDP=20 > > attribute (like direction, content) in media level for RS dialog=20 > > (using SDP label attribute as a pointer) until otherwise there is a=20 > > restriction in using in such manner. As per RFC 4796, there is no=20 > > such restriction and so, I prefer to reuse as content SDP attribute=20 > > rather than introducing the new element for this=20 > > purpose. > > > > Thanks > > Partha > > > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Monday, June 27, 2011 1:18 PM > > To: Parthasarathi R (partr); siprec@ietf.org > > Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > Subject: RE: Content (RFC 4796) attribute in SDP or XML > > > > > > > > > -----Original Message----- > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > Sent: 27 June 2011 08:08 > > > To: siprec@ietf.org; Elwell, John > > > Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > > Subject: Content (RFC 4796) attribute in SDP or XML > > > > > > Hi all, > > > > > > As per the last interim SIPREC meeting, there is a consensus to=20 > > > describe the content of an MS using RFC 4796 & its > > extension. As per > > > RFC 4796, the multiple instance of content attribute is possible to > > > exist in SDP which shall be used in RS SDP. SRS shall group > > the same > > > media content types by "content" attribute in RS SDP. We are=20 > > > interested in knowing any specfic reason for this attribute to be=20 > > > duplicated in Metadata XML. > > [JRE] I don't have a reason for **duplication**. However, I think=20 > > there is a valid question to be asked whether the content type of an > > MS should be represented: > > A) in XML; or > > B) in RS SDP as a=3Dcontent. > > > > The content type we are talking about is an MS content type, i.e.,=20 > > relating to the CS. One could argue that the corresponding RS stream > > is NOT the same content type. For example: > > - CS MS content type is "slides". > > - RS media stream content type is "recording of slides". > > > > On this basis, I think the correct option for conveying the MS content > > type "slides" is A) (in the XML). > > > > Note that this would not involve duplication. The SDP a=3Dcontent=20 > > attribute is optional, so we need not use it for the RS. > > > > Perhaps my distinction is too theoretical, but I do feel a little more > > comfortable using the XML rather than the RS SDP. > > > > John (as individual) > > > > > > > > > > Thanks > > > > > > Partha > > > > > > last Interim SIPREC meeting Note: > > > > > > Slide 7: On the question of how to describe the content of an MS,=20 > > > there was no objection to basing this on the types in the RFC 4796 > > > registry (new values could be specified via the appropriate > > means if > > > needed). Paul had a slight concern that you might be mixing > > multiple > > > CS MSs into a single RS media stream and whether this might > > result in > > > cases not describable in this way, but in the end accepted the=20 > > > consensus. It needs to be discussed on the list whether this is=20 > > > conveyed in XML or in the RS SDP a=3Dcontent attribute. > > > > > > > > > _______________________________________________ > siprec mailing 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 Sun Jul 3 14:57: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 C112011E8080 for ; Sun, 3 Jul 2011 14:57:03 -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 j8gOv08pDPZs for ; Sun, 3 Jul 2011 14:57:03 -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 024DA21F8582 for ; Sun, 3 Jul 2011 14:57:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=3650; q=dns/txt; s=iport; t=1309730222; x=1310939822; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=PJDNplkD4gPiXYqHPG9JnSBe1BZj2/ruQnCoidnCdPo=; b=dYHnB8uUam5PAYNsbOrkEYRrck3pKaok3hsS9gM6Fnlq+mz6jcVjseRp wBgkomrmuQq9VUaBrNoXFsyEDlLf+hATDnaGTEqZlA1nNRCowYEQIBhKh QyfXguNGYzkbcfvJ26Irzb7IJmo+vRdqrxuQ4cqJ+74RcLkuTNpcG8gG3 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEBAKPkEE6rRDoI/2dsb2JhbABSmEiPNHeIeqQvnH2GNgSSNoR4i1o X-IronPort-AV: E=Sophos;i="4.65,468,1304294400"; d="scan'208";a="289123073" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-4.cisco.com with ESMTP; 03 Jul 2011 21:57:02 +0000 Received: from [10.86.248.162] (bxb-vpn3-162.cisco.com [10.86.248.162]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p63Lv1Ts010026; Sun, 3 Jul 2011 21:57:02 GMT Message-ID: <4E10E5AD.6000801@cisco.com> Date: Sun, 03 Jul 2011 17:57:01 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Leon Portman References: <4E04A13F.8090506@cisco.com> <07465C1D981ABC41A344374066AE1A2C38AF6D40D7@TLVMBX01.nice.com> In-Reply-To: <07465C1D981ABC41A344374066AE1A2C38AF6D40D7@TLVMBX01.nice.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "siprec@ietf.org" Subject: Re: [siprec] Format options for unique IDs X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 21:57:03 -0000 On 7/3/2011 6:50 AM, Leon Portman wrote: > I am ok with all options. Actually the question is if from SRS point of view, should it even care? It will be just string with identifier. Should it have any assumptions about it expect uniqueness? Well, that is part of the discussion. Not caring implies that it is happy using arbitrarily long strings as IDs, which has an impact on DB schema design. I'm not a DB guy, so I'm perfectly fine with variable length strings. Thanks, Paul > Leon > > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Friday, June 24, 2011 5:38 PM > To: siprec@ietf.org > Subject: [siprec] Format options for unique IDs > > > > On 6/24/2011 5:58 AM, Elwell, John wrote: > >> - Options for globally unique IDs, along with pros and cons (Partha to >> initiate) > > I'm not Partha, but I'll comment. Some possibilities: > > A) A generic URN, with added constraint that equality is > based only on lexical equivalence (as defined in rfc 2141) > > B) UUID URN (rfc 4122) > > C) UUID encoded more densely than the UUID URN > (e.g. radix64 of the binary uuid form defined in 4122) > > Pros/cons of these: > > A) Pro: very flexible for the SRC. It has many options for > how to create and encode IDs. > > Pro: ease of generation, assuming the SRC chooses wisely. > > Con: Difficult for the SRS. It must deal with variable > unbounded length ID. Doesn't easily fit in databases. > > Con: Somewhat inefficient wire encoding: > there is minimum length of "URN:" plus NID (namespace identifier). > > Pro/Con: Wire efficiency varies depending on SRC choices. > Could be very good or very bad, depending on what NID is chosen. > > B) Pro: very flexible for the SRC. 4122 provides multiple ways of > generating the UUID. One of them (the name based one) would > allow generating a UUID from the same strings you might use > for (A), so its at least as flexible as (A). > > Pro: easy of generation. Like (A), but then requires an SHA-1 > computation. So not as easy as (A). > > Pro: Simple for SRS. The UUID can be easily extracted from > the URN and converted to a fixed length (16 bytes) binary value. > That value then can be stored in databases, compared, etc. > > Con: Somewhat inefficient wire encoding. The urn encoding is > 45 bytes. > > Pro: Flexible to future extension to other sorts of URNs > (e.g. (A)) due to the use of the URN syntax. > > C) Pro: very flexible for the SRC. (Identical to (B)) > > Pro: easy of generation. Virtually the same as (B). > (The final textual formatting is different from (B), but > similar (insignificant) computationally.) > > Pro: Simple for SRS. Virtually the same as (B). > (The final textual formatting is different from (B), but > similar (insignificant) computationally.) > > Pro: Efficient wire encoding. > (Radix 64 takes 22 bytes to represent the 16 binary bytes.) > > For the metadata these would probably all be wrapped in XML in comparable ways, so none has an advantage over another in that respect. > > Please feel free to propose other alternatives. > > As a specific example, for the UUIDs, one could use the 4122 "name based" approach, where the "name" is just a binary integer counter. > > Thanks, > Paul > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From Leon.Portman@nice.com Sun Jul 3 23:40: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 A7F9521F85DF for ; Sun, 3 Jul 2011 23:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.074 X-Spam-Level: X-Spam-Status: No, score=-2.074 tagged_above=-999 required=5 tests=[AWL=-0.075, 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 77isOTbpiMkV for ; Sun, 3 Jul 2011 23:40:53 -0700 (PDT) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id 464DE21F8595 for ; Sun, 3 Jul 2011 23:40:52 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Mon, 4 Jul 2011 09:40:50 +0300 From: Leon Portman To: "Parthasarathi R (partr)" , "Charles Eckel (eckelcu)" , "Elwell, John" , "siprec@ietf.org" Date: Mon, 4 Jul 2011 09:40:50 +0300 Thread-Topic: [siprec] Content (RFC 4796) attribute in SDP or XML Thread-Index: Acw0mPHhxfeVJEDcQLSYWo3IAZGl7wABDbXgACpfOfAADTnVAAA/CH7wAL12yxAADByJIAAdm3Fg Message-ID: <07465C1D981ABC41A344374066AE1A2C38AF6D4376@TLVMBX01.nice.com> References: <07465C1D981ABC41A344374066AE1A2C38AF6D40CC@TLVMBX01.nice.com> In-Reply-To: Accept-Language: en-US, he-IL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, he-IL Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Content (RFC 4796) attribute in SDP or XML X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 06:40:54 -0000 Partha Hi Please see below. Leon -----Original Message----- From: Parthasarathi R (partr) [mailto:partr@cisco.com]=20 Sent: Sunday, July 03, 2011 7:50 PM To: Leon Portman; Charles Eckel (eckelcu); Elwell, John; siprec@ietf.org Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML Leon, Please read inline. Thanks Partha=20 -----Original Message----- From: Leon Portman [mailto:Leon.Portman@nice.com] Sent: Sunday, July 03, 2011 4:13 PM To: Charles Eckel (eckelcu); Elwell, John; Parthasarathi R (partr); siprec@= ietf.org Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML I do prefer that metadata XML will be as self-contained as possible and not= rely on conveying some data via RS SDP. RS SDP should only be used to reco= rding establishment and negotiation and not as a mechanism for metadata rep= orting. In case Metadata XML has to be self-contained, the complete SDP ha= s to be converted into XML format or else XML has to have sort of= XML attribute which carries SDP. Creating mapping for each SDP attribute w= ith metadata XML element does not seems to be feasible [LeonP] But if CS SDP is different from RS SDP, anyway you will need to enc= apsulate the original RS SDP, so why not in XML? Otherwise we will not be able to reuse same format for reporting metadata v= ia web services As per IETF-80 and last interim meeting, there is = no intent of reusing this metadata XML in other protocol. In case reusing s= ame format for webservice or XMPP is the intent, the current metadata XML m= echanism is not the appropriate. This was discussed in http://www.ietf.org/= mail-archive/web/siprec/current/msg02151.html, http://www.ietf.org/mail-archive/web/siprec/current/msg02155.html(1st point in format slide). In case you have difference of opinion even after t= his multiple discussion, let us again discuss at IETF-81. =20 [LeonP] I was not proposing replacing SIP with another transport layer, jus= t wanted to keep other options open. I am very big supporter for metadata o= ver SIP reporting or as dedicated SIP session. In case Metadata is separate session from RS, RS attribute like RS= -id MUST be included within XML. This was discussed at http://www.ietf.org/= mail-archive/web/siprec/current/msg02013.html. Could you please explain rea= son for the dedicated SIP session for metadata. [LeonP] The main use case is Recording on Demand, that is triggered by SRS.= In such case it will be very useful to have just one SIP session and send = all metadata over it (like CTI link) and then only trigger recording (via e= xternal SRC interface) only for specific call segments. As for examples, the basic information as media type, labels, volume etc. A= ny application level data can be relevant. Even indication of encryption (f= or a case where RS is not encrypted) Leon -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Charles Eckel (eckelcu) Sent: Wednesday, June 29, 2011 7:17 PM To: Elwell, John; Parthasarathi R (partr); siprec@ietf.org Subject: Re: [siprec] Content (RFC 4796) attribute in SDP or XML I think it is sufficient, especially since we can assign new values if nece= ssary. Are there any examples of what people think they might want to capture in t= he SDP and/or metadata field? Cheers, Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > Sent: Tuesday, June 28, 2011 3:11 AM > To: Parthasarathi R (partr); siprec@ietf.org > Subject: Re: [siprec] Content (RFC 4796) attribute in SDP or XML >=20 > I would like other opinions on whether the SDP a=3Dcontent attribute in the RS SDP has the correct > semantics for representing the content type of the recorded CS media stream. >=20 > John >=20 > > -----Original Message----- > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > Sent: 28 June 2011 10:45 > > To: Elwell, John; siprec@ietf.org > > Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > Subject: RE: Content (RFC 4796) attribute in SDP or XML > > > > John, > > > > In case if it is the argument of whether CS MS content type or RS MS > > content type in the metadata, it is better for us to re-open ticket > > #71 > > (http://www.ietf.org/mail-archive/web/siprec/current/msg02106.html). > > Please let me know your opinion here. > > > > The basic idea in metadata format is to re-use as much as SDP=20 > > attribute (like direction, content) in media level for RS dialog=20 > > (using SDP label attribute as a pointer) until otherwise there is a=20 > > restriction in using in such manner. As per RFC 4796, there is no=20 > > such restriction and so, I prefer to reuse as content SDP attribute=20 > > rather than introducing the new element for this=20 > > purpose. > > > > Thanks > > Partha > > > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Monday, June 27, 2011 1:18 PM > > To: Parthasarathi R (partr); siprec@ietf.org > > Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > Subject: RE: Content (RFC 4796) attribute in SDP or XML > > > > > > > > > -----Original Message----- > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > Sent: 27 June 2011 08:08 > > > To: siprec@ietf.org; Elwell, John > > > Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > > Subject: Content (RFC 4796) attribute in SDP or XML > > > > > > Hi all, > > > > > > As per the last interim SIPREC meeting, there is a consensus to=20 > > > describe the content of an MS using RFC 4796 & its > > extension. As per > > > RFC 4796, the multiple instance of content attribute is possible to > > > exist in SDP which shall be used in RS SDP. SRS shall group > > the same > > > media content types by "content" attribute in RS SDP. We are=20 > > > interested in knowing any specfic reason for this attribute to be=20 > > > duplicated in Metadata XML. > > [JRE] I don't have a reason for **duplication**. However, I think=20 > > there is a valid question to be asked whether the content type of an > > MS should be represented: > > A) in XML; or > > B) in RS SDP as a=3Dcontent. > > > > The content type we are talking about is an MS content type, i.e.,=20 > > relating to the CS. One could argue that the corresponding RS stream > > is NOT the same content type. For example: > > - CS MS content type is "slides". > > - RS media stream content type is "recording of slides". > > > > On this basis, I think the correct option for conveying the MS content > > type "slides" is A) (in the XML). > > > > Note that this would not involve duplication. The SDP a=3Dcontent=20 > > attribute is optional, so we need not use it for the RS. > > > > Perhaps my distinction is too theoretical, but I do feel a little more > > comfortable using the XML rather than the RS SDP. > > > > John (as individual) > > > > > > > > > > Thanks > > > > > > Partha > > > > > > last Interim SIPREC meeting Note: > > > > > > Slide 7: On the question of how to describe the content of an MS,=20 > > > there was no objection to basing this on the types in the RFC 4796 > > > registry (new values could be specified via the appropriate > > means if > > > needed). Paul had a slight concern that you might be mixing > > multiple > > > CS MSs into a single RS media stream and whether this might > > result in > > > cases not describable in this way, but in the end accepted the=20 > > > consensus. It needs to be discussed on the list whether this is=20 > > > conveyed in XML or in the RS SDP a=3Dcontent attribute. > > > > > > > > > _______________________________________________ > siprec mailing 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 Sun Jul 3 23:42: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 EDA2E21F862C for ; Sun, 3 Jul 2011 23:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.359 X-Spam-Level: X-Spam-Status: No, score=-2.359 tagged_above=-999 required=5 tests=[AWL=0.240, 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 0CaSQHbAFMar for ; Sun, 3 Jul 2011 23:42:25 -0700 (PDT) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id DB4D321F862A for ; Sun, 3 Jul 2011 23:42:24 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Mon, 4 Jul 2011 09:42:23 +0300 From: Leon Portman To: Paul Kyzivat Date: Mon, 4 Jul 2011 09:42:23 +0300 Thread-Topic: [siprec] Format options for unique IDs Thread-Index: Acw5zCmN0cDf6EfWRZiKNIpiIiu2agASSkEQ Message-ID: <07465C1D981ABC41A344374066AE1A2C38AF6D437B@TLVMBX01.nice.com> References: <4E04A13F.8090506@cisco.com> <07465C1D981ABC41A344374066AE1A2C38AF6D40D7@TLVMBX01.nice.com> <4E10E5AD.6000801@cisco.com> In-Reply-To: <4E10E5AD.6000801@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] Format options for unique IDs X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 06:42:26 -0000 Paul, Hi I understand the concern. BTW from DB point of view, anyway SRS usually wil= l create its own key as a primary key (for multiple reasons, specially for = data base portioning and multi-tenancy support). And SRC generated ID is on= ly used for external references. Leon -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: Monday, July 04, 2011 12:57 AM To: Leon Portman Cc: siprec@ietf.org Subject: Re: [siprec] Format options for unique IDs On 7/3/2011 6:50 AM, Leon Portman wrote: > I am ok with all options. Actually the question is if from SRS point of v= iew, should it even care? It will be just string with identifier. Should it= have any assumptions about it expect uniqueness? Well, that is part of the discussion. Not caring implies that it is happy using arbitrarily long strings as IDs, = which has an impact on DB schema design. I'm not a DB guy, so I'm perfectly fine with variable length strings. Thanks, Paul > Leon > > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > Behalf Of Paul Kyzivat > Sent: Friday, June 24, 2011 5:38 PM > To: siprec@ietf.org > Subject: [siprec] Format options for unique IDs > > > > On 6/24/2011 5:58 AM, Elwell, John wrote: > >> - Options for globally unique IDs, along with pros and cons (Partha=20 >> to >> initiate) > > I'm not Partha, but I'll comment. Some possibilities: > > A) A generic URN, with added constraint that equality is > based only on lexical equivalence (as defined in rfc 2141) > > B) UUID URN (rfc 4122) > > C) UUID encoded more densely than the UUID URN > (e.g. radix64 of the binary uuid form defined in 4122) > > Pros/cons of these: > > A) Pro: very flexible for the SRC. It has many options for > how to create and encode IDs. > > Pro: ease of generation, assuming the SRC chooses wisely. > > Con: Difficult for the SRS. It must deal with variable > unbounded length ID. Doesn't easily fit in databases. > > Con: Somewhat inefficient wire encoding: > there is minimum length of "URN:" plus NID (namespace identifier). > > Pro/Con: Wire efficiency varies depending on SRC choices. > Could be very good or very bad, depending on what NID is chosen. > > B) Pro: very flexible for the SRC. 4122 provides multiple ways of > generating the UUID. One of them (the name based one) would > allow generating a UUID from the same strings you might use > for (A), so its at least as flexible as (A). > > Pro: easy of generation. Like (A), but then requires an SHA-1 > computation. So not as easy as (A). > > Pro: Simple for SRS. The UUID can be easily extracted from > the URN and converted to a fixed length (16 bytes) binary value. > That value then can be stored in databases, compared, etc. > > Con: Somewhat inefficient wire encoding. The urn encoding is > 45 bytes. > > Pro: Flexible to future extension to other sorts of URNs > (e.g. (A)) due to the use of the URN syntax. > > C) Pro: very flexible for the SRC. (Identical to (B)) > > Pro: easy of generation. Virtually the same as (B). > (The final textual formatting is different from (B), but > similar (insignificant) computationally.) > > Pro: Simple for SRS. Virtually the same as (B). > (The final textual formatting is different from (B), but > similar (insignificant) computationally.) > > Pro: Efficient wire encoding. > (Radix 64 takes 22 bytes to represent the 16 binary bytes.) > > For the metadata these would probably all be wrapped in XML in comparable= ways, so none has an advantage over another in that respect. > > Please feel free to propose other alternatives. > > As a specific example, for the UUIDs, one could use the 4122 "name based"= approach, where the "name" is just a binary integer counter. > > Thanks, > Paul > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From partr@cisco.com Mon Jul 4 00:08: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 C692021F864E for ; Mon, 4 Jul 2011 00:08:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.697 X-Spam-Level: X-Spam-Status: No, score=-9.697 tagged_above=-999 required=5 tests=[AWL=0.302, 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 2jKdG9jCdQxq for ; Mon, 4 Jul 2011 00:08: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 D5CC621F8658 for ; Mon, 4 Jul 2011 00:08:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=10079; q=dns/txt; s=iport; t=1309763295; x=1310972895; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=KFnFU0AtvPvoOd9qS+RYLoI18MDLtJ1uMxeHhP1VhyY=; b=Kcyi6aWgcIIvgkkHolsMMOOa2leleOQXkhGW9XZXP0Oc/BHb0baqPFb0 tmw6DyAtjj8G8hQRwBA21cuVhfmhT08WrjoZ9BEZAyh7LWO6sNx5gxBEH N+wySJpCOuCUYTHR4IpS/jV8yDsc3D0/XNzX+6RLnMp6ga2yCFXEVTahG s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIBAEVmEU5Io8UR/2dsb2JhbABSmEiPNHeIeqR8nRmGNgSHPY96iz0 X-IronPort-AV: E=Sophos;i="4.65,471,1304294400"; d="scan'208";a="99470114" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-1.cisco.com with ESMTP; 04 Jul 2011 07:08:12 +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 p6476wsW027747; Mon, 4 Jul 2011 07:08:12 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, 4 Jul 2011 12:37: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, 4 Jul 2011 12:37:45 +0530 Message-ID: In-Reply-To: <07465C1D981ABC41A344374066AE1A2C38AF6D4376@TLVMBX01.nice.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Content (RFC 4796) attribute in SDP or XML Thread-Index: Acw0mPHhxfeVJEDcQLSYWo3IAZGl7wABDbXgACpfOfAADTnVAAA/CH7wAL12yxAADByJIAAdm3FgAADcErA= References: <07465C1D981ABC41A344374066AE1A2C38AF6D40CC@TLVMBX01.nice.com> <07465C1D981ABC41A344374066AE1A2C38AF6D4376@TLVMBX01.nice.com> From: "Parthasarathi R (partr)" To: "Leon Portman" , "Charles Eckel (eckelcu)" , "Elwell, John" , X-OriginalArrivalTime: 04 Jul 2011 07:07:46.0892 (UTC) FILETIME=[13DFA8C0:01CC3A19] Subject: Re: [siprec] Content (RFC 4796) attribute in SDP or XML X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 07:08:16 -0000 Leon, Please read inline. Thanks Partha > -----Original Message----- > From: Leon Portman [mailto:Leon.Portman@nice.com]=20 > Sent: Monday, July 04, 2011 12:11 PM > To: Parthasarathi R (partr); Charles Eckel (eckelcu); Elwell,=20 > John; siprec@ietf.org > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML >=20 > Partha Hi >=20 > Please see below. >=20 > Leon >=20 > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > Sent: Sunday, July 03, 2011 7:50 PM > To: Leon Portman; Charles Eckel (eckelcu); Elwell, John;=20 > siprec@ietf.org > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML >=20 > Leon, >=20 > Please read inline. >=20 > Thanks > Partha=20 >=20 > -----Original Message----- > From: Leon Portman [mailto:Leon.Portman@nice.com] > Sent: Sunday, July 03, 2011 4:13 PM > To: Charles Eckel (eckelcu); Elwell, John; Parthasarathi R=20 > (partr); siprec@ietf.org > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML >=20 > I do prefer that metadata XML will be as self-contained as=20 > possible and not rely on conveying some data via RS SDP. RS=20 > SDP should only be used to recording establishment and=20 > negotiation and not as a mechanism for metadata reporting. >=20 > In case Metadata XML has to be self-contained, the=20 > complete SDP has to be converted into XML format or else XML=20 > has to have sort of XML attribute which carries=20 > SDP. Creating mapping for each SDP attribute with metadata=20 > XML element does not seems to be feasible >=20 > [LeonP] But if CS SDP is different from RS SDP, anyway you=20 > will need to encapsulate the original RS SDP, so why not in XML? I guess that the confusion is here. In the current format, RS SDP is only carried towards SRS and CS SDP is not forwarded. This design is closed as part of ticket #71 (http://www.ietf.org/mail-archive/web/siprec/current/msg02106.html). Please bring up with the usecase for CS SDP if required >=20 > Otherwise we will not be able to reuse same format for=20 > reporting metadata via web services As per IETF-80=20 > and last interim meeting, there is no intent of reusing this=20 > metadata XML in other protocol. In case reusing same format=20 > for webservice or XMPP is the intent, the current metadata=20 > XML mechanism is not the appropriate. This was discussed in=20 > http://www.ietf.org/mail-archive/web/siprec/current/msg02151.html, > http://www.ietf.org/mail-archive/web/siprec/current/msg02155.html(1st > point in format slide). In case you have difference of=20 > opinion even after this multiple discussion, let us again=20 > discuss at IETF-81. > =20 >=20 > [LeonP] I was not proposing replacing SIP with another=20 > transport layer, just wanted to keep other options open. Current metadata format is customized for SIP transport. In case we need to keep the options open, the format has to be revisited from the scratch. In our analysis, we notice that REST architecture with Metadata XML is best fit for HTTP, XMPP I am=20 > very big supporter for metadata over SIP reporting >=20 Thanks, Me too.. > or as dedicated SIP session. > In case Metadata is separate session from RS, RS=20 > attribute like RS-id MUST be included within XML. This was=20 > discussed at=20 > http://www.ietf.org/mail-archive/web/siprec/current/msg02013.h tml. Could you please explain reason for the dedicated SIP > session for metadata. > >=20 > [LeonP] The main use case is Recording on Demand, that is=20 > triggered by SRS. In such case it will be very useful to have=20 > just one SIP session and send all metadata over it (like CTI=20 > link) and then only trigger recording (via external SRC=20 > interface) only for specific call segments. >=20 I understand the current implementation wherein few of the metadata like CDR records is passed through non-sip interface. It is outside the scope of SIPREC. The global-id in format shall be used to correlate. Please let me know in case any current SIPREC metadata attribute MUST be passed through this CTS link. > As for examples, the basic information as media type, labels,=20 > volume etc. Any application level data can be relevant. Even=20 > indication of encryption (for a case where RS is not encrypted) >=20 > Leon >=20 > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Charles Eckel (eckelcu) > Sent: Wednesday, June 29, 2011 7:17 PM > To: Elwell, John; Parthasarathi R (partr); siprec@ietf.org > Subject: Re: [siprec] Content (RFC 4796) attribute in SDP or XML >=20 > I think it is sufficient, especially since we can assign new=20 > values if necessary. > Are there any examples of what people think they might want=20 > to capture in the SDP and/or metadata field? >=20 > Cheers, > Charles >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Elwell, John > > Sent: Tuesday, June 28, 2011 3:11 AM > > To: Parthasarathi R (partr); siprec@ietf.org > > Subject: Re: [siprec] Content (RFC 4796) attribute in SDP or XML > >=20 > > I would like other opinions on whether the SDP a=3Dcontent=20 > attribute in > the RS SDP has the correct > > semantics for representing the content type of the recorded CS media > stream. > >=20 > > John > >=20 > > > -----Original Message----- > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > Sent: 28 June 2011 10:45 > > > To: Elwell, John; siprec@ietf.org > > > Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > > Subject: RE: Content (RFC 4796) attribute in SDP or XML > > > > > > John, > > > > > > In case if it is the argument of whether CS MS content=20 > type or RS MS >=20 > > > content type in the metadata, it is better for us to=20 > re-open ticket > > > #71 > > >=20 > (http://www.ietf.org/mail-archive/web/siprec/current/msg02106.html). > > > Please let me know your opinion here. > > > > > > The basic idea in metadata format is to re-use as much as SDP=20 > > > attribute (like direction, content) in media level for RS dialog=20 > > > (using SDP label attribute as a pointer) until otherwise=20 > there is a=20 > > > restriction in using in such manner. As per RFC 4796, there is no=20 > > > such restriction and so, I prefer to reuse as content SDP=20 > attribute=20 > > > rather than introducing the new element for this=20 > > > purpose. > > > > > > Thanks > > > Partha > > > > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > Sent: Monday, June 27, 2011 1:18 PM > > > To: Parthasarathi R (partr); siprec@ietf.org > > > Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > > Subject: RE: Content (RFC 4796) attribute in SDP or XML > > > > > > > > > > > > > -----Original Message----- > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > Sent: 27 June 2011 08:08 > > > > To: siprec@ietf.org; Elwell, John > > > > Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > > > Subject: Content (RFC 4796) attribute in SDP or XML > > > > > > > > Hi all, > > > > > > > > As per the last interim SIPREC meeting, there is a consensus to=20 > > > > describe the content of an MS using RFC 4796 & its > > > extension. As per > > > > RFC 4796, the multiple instance of content attribute is possible > to > > > > exist in SDP which shall be used in RS SDP. SRS shall group > > > the same > > > > media content types by "content" attribute in RS SDP. We are=20 > > > > interested in knowing any specfic reason for this=20 > attribute to be=20 > > > > duplicated in Metadata XML. > > > [JRE] I don't have a reason for **duplication**. However, I think=20 > > > there is a valid question to be asked whether the content=20 > type of an >=20 > > > MS should be represented: > > > A) in XML; or > > > B) in RS SDP as a=3Dcontent. > > > > > > The content type we are talking about is an MS content=20 > type, i.e.,=20 > > > relating to the CS. One could argue that the=20 > corresponding RS stream >=20 > > > is NOT the same content type. For example: > > > - CS MS content type is "slides". > > > - RS media stream content type is "recording of slides". > > > > > > On this basis, I think the correct option for conveying the MS > content > > > type "slides" is A) (in the XML). > > > > > > Note that this would not involve duplication. The SDP a=3Dcontent=20 > > > attribute is optional, so we need not use it for the RS. > > > > > > Perhaps my distinction is too theoretical, but I do feel a little > more > > > comfortable using the XML rather than the RS SDP. > > > > > > John (as individual) > > > > > > > > > > > > > > Thanks > > > > > > > > Partha > > > > > > > > last Interim SIPREC meeting Note: > > > > > > > > Slide 7: On the question of how to describe the content=20 > of an MS,=20 > > > > there was no objection to basing this on the types in=20 > the RFC 4796 >=20 > > > > registry (new values could be specified via the appropriate > > > means if > > > > needed). Paul had a slight concern that you might be mixing > > > multiple > > > > CS MSs into a single RS media stream and whether this might > > > result in > > > > cases not describable in this way, but in the end accepted the=20 > > > > consensus. It needs to be discussed on the list whether this is=20 > > > > conveyed in XML or in the RS SDP a=3Dcontent attribute. > > > > > > > > > > > > > _______________________________________________ > > siprec mailing 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 Henry.Lum@alcatel-lucent.com Mon Jul 4 08:14: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 1FFC121F85C0 for ; Mon, 4 Jul 2011 08:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, 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 g2O110ROr9zR for ; Mon, 4 Jul 2011 08:14:47 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 78BCA21F8595 for ; Mon, 4 Jul 2011 08:14:47 -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 p64FEkVr017797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 4 Jul 2011 10:14:46 -0500 (CDT) Received: from relay-out1.wc.genesyslab.com (relay-out1.wc.genesyslab.com [172.22.70.114]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p64FEjMi022498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 4 Jul 2011 10:14:46 -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 p64FEiGE000916 for ; Mon, 4 Jul 2011 08:14:44 -0700 (PDT) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.93]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 4 Jul 2011 08:14:44 -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_01CC3A5D.1AB49EBA" Date: Mon, 4 Jul 2011 08:14:43 -0700 Message-ID: <059AF07365DC474393A19A3AF187DF740747F9B8@NAHALD.us.int.genesyslab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: record-aware options tag Thread-Index: Acw6XRpvumjRleP6QM2icyxTy5+tFQ== From: "Henry Lum" To: X-OriginalArrivalTime: 04 Jul 2011 15:14:44.0492 (UTC) FILETIME=[1AEB9CC0:01CC3A5D] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: [siprec] record-aware options tag X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 15:14:48 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC3A5D.1AB49EBA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Following up on an issue from the interim meeting about the obligations for recording aware UA. I think it would be sufficient to require that a recording aware UA to indicate two things: 1) that it is recording-aware by adding the record-aware options tag in the Supported header; 2) provide recording indications with the a=3Drecord SDP attribute. Some types of UA such as PSTN gateways may have local policies to provide recording indications through other means such as inband tones/announcements, but they are in addition to the a=3Drecord SDP attribute. =20 Would such text be sufficient? =20 Regards, Henry =20 =09 -------------------------------------------------------------------------= ------------------------------------------ CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain co= nfidential and proprietary information of Alcatel-Lucent and/or its affil= iated entities. Access by the intended recipient only is authorized. Any = liability arising from any party acting, or refraining from acting, on an= y information contained in this e-mail is hereby excluded. If you are not= the intended recipient, please notify the sender immediately, destroy th= e original transmission and its attachments and do not disclose the conte= nts to any other person, use it for any purpose, or store or copy the inf= ormation in any medium. Copyright in this e-mail and any attachments belo= ngs to Alcatel-Lucent and/or its affiliated entities. =09 ------_=_NextPart_001_01CC3A5D.1AB49EBA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Following up on an issue from the interim meeting ab= out the obligations for recording aware UA. I think it would be sufficient to req= uire that a recording aware UA to indicate two things: 1) that it is recording= -aware by adding the record-aware options tag in the Supported header; 2) provid= e recording indications with the a=3Drecord SDP attribute. Some types of UA= such as PSTN gateways may have local policies to provide recording indications th= rough other means such as inband tones/announcements, but they are in addition = to the a=3Drecord SDP attribute.

 

Would such text be sufficient?

 

Regards,

Henry

 

 


CONFIDENTIALITY NOTICE: This e-mai= l and any files attached may contain confidential and proprietary informa= tion of Alcatel-Lucent and/or its affiliated entities. Access by the inte= nded recipient only is authorized. Any liability arising from any party a= cting, or refraining from acting, on any information contained in this e-= mail is hereby excluded. If you are not the intended recipient, please no= tify the sender immediately, destroy the original transmission and its at= tachments and do not disclose the contents to any other person, use it fo= r 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 a= ffiliated entities. ------_=_NextPart_001_01CC3A5D.1AB49EBA-- From Leon.Portman@nice.com Mon Jul 4 09:38: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 8031811E80B1 for ; Mon, 4 Jul 2011 09:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.101, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_16=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 3em6f2Sawa2R for ; Mon, 4 Jul 2011 09:38:05 -0700 (PDT) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id 3F6B511E80AC for ; Mon, 4 Jul 2011 09:38:04 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Mon, 4 Jul 2011 19:38:02 +0300 From: Leon Portman To: Henry Lum , "siprec@ietf.org" Date: Mon, 4 Jul 2011 19:38:01 +0300 Thread-Topic: record-aware options tag Thread-Index: Acw6XRpvumjRleP6QM2icyxTy5+tFQAC10GQ Message-ID: <07465C1D981ABC41A344374066AE1A2C38AF6D4747@TLVMBX01.nice.com> References: <059AF07365DC474393A19A3AF187DF740747F9B8@NAHALD.us.int.genesyslab.com> In-Reply-To: <059AF07365DC474393A19A3AF187DF740747F9B8@NAHALD.us.int.genesyslab.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_07465C1D981ABC41A344374066AE1A2C38AF6D4747TLVMBX01nicec_" MIME-Version: 1.0 Subject: Re: [siprec] record-aware options tag X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 16:38:05 -0000 --_000_07465C1D981ABC41A344374066AE1A2C38AF6D4747TLVMBX01nicec_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Do we also want to add some kind of indication if such recording aware UA i= ntroduces recording tone in the media, in order not to allow multiple media= injections if more than one in the communication path? Leon From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Henry Lum Sent: Monday, July 04, 2011 6:15 PM To: siprec@ietf.org Subject: [siprec] record-aware options tag Following up on an issue from the interim meeting about the obligations for= recording aware UA. I think it would be sufficient to require that a recor= ding aware UA to indicate two things: 1) that it is recording-aware by addi= ng the record-aware options tag in the Supported header; 2) provide recordi= ng indications with the a=3Drecord SDP attribute. Some types of UA such as = PSTN gateways may have local policies to provide recording indications thro= ugh other means such as inband tones/announcements, but they are in additio= n to the a=3Drecord SDP attribute. Would such text be sufficient? Regards, Henry CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain conf= idential and proprietary information of Alcatel-Lucent and/or its affiliate= d entities. Access by the intended recipient only is authorized. Any liabil= ity arising from any party acting, or refraining from acting, on any inform= ation contained in this e-mail is hereby excluded. If you are not the inten= ded recipient, please notify the sender immediately, destroy the original t= ransmission and its attachments and do not disclose the contents to any oth= er person, use it for any purpose, or store or copy the information in any = medium. Copyright in this e-mail and any attachments belongs to Alcatel-Luc= ent and/or its affiliated entities. --_000_07465C1D981ABC41A344374066AE1A2C38AF6D4747TLVMBX01nicec_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Do we also want to add some kind of indication if such record= ing aware UA introduces recording tone in the media, in order not to allow = multiple media injections if more than one in the communication path?<= /o:p>

&nb= sp;

Leon=

 

From: siprec-bou= nces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Henry Lu= m
Sent: Monday, July 04, 2011 6:15 PM
To: siprec@ietf.o= rg
Subject: [siprec] record-aware options tag

 

Following up on an issue from the interim meeting about the obligations f= or recording aware UA. I think it would be sufficient to require that a rec= ording aware UA to indicate two things: 1) that it is recording-aware by ad= ding the record-aware options tag in the Supported header; 2) provide recor= ding indications with the a=3Drecord SDP attribute. Some types of UA such a= s PSTN gateways may have local policies to provide recording indications th= rough other means such as inband tones/announcements, but they are in addit= ion to the a=3Drecord SDP attribute.

 

Would such text be sufficient?<= /o:p>

 

Reg= ards,

Henry

 

 <= /p>

 


CONFIDENTIALITY NOTICE: This e-mail and any files attached may con= tain confidential and proprietary information of Alcatel-Lucent and/or its = affiliated entities. Access by the intended recipient only is authorized. A= ny liability arising from any party acting, or refraining from acting, on a= ny information contained in this e-mail is hereby excluded. If you are not = the intended recipient, please notify the sender immediately, destroy the o= riginal transmission and its attachments and do not disclose the contents t= o any other person, use it for any purpose, or store or copy the informatio= n in any medium. Copyright in this e-mail and any attachments belongs to Al= catel-Lucent and/or its affiliated entities.

= --_000_07465C1D981ABC41A344374066AE1A2C38AF6D4747TLVMBX01nicec_-- From Henry.Lum@alcatel-lucent.com Mon Jul 4 11:40: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 B75C11F0CA0 for ; Mon, 4 Jul 2011 11:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, 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 5nIZPn9N32zn for ; Mon, 4 Jul 2011 11:40:09 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id AD3BD1F0C93 for ; Mon, 4 Jul 2011 11:40:03 -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 p64Ie27P010975 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 4 Jul 2011 13:40:02 -0500 (CDT) Received: from relay-out2.dc (relay-out2.dc.genesyslab.com [172.22.68.188]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p64IdxFb030789 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 4 Jul 2011 13:40:02 -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 p64IdxlZ007721; Mon, 4 Jul 2011 11:39:59 -0700 (PDT) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.93]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 4 Jul 2011 11:39:59 -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_01CC3A79.C6D6EEBA" Date: Mon, 4 Jul 2011 11:39:58 -0700 Message-ID: <059AF07365DC474393A19A3AF187DF740747FA47@NAHALD.us.int.genesyslab.com> In-Reply-To: <07465C1D981ABC41A344374066AE1A2C38AF6D4747@TLVMBX01.nice.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: record-aware options tag Thread-Index: Acw6XRpvumjRleP6QM2icyxTy5+tFQAC10GQAAQxQgA= References: <059AF07365DC474393A19A3AF187DF740747F9B8@NAHALD.us.int.genesyslab.com> <07465C1D981ABC41A344374066AE1A2C38AF6D4747@TLVMBX01.nice.com> From: "Henry Lum" To: "Leon Portman" , X-OriginalArrivalTime: 04 Jul 2011 18:39:59.0257 (UTC) FILETIME=[C717A090:01CC3A79] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: Re: [siprec] record-aware options tag X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 18:40:11 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC3A79.C6D6EEBA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is similar to negotiating or indicating which SRC will be recording and the same question has been raised on the other thread about SDP recording attributes. I think we are in agreement that it is not the goal to indicate/negotiate multiple SRCs in the call path because this can get quite complex... =20 Henry =20 From: Leon Portman [mailto:Leon.Portman@nice.com]=20 Sent: July-04-11 12:38 PM To: Henry Lum; siprec@ietf.org Subject: RE: record-aware options tag =20 Do we also want to add some kind of indication if such recording aware UA introduces recording tone in the media, in order not to allow multiple media injections if more than one in the communication path? =20 Leon =20 From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Henry Lum Sent: Monday, July 04, 2011 6:15 PM To: siprec@ietf.org Subject: [siprec] record-aware options tag =20 Following up on an issue from the interim meeting about the obligations for recording aware UA. I think it would be sufficient to require that a recording aware UA to indicate two things: 1) that it is recording-aware by adding the record-aware options tag in the Supported header; 2) provide recording indications with the a=3Drecord SDP attribute. Some types of UA such as PSTN gateways may have local policies to provide recording indications through other means such as inband tones/announcements, but they are in addition to the a=3Drecord SDP attribute. =20 Would such text be sufficient? =20 Regards, Henry =20 =20 =20 CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities. =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_01CC3A79.C6D6EEBA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is similar to negotiating or indicating which SRC wi= ll be recording and the same question has been raised on the other thread= about SDP recording attributes. I think we are in agreement that it is n= ot the goal to indicate/negotiate multiple SRCs in the call path because = this can get quite complex…

 

Henry

 

<= div style=3D'border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm= 4.0pt'>

From: Leon Portman [mailto:Leon.Portman@nice.com]
Sent: July-04-= 11 12:38 PM
To: Henry Lum; siprec@ietf.org
Subject: R= E: record-aware options tag

 

Do we also want to add some kind of indication if su= ch recording aware UA introduces recording tone in the media, in order no= t to allow multiple media injections if more than one in the communicatio= n path?

 

Leon

 =

From: siprec-bounces@ietf.o= rg [mailto:siprec= -bounces@ietf.org] On Behalf Of Henry Lum
Sent: Mond= ay, July 04, 2011 6:15 PM
To: siprec@ietf.org
Subject: [siprec] record-aware options ta= g

 

Fol= lowing up on an issue from the interim meeting about the obligations for = recording aware UA. I think it would be sufficient to require that a reco= rding aware UA to indicate two things: 1) that it is recording-aware by a= dding the record-aware options tag in the Supported header; 2) provide re= cording indications with the a=3Drecord SDP attribute. Some types of UA s= uch as PSTN gateways may have local policies to provide recording indicat= ions through other means such as inband tones/announcements, but they are= in addition to the a=3Drecord SDP attribute.

 

Would such text be sufficient?

 <= /p>

Regards,

=

Henry

 

 

 


CONFIDENTIALITY NOTICE: This e-mail and any files at= tached may contain confidential and proprietary information of Alcatel-Lu= cent and/or its affiliated entities. Access by the intended recipient onl= y is authorized. Any liability arising from any party acting, or refraini= ng from acting, on any information contained in this e-mail is hereby exc= luded. If you are not the intended recipient, please notify the sender im= mediately, destroy the original transmission and its attachments and do n= ot 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= =2E

 


CONFIDENTIALITY NOTICE: This e-mail and any files attached may c= ontain confidential and proprietary information of Alcatel-Lucent and/or = its affiliated entities. Access by the intended recipient only is authori= zed. Any liability arising from any party acting, or refraining from acti= ng, on any information contained in this e-mail is hereby excluded. If yo= u are not the intended recipient, please notify the sender immediately, d= estroy the original transmission and its attachments and do not disclose = the contents to any other person, use it for any purpose, or store or cop= y the information in any medium. Copyright in this e-mail and any attachm= ents belongs to Alcatel-Lucent and/or its affiliated entities. ------_=_NextPart_001_01CC3A79.C6D6EEBA-- From john.elwell@siemens-enterprise.com Tue Jul 5 07:44: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 518A111E8098 for ; Tue, 5 Jul 2011 07:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.137 X-Spam-Level: X-Spam-Status: No, score=-106.137 tagged_above=-999 required=5 tests=[AWL=-0.138, 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 4LavUklVcp-u for ; Tue, 5 Jul 2011 07:44:10 -0700 (PDT) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfa.amsl.com (Postfix) with SMTP id 80D4021F85F5 for ; Tue, 5 Jul 2011 07:44:09 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1309877037!37386870!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 11193 invoked from network); 5 Jul 2011 14:43:57 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-5.tower-27.messagelabs.com with SMTP; 5 Jul 2011 14:43:57 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id EDED81EB83EE; Tue, 5 Jul 2011 16:44:07 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 5 Jul 2011 16:44:07 +0200 From: "Elwell, John" To: "Parthasarathi R (partr)" , Leon Portman , "Charles Eckel (eckelcu)" , "siprec@ietf.org" Date: Tue, 5 Jul 2011 16:44:07 +0200 Thread-Topic: [siprec] Content (RFC 4796) attribute in SDP or XML Thread-Index: Acw0mPHhxfeVJEDcQLSYWo3IAZGl7wABDbXgACpfOfAADTnVAAA/CH7wAL12yxAADByJIAAdm3FgAADcErAAQaGFkA== Message-ID: References: <07465C1D981ABC41A344374066AE1A2C38AF6D40CC@TLVMBX01.nice.com> <07465C1D981ABC41A344374066AE1A2C38AF6D4376@TLVMBX01.nice.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Content (RFC 4796) attribute in SDP or XML X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 14:44:11 -0000 (as chair) We should try to avoid opening up old issues. I think we had agreed that: - RS SDP describes the RS, and therefore just describes how recordable medi= a is delivered to the SRS. It does not describe how media is delivered betw= een CS endpoints as part of the CS. - Therefore anything to do with the CS (i.e., the session being recorded) n= eeds to be delivered to the SRS as metadata (i.e., in XML). - We don't see a need to standardize delivery of things like CS codecs in t= he metadata, but that could be done using the extension mechanism. Focusing now on the content attribute, I don't think there is any disagreem= ent that the SRS needs to know the content type (e.g., presentation) of a m= edia stream. The SRC can obtain this from the a=3Dcontent attribute of the = CS SDP. The discussion is about whether this content attribute should be co= nveyed to the SRS: A) as an a=3Dcontent attribute of the RS SDP, or B) within the metadata XML. (as individual) According to past decisions, there is perhaps an argument for B). If, for e= xample, we wanted to convey the fact that a CS media stream was subject to = 256-bit encryption, this information would go in the XML (it can't go in th= e RS SDP, because the RS might not use 256-bit encryption. Similarly, one c= ould argue that the content type of a CS media stream should go in the XML,= not in the RS SDP. I could even imagine cases where the content type of a CS media stream does= not equal the content type of an RS media stream, e.g., where the SRC comb= ines the current speaker video and the room video into two videos side-by-s= ide in the same RS media stream. In the metadata these would be two media s= treams, each with its own content type, but both would refer to the same RS= media stream. John > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com]=20 > Sent: 04 July 2011 08:08 > To: Leon Portman; Charles Eckel (eckelcu); Elwell, John;=20 > siprec@ietf.org > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML >=20 > Leon, >=20 > Please read inline. >=20 > Thanks > Partha >=20 > > -----Original Message----- > > From: Leon Portman [mailto:Leon.Portman@nice.com]=20 > > Sent: Monday, July 04, 2011 12:11 PM > > To: Parthasarathi R (partr); Charles Eckel (eckelcu); Elwell,=20 > > John; siprec@ietf.org > > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML > >=20 > > Partha Hi > >=20 > > Please see below. > >=20 > > Leon > >=20 > > -----Original Message----- > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > Sent: Sunday, July 03, 2011 7:50 PM > > To: Leon Portman; Charles Eckel (eckelcu); Elwell, John;=20 > > siprec@ietf.org > > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML > >=20 > > Leon, > >=20 > > Please read inline. > >=20 > > Thanks > > Partha=20 > >=20 > > -----Original Message----- > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > Sent: Sunday, July 03, 2011 4:13 PM > > To: Charles Eckel (eckelcu); Elwell, John; Parthasarathi R=20 > > (partr); siprec@ietf.org > > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML > >=20 > > I do prefer that metadata XML will be as self-contained as=20 > > possible and not rely on conveying some data via RS SDP. RS=20 > > SDP should only be used to recording establishment and=20 > > negotiation and not as a mechanism for metadata reporting. > >=20 > > In case Metadata XML has to be self-contained, the=20 > > complete SDP has to be converted into XML format or else XML=20 > > has to have sort of XML attribute which carries=20 > > SDP. Creating mapping for each SDP attribute with metadata=20 > > XML element does not seems to be feasible > >=20 > > [LeonP] But if CS SDP is different from RS SDP, anyway you=20 > > will need to encapsulate the original RS SDP, so why not in XML? >=20 > I guess that the confusion is here. In the current format, RS > SDP is only carried towards SRS and CS SDP is not forwarded.=20 > This design > is closed as part of ticket #71 > (http://www.ietf.org/mail-archive/web/siprec/current/msg02106.html). > Please bring up with the usecase for CS SDP if required >=20 > >=20 > > Otherwise we will not be able to reuse same format for=20 > > reporting metadata via web services As per IETF-80=20 > > and last interim meeting, there is no intent of reusing this=20 > > metadata XML in other protocol. In case reusing same format=20 > > for webservice or XMPP is the intent, the current metadata=20 > > XML mechanism is not the appropriate. This was discussed in=20 > > http://www.ietf.org/mail-archive/web/siprec/current/msg02151.html, > >=20 > http://www.ietf.org/mail-archive/web/siprec/current/msg02155.html(1st > > point in format slide). In case you have difference of=20 > > opinion even after this multiple discussion, let us again=20 > > discuss at IETF-81. > > =20 > >=20 > > [LeonP] I was not proposing replacing SIP with another=20 > > transport layer, just wanted to keep other options open. >=20 > Current metadata format is customized for SIP transport. In > case we need to keep the options open, the format has to be revisited > from the scratch. In our analysis, we notice that REST=20 > architecture with > Metadata XML is best fit for HTTP, XMPP >=20 > I am=20 > > very big supporter for metadata over SIP reporting > >=20 > Thanks, Me too.. >=20 > > or as dedicated SIP session. > > In case Metadata is separate session from RS, RS=20 > > attribute like RS-id MUST be included within XML. This was=20 > > discussed at=20 > > http://www.ietf.org/mail-archive/web/siprec/current/msg02013.h > tml. Could you please explain reason for the dedicated SIP >=20 > session for > metadata. > > > >=20 > > [LeonP] The main use case is Recording on Demand, that is=20 > > triggered by SRS. In such case it will be very useful to have=20 > > just one SIP session and send all metadata over it (like CTI=20 > > link) and then only trigger recording (via external SRC=20 > > interface) only for specific call segments. > >=20 > I understand the current implementation wherein few of the > metadata like CDR records is passed through non-sip interface. It is > outside the scope of SIPREC. The global-id in format shall be used to > correlate. Please let me know in case any current SIPREC metadata > attribute MUST be passed through this CTS link. >=20 > > As for examples, the basic information as media type, labels,=20 > > volume etc. Any application level data can be relevant. Even=20 > > indication of encryption (for a case where RS is not encrypted) > >=20 > > Leon > >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org=20 > > [mailto:siprec-bounces@ietf.org] On Behalf Of Charles Eckel=20 > (eckelcu) > > Sent: Wednesday, June 29, 2011 7:17 PM > > To: Elwell, John; Parthasarathi R (partr); siprec@ietf.org > > Subject: Re: [siprec] Content (RFC 4796) attribute in SDP or XML > >=20 > > I think it is sufficient, especially since we can assign new=20 > > values if necessary. > > Are there any examples of what people think they might want=20 > > to capture in the SDP and/or metadata field? > >=20 > > Cheers, > > Charles > >=20 > > > -----Original Message----- > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Elwell, John > > > Sent: Tuesday, June 28, 2011 3:11 AM > > > To: Parthasarathi R (partr); siprec@ietf.org > > > Subject: Re: [siprec] Content (RFC 4796) attribute in SDP or XML > > >=20 > > > I would like other opinions on whether the SDP a=3Dcontent=20 > > attribute in > > the RS SDP has the correct > > > semantics for representing the content type of the=20 > recorded CS media > > stream. > > >=20 > > > John > > >=20 > > > > -----Original Message----- > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > Sent: 28 June 2011 10:45 > > > > To: Elwell, John; siprec@ietf.org > > > > Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > > > Subject: RE: Content (RFC 4796) attribute in SDP or XML > > > > > > > > John, > > > > > > > > In case if it is the argument of whether CS MS content=20 > > type or RS MS > >=20 > > > > content type in the metadata, it is better for us to=20 > > re-open ticket > > > > #71 > > > >=20 > > (http://www.ietf.org/mail-archive/web/siprec/current/msg02106.html). > > > > Please let me know your opinion here. > > > > > > > > The basic idea in metadata format is to re-use as much as SDP=20 > > > > attribute (like direction, content) in media level for=20 > RS dialog=20 > > > > (using SDP label attribute as a pointer) until otherwise=20 > > there is a=20 > > > > restriction in using in such manner. As per RFC 4796,=20 > there is no=20 > > > > such restriction and so, I prefer to reuse as content SDP=20 > > attribute=20 > > > > rather than introducing the new element for this=20 > > > > purpose. > > > > > > > > Thanks > > > > Partha > > > > > > > > -----Original Message----- > > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > Sent: Monday, June 27, 2011 1:18 PM > > > > To: Parthasarathi R (partr); siprec@ietf.org > > > > Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > > > Subject: RE: Content (RFC 4796) attribute in SDP or XML > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > > Sent: 27 June 2011 08:08 > > > > > To: siprec@ietf.org; Elwell, John > > > > > Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > > > > Subject: Content (RFC 4796) attribute in SDP or XML > > > > > > > > > > Hi all, > > > > > > > > > > As per the last interim SIPREC meeting, there is a=20 > consensus to=20 > > > > > describe the content of an MS using RFC 4796 & its > > > > extension. As per > > > > > RFC 4796, the multiple instance of content attribute=20 > is possible > > to > > > > > exist in SDP which shall be used in RS SDP. SRS shall group > > > > the same > > > > > media content types by "content" attribute in RS SDP. We are=20 > > > > > interested in knowing any specfic reason for this=20 > > attribute to be=20 > > > > > duplicated in Metadata XML. > > > > [JRE] I don't have a reason for **duplication**.=20 > However, I think=20 > > > > there is a valid question to be asked whether the content=20 > > type of an > >=20 > > > > MS should be represented: > > > > A) in XML; or > > > > B) in RS SDP as a=3Dcontent. > > > > > > > > The content type we are talking about is an MS content=20 > > type, i.e.,=20 > > > > relating to the CS. One could argue that the=20 > > corresponding RS stream > >=20 > > > > is NOT the same content type. For example: > > > > - CS MS content type is "slides". > > > > - RS media stream content type is "recording of slides". > > > > > > > > On this basis, I think the correct option for conveying the MS > > content > > > > type "slides" is A) (in the XML). > > > > > > > > Note that this would not involve duplication. The SDP a=3Dcontent=20 > > > > attribute is optional, so we need not use it for the RS. > > > > > > > > Perhaps my distinction is too theoretical, but I do=20 > feel a little > > more > > > > comfortable using the XML rather than the RS SDP. > > > > > > > > John (as individual) > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > Partha > > > > > > > > > > last Interim SIPREC meeting Note: > > > > > > > > > > Slide 7: On the question of how to describe the content=20 > > of an MS,=20 > > > > > there was no objection to basing this on the types in=20 > > the RFC 4796 > >=20 > > > > > registry (new values could be specified via the appropriate > > > > means if > > > > > needed). Paul had a slight concern that you might be mixing > > > > multiple > > > > > CS MSs into a single RS media stream and whether this might > > > > result in > > > > > cases not describable in this way, but in the end=20 > accepted the=20 > > > > > consensus. It needs to be discussed on the list=20 > whether this is=20 > > > > > conveyed in XML or in the RS SDP a=3Dcontent attribute. > > > > > > > > > > > > > > > > > _______________________________________________ > > > siprec mailing 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 Tue Jul 5 08:02: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 50B0521F85D2 for ; Tue, 5 Jul 2011 08:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.128 X-Spam-Level: X-Spam-Status: No, score=-106.128 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, 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 2VQCUP+ySNgq for ; Tue, 5 Jul 2011 08:02:09 -0700 (PDT) Received: from mail182.messagelabs.com (mail182.messagelabs.com [85.158.139.83]) by ietfa.amsl.com (Postfix) with SMTP id D159A11E81A9 for ; Tue, 5 Jul 2011 08:01:32 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1309878091!10661866!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 7500 invoked from network); 5 Jul 2011 15:01:31 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-5.tower-182.messagelabs.com with SMTP; 5 Jul 2011 15:01:31 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 70CD31EB83ED; Tue, 5 Jul 2011 17:01:31 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 5 Jul 2011 17:01:31 +0200 From: "Elwell, John" To: Henry Lum , "siprec@ietf.org" Date: Tue, 5 Jul 2011 17:01:30 +0200 Thread-Topic: record-aware options tag Thread-Index: Acw6XRpvumjRleP6QM2icyxTy5+tFQAxb5ig Message-ID: References: <059AF07365DC474393A19A3AF187DF740747F9B8@NAHALD.us.int.genesyslab.com> In-Reply-To: <059AF07365DC474393A19A3AF187DF740747F9B8@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] record-aware options tag X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 15:02:10 -0000 My interpretation of what the meeting wanted was text along the following l= ines. "A UA that has indicated recording awareness by including the record-aware = option tag in a transmitted Supported header field MUST provide at its user= interface an indication whether recording is on or off for a given medium = based on the most recently received a=3Drecord SDP attribute for that mediu= m." I am not sure whether this is sufficient or whether we need to say more. Fo= r example, an automaton (such as a media server) would not have a user inte= rface. A UA that is a conference focus might need to pass it on somehow to = other participants. A UA that is a PSTN gateway would need to play a tone o= r announcement. Of course, a UA can avoid such an obligation by not sending= this option tag in Supported, thereby relying on the SRC to do the necessa= ry (e.g., play a tone or announcement in the case of audio). In addition, we would need some normative statement for an SRC. Clearly it = would be obliged to take action if the UA has not indicated recording aware= ness. John (as individual) > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Henry Lum > Sent: 04 July 2011 16:15 > To: siprec@ietf.org > Subject: [siprec] record-aware options tag >=20 > Following up on an issue from the interim meeting about the=20 > obligations for recording aware UA. I think it would be=20 > sufficient to require that a recording aware UA to indicate=20 > two things: 1) that it is recording-aware by adding the=20 > record-aware options tag in the Supported header; 2) provide=20 > recording indications with the a=3Drecord SDP attribute. Some=20 > types of UA such as PSTN gateways may have local policies to=20 > provide recording indications through other means such as=20 > inband tones/announcements, but they are in addition to the=20 > a=3Drecord SDP attribute. >=20 > =20 >=20 > Would such text be sufficient? >=20 > =20 >=20 > Regards, >=20 > Henry >=20 > =20 >=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 Leon.Portman@nice.com Tue Jul 5 08:42: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 09D1B21F8747 for ; Tue, 5 Jul 2011 08:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.085 X-Spam-Level: X-Spam-Status: No, score=-2.085 tagged_above=-999 required=5 tests=[AWL=-0.086, 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 bso-d8hKYTMX for ; Tue, 5 Jul 2011 08:42:32 -0700 (PDT) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id 4580021F8718 for ; Tue, 5 Jul 2011 08:42:29 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.15]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Tue, 5 Jul 2011 18:42:28 +0300 From: Leon Portman To: "Elwell, John" , "Parthasarathi R (partr)" , "Charles Eckel (eckelcu)" , "siprec@ietf.org" Date: Tue, 5 Jul 2011 18:42:26 +0300 Thread-Topic: [siprec] Content (RFC 4796) attribute in SDP or XML Thread-Index: Acw0mPHhxfeVJEDcQLSYWo3IAZGl7wABDbXgACpfOfAADTnVAAA/CH7wAL12yxAADByJIAAdm3FgAADcErAAQaGFkAAC7JoQ Message-ID: <07465C1D981ABC41A344374066AE1A2C38AFE9B1C0@TLVMBX01.nice.com> References: <07465C1D981ABC41A344374066AE1A2C38AF6D40CC@TLVMBX01.nice.com> <07465C1D981ABC41A344374066AE1A2C38AF6D4376@TLVMBX01.nice.com> In-Reply-To: Accept-Language: en-US, he-IL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, he-IL Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Content (RFC 4796) attribute in SDP or XML X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 15:42:33 -0000 I completely agree with the below. Leon -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 Sent: Tuesday, July 05, 2011 5:44 PM To: Parthasarathi R (partr); Leon Portman; Charles Eckel (eckelcu); siprec@= ietf.org Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML (as chair) We should try to avoid opening up old issues. I think we had agreed that: - RS SDP describes the RS, and therefore just describes how recordable medi= a is delivered to the SRS. It does not describe how media is delivered betw= een CS endpoints as part of the CS. - Therefore anything to do with the CS (i.e., the session being recorded) n= eeds to be delivered to the SRS as metadata (i.e., in XML). - We don't see a need to standardize delivery of things like CS codecs in t= he metadata, but that could be done using the extension mechanism. Focusing now on the content attribute, I don't think there is any disagreem= ent that the SRS needs to know the content type (e.g., presentation) of a m= edia stream. The SRC can obtain this from the a=3Dcontent attribute of the = CS SDP. The discussion is about whether this content attribute should be co= nveyed to the SRS: A) as an a=3Dcontent attribute of the RS SDP, or B) within the metadata XML. (as individual) According to past decisions, there is perhaps an argument for B). If, for e= xample, we wanted to convey the fact that a CS media stream was subject to = 256-bit encryption, this information would go in the XML (it can't go in th= e RS SDP, because the RS might not use 256-bit encryption. Similarly, one c= ould argue that the content type of a CS media stream should go in the XML,= not in the RS SDP. I could even imagine cases where the content type of a CS media stream does= not equal the content type of an RS media stream, e.g., where the SRC comb= ines the current speaker video and the room video into two videos side-by-s= ide in the same RS media stream. In the metadata these would be two media s= treams, each with its own content type, but both would refer to the same RS= media stream. John > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > Sent: 04 July 2011 08:08 > To: Leon Portman; Charles Eckel (eckelcu); Elwell, John;=20 > siprec@ietf.org > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML >=20 > Leon, >=20 > Please read inline. >=20 > Thanks > Partha >=20 > > -----Original Message----- > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > Sent: Monday, July 04, 2011 12:11 PM > > To: Parthasarathi R (partr); Charles Eckel (eckelcu); Elwell, John;=20 > > siprec@ietf.org > > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML > >=20 > > Partha Hi > >=20 > > Please see below. > >=20 > > Leon > >=20 > > -----Original Message----- > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > Sent: Sunday, July 03, 2011 7:50 PM > > To: Leon Portman; Charles Eckel (eckelcu); Elwell, John;=20 > > siprec@ietf.org > > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML > >=20 > > Leon, > >=20 > > Please read inline. > >=20 > > Thanks > > Partha > >=20 > > -----Original Message----- > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > Sent: Sunday, July 03, 2011 4:13 PM > > To: Charles Eckel (eckelcu); Elwell, John; Parthasarathi R (partr);=20 > > siprec@ietf.org > > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML > >=20 > > I do prefer that metadata XML will be as self-contained as possible=20 > > and not rely on conveying some data via RS SDP. RS SDP should only=20 > > be used to recording establishment and negotiation and not as a=20 > > mechanism for metadata reporting. > >=20 > > In case Metadata XML has to be self-contained, the complete=20 > > SDP has to be converted into XML format or else XML has to have=20 > > sort of XML attribute which carries SDP. Creating mapping=20 > > for each SDP attribute with metadata XML element does not seems to=20 > > be feasible > >=20 > > [LeonP] But if CS SDP is different from RS SDP, anyway you will need=20 > > to encapsulate the original RS SDP, so why not in XML? >=20 > I guess that the confusion is here. In the current format, RS=20 > SDP is only carried towards SRS and CS SDP is not forwarded. > This design > is closed as part of ticket #71 > (http://www.ietf.org/mail-archive/web/siprec/current/msg02106.html). > Please bring up with the usecase for CS SDP if required >=20 > >=20 > > Otherwise we will not be able to reuse same format for reporting=20 > > metadata via web services As per IETF-80 and last interim=20 > > meeting, there is no intent of reusing this metadata XML in other=20 > > protocol. In case reusing same format for webservice or XMPP is the=20 > > intent, the current metadata XML mechanism is not the appropriate.=20 > > This was discussed in=20 > > http://www.ietf.org/mail-archive/web/siprec/current/msg02151.html, > >=20 > http://www.ietf.org/mail-archive/web/siprec/current/msg02155.html(1st > > point in format slide). In case you have difference of opinion even=20 > > after this multiple discussion, let us again discuss at IETF-81. > > > >=20 > > [LeonP] I was not proposing replacing SIP with another transport=20 > > layer, just wanted to keep other options open. >=20 > Current metadata format is customized for SIP transport. In=20 > case we need to keep the options open, the format has to be revisited=20 > from the scratch. In our analysis, we notice that REST architecture=20 > with Metadata XML is best fit for HTTP, XMPP >=20 > I am > > very big supporter for metadata over SIP reporting > >=20 > Thanks, Me too.. >=20 > > or as dedicated SIP session. > > In case Metadata is separate session from RS, RS attribute=20 > > like RS-id MUST be included within XML. This was discussed at=20 > > http://www.ietf.org/mail-archive/web/siprec/current/msg02013.h > tml. Could you please explain reason for the dedicated SIP > session=20 > for metadata. > > > >=20 > > [LeonP] The main use case is Recording on Demand, that is triggered=20 > > by SRS. In such case it will be very useful to have just one SIP=20 > > session and send all metadata over it (like CTI > > link) and then only trigger recording (via external SRC > > interface) only for specific call segments. > >=20 > I understand the current implementation wherein few of the=20 > metadata like CDR records is passed through non-sip interface. It is=20 > outside the scope of SIPREC. The global-id in format shall be used to=20 > correlate. Please let me know in case any current SIPREC metadata=20 > attribute MUST be passed through this CTS link. >=20 > > As for examples, the basic information as media type, labels, volume=20 > > etc. Any application level data can be relevant. Even indication of=20 > > encryption (for a case where RS is not encrypted) > >=20 > > Leon > >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf Of Charles Eckel > (eckelcu) > > Sent: Wednesday, June 29, 2011 7:17 PM > > To: Elwell, John; Parthasarathi R (partr); siprec@ietf.org > > Subject: Re: [siprec] Content (RFC 4796) attribute in SDP or XML > >=20 > > I think it is sufficient, especially since we can assign new values=20 > > if necessary. > > Are there any examples of what people think they might want to=20 > > capture in the SDP and/or metadata field? > >=20 > > Cheers, > > Charles > >=20 > > > -----Original Message----- > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Elwell, John > > > Sent: Tuesday, June 28, 2011 3:11 AM > > > To: Parthasarathi R (partr); siprec@ietf.org > > > Subject: Re: [siprec] Content (RFC 4796) attribute in SDP or XML > > >=20 > > > I would like other opinions on whether the SDP a=3Dcontent > > attribute in > > the RS SDP has the correct > > > semantics for representing the content type of the > recorded CS media > > stream. > > >=20 > > > John > > >=20 > > > > -----Original Message----- > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > Sent: 28 June 2011 10:45 > > > > To: Elwell, John; siprec@ietf.org > > > > Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > > > Subject: RE: Content (RFC 4796) attribute in SDP or XML > > > > > > > > John, > > > > > > > > In case if it is the argument of whether CS MS content > > type or RS MS > >=20 > > > > content type in the metadata, it is better for us to > > re-open ticket > > > > #71 > > > >=20 > > (http://www.ietf.org/mail-archive/web/siprec/current/msg02106.html). > > > > Please let me know your opinion here. > > > > > > > > The basic idea in metadata format is to re-use as much as SDP=20 > > > > attribute (like direction, content) in media level for > RS dialog > > > > (using SDP label attribute as a pointer) until otherwise > > there is a > > > > restriction in using in such manner. As per RFC 4796, > there is no > > > > such restriction and so, I prefer to reuse as content SDP > > attribute > > > > rather than introducing the new element for this=20 > > > > purpose. > > > > > > > > Thanks > > > > Partha > > > > > > > > -----Original Message----- > > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > Sent: Monday, June 27, 2011 1:18 PM > > > > To: Parthasarathi R (partr); siprec@ietf.org > > > > Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > > > Subject: RE: Content (RFC 4796) attribute in SDP or XML > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > > Sent: 27 June 2011 08:08 > > > > > To: siprec@ietf.org; Elwell, John > > > > > Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > > > > Subject: Content (RFC 4796) attribute in SDP or XML > > > > > > > > > > Hi all, > > > > > > > > > > As per the last interim SIPREC meeting, there is a > consensus to > > > > > describe the content of an MS using RFC 4796 & its > > > > extension. As per > > > > > RFC 4796, the multiple instance of content attribute > is possible > > to > > > > > exist in SDP which shall be used in RS SDP. SRS shall group > > > > the same > > > > > media content types by "content" attribute in RS SDP. We are=20 > > > > > interested in knowing any specfic reason for this > > attribute to be > > > > > duplicated in Metadata XML. > > > > [JRE] I don't have a reason for **duplication**.=20 > However, I think > > > > there is a valid question to be asked whether the content > > type of an > >=20 > > > > MS should be represented: > > > > A) in XML; or > > > > B) in RS SDP as a=3Dcontent. > > > > > > > > The content type we are talking about is an MS content > > type, i.e., > > > > relating to the CS. One could argue that the > > corresponding RS stream > >=20 > > > > is NOT the same content type. For example: > > > > - CS MS content type is "slides". > > > > - RS media stream content type is "recording of slides". > > > > > > > > On this basis, I think the correct option for conveying the MS > > content > > > > type "slides" is A) (in the XML). > > > > > > > > Note that this would not involve duplication. The SDP a=3Dcontent=20 > > > > attribute is optional, so we need not use it for the RS. > > > > > > > > Perhaps my distinction is too theoretical, but I do > feel a little > > more > > > > comfortable using the XML rather than the RS SDP. > > > > > > > > John (as individual) > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > Partha > > > > > > > > > > last Interim SIPREC meeting Note: > > > > > > > > > > Slide 7: On the question of how to describe the content > > of an MS, > > > > > there was no objection to basing this on the types in > > the RFC 4796 > >=20 > > > > > registry (new values could be specified via the appropriate > > > > means if > > > > > needed). Paul had a slight concern that you might be mixing > > > > multiple > > > > > CS MSs into a single RS media stream and whether this might > > > > result in > > > > > cases not describable in this way, but in the end > accepted the > > > > > consensus. It needs to be discussed on the list > whether this is > > > > > conveyed in XML or in the RS SDP a=3Dcontent attribute. > > > > > > > > > > > > > > > > > _______________________________________________ > > > siprec mailing 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 eckelcu@cisco.com Tue Jul 5 10:14: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 DE44722801E for ; Tue, 5 Jul 2011 10:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.099 X-Spam-Level: X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[AWL=-0.100, 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 rV2b63xKzlJQ for ; Tue, 5 Jul 2011 10:14:33 -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 97510228018 for ; Tue, 5 Jul 2011 10:14:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=13777; q=dns/txt; s=iport; t=1309886073; x=1311095673; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=4CiW5sv8u9AdTzYkwCJOQaQONjsiVriLZR69xcMT7cc=; b=bTKi7kV6xsu6kDVLtDD8ZRe/35kFDx9Gvir3F7KYcHU+hAozo5sj1BET JxXhweursZ9khu9P7Suo5lXYFsggLb6KQPGFEA5Rjjr9Np/JD3m1jPHpX FZ8QTd02fVzVowwp76E5hH7mfHZh1c/LFHUro8f5VsuV5vcgdf2IbQya6 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAADNGE06rRDoH/2dsb2JhbABTmFGPOHeIeqQnnXGGNgSHP494i1U X-IronPort-AV: E=Sophos;i="4.65,480,1304294400"; d="scan'208";a="361534557" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-5.cisco.com with ESMTP; 05 Jul 2011 17:14:14 +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 p65HEECJ020431; Tue, 5 Jul 2011 17:14:14 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, 5 Jul 2011 10:14:14 -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, 5 Jul 2011 10:14:13 -0700 Message-ID: In-Reply-To: <07465C1D981ABC41A344374066AE1A2C38AFE9B1C0@TLVMBX01.nice.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [siprec] Content (RFC 4796) attribute in SDP or XML thread-index: Acw0mPHhxfeVJEDcQLSYWo3IAZGl7wABDbXgACpfOfAADTnVAAA/CH7wAL12yxAADByJIAAdm3FgAADcErAAQaGFkAAC7JoQAAMpvCA= References: <07465C1D981ABC41A344374066AE1A2C38AF6D40CC@TLVMBX01.nice.com> <07465C1D981ABC41A344374066AE1A2C38AF6D4376@TLVMBX01.nice.com> <07465C1D981ABC41A344374066AE1A2C38AFE9B1C0@TLVMBX01.nice.com> From: "Charles Eckel (eckelcu)" To: "Leon Portman" , "Elwell, John" , "Parthasarathi R (partr)" , X-OriginalArrivalTime: 05 Jul 2011 17:14:14.0732 (UTC) FILETIME=[F72128C0:01CC3B36] Subject: Re: [siprec] Content (RFC 4796) attribute in SDP or XML X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 17:14:35 -0000 Okay by me. Cheers, Charles > -----Original Message----- > From: Leon Portman [mailto:Leon.Portman@nice.com] > Sent: Tuesday, July 05, 2011 8:42 AM > To: Elwell, John; Parthasarathi R (partr); Charles Eckel (eckelcu); siprec@ietf.org > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML >=20 > I completely agree with the below. >=20 > Leon >=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Tuesday, July 05, 2011 5:44 PM > To: Parthasarathi R (partr); Leon Portman; Charles Eckel (eckelcu); siprec@ietf.org > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML >=20 > (as chair) > We should try to avoid opening up old issues. I think we had agreed that: > - RS SDP describes the RS, and therefore just describes how recordable media is delivered to the SRS. > It does not describe how media is delivered between CS endpoints as part of the CS. > - Therefore anything to do with the CS (i.e., the session being recorded) needs to be delivered to the > SRS as metadata (i.e., in XML). > - We don't see a need to standardize delivery of things like CS codecs in the metadata, but that could > be done using the extension mechanism. >=20 > Focusing now on the content attribute, I don't think there is any disagreement that the SRS needs to > know the content type (e.g., presentation) of a media stream. The SRC can obtain this from the > a=3Dcontent attribute of the CS SDP. The discussion is about whether this content attribute should be > conveyed to the SRS: > A) as an a=3Dcontent attribute of the RS SDP, or > B) within the metadata XML. >=20 > (as individual) > According to past decisions, there is perhaps an argument for B). If, for example, we wanted to convey > the fact that a CS media stream was subject to 256-bit encryption, this information would go in the > XML (it can't go in the RS SDP, because the RS might not use 256-bit encryption. Similarly, one could > argue that the content type of a CS media stream should go in the XML, not in the RS SDP. >=20 > I could even imagine cases where the content type of a CS media stream does not equal the content type > of an RS media stream, e.g., where the SRC combines the current speaker video and the room video into > two videos side-by-side in the same RS media stream. In the metadata these would be two media streams, > each with its own content type, but both would refer to the same RS media stream. >=20 > John >=20 >=20 > > -----Original Message----- > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > Sent: 04 July 2011 08:08 > > To: Leon Portman; Charles Eckel (eckelcu); Elwell, John; > > siprec@ietf.org > > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML > > > > Leon, > > > > Please read inline. > > > > Thanks > > Partha > > > > > -----Original Message----- > > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > > Sent: Monday, July 04, 2011 12:11 PM > > > To: Parthasarathi R (partr); Charles Eckel (eckelcu); Elwell, John; > > > siprec@ietf.org > > > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML > > > > > > Partha Hi > > > > > > Please see below. > > > > > > Leon > > > > > > -----Original Message----- > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > Sent: Sunday, July 03, 2011 7:50 PM > > > To: Leon Portman; Charles Eckel (eckelcu); Elwell, John; > > > siprec@ietf.org > > > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML > > > > > > Leon, > > > > > > Please read inline. > > > > > > Thanks > > > Partha > > > > > > -----Original Message----- > > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > > Sent: Sunday, July 03, 2011 4:13 PM > > > To: Charles Eckel (eckelcu); Elwell, John; Parthasarathi R (partr); > > > siprec@ietf.org > > > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML > > > > > > I do prefer that metadata XML will be as self-contained as possible > > > and not rely on conveying some data via RS SDP. RS SDP should only > > > be used to recording establishment and negotiation and not as a > > > mechanism for metadata reporting. > > > > > > In case Metadata XML has to be self-contained, the complete > > > SDP has to be converted into XML format or else XML has to have > > > sort of XML attribute which carries SDP. Creating mapping > > > for each SDP attribute with metadata XML element does not seems to > > > be feasible > > > > > > [LeonP] But if CS SDP is different from RS SDP, anyway you will need > > > to encapsulate the original RS SDP, so why not in XML? > > > > I guess that the confusion is here. In the current format, RS > > SDP is only carried towards SRS and CS SDP is not forwarded. > > This design > > is closed as part of ticket #71 > > (http://www.ietf.org/mail-archive/web/siprec/current/msg02106.html). > > Please bring up with the usecase for CS SDP if required > > > > > > > > Otherwise we will not be able to reuse same format for reporting > > > metadata via web services As per IETF-80 and last interim > > > meeting, there is no intent of reusing this metadata XML in other > > > protocol. In case reusing same format for webservice or XMPP is the > > > intent, the current metadata XML mechanism is not the appropriate. > > > This was discussed in > > > http://www.ietf.org/mail-archive/web/siprec/current/msg02151.html, > > > > > http://www.ietf.org/mail-archive/web/siprec/current/msg02155.html(1st > > > point in format slide). In case you have difference of opinion even > > > after this multiple discussion, let us again discuss at IETF-81. > > > > > > > > > [LeonP] I was not proposing replacing SIP with another transport > > > layer, just wanted to keep other options open. > > > > Current metadata format is customized for SIP transport. In > > case we need to keep the options open, the format has to be revisited > > from the scratch. In our analysis, we notice that REST architecture > > with Metadata XML is best fit for HTTP, XMPP > > > > I am > > > very big supporter for metadata over SIP reporting > > > > > Thanks, Me too.. > > > > > or as dedicated SIP session. > > > In case Metadata is separate session from RS, RS attribute > > > like RS-id MUST be included within XML. This was discussed at > > > http://www.ietf.org/mail-archive/web/siprec/current/msg02013.h > > tml. Could you please explain reason for the dedicated SIP > session > > for metadata. > > > > > > > > > [LeonP] The main use case is Recording on Demand, that is triggered > > > by SRS. In such case it will be very useful to have just one SIP > > > session and send all metadata over it (like CTI > > > link) and then only trigger recording (via external SRC > > > interface) only for specific call segments. > > > > > I understand the current implementation wherein few of the > > metadata like CDR records is passed through non-sip interface. It is > > outside the scope of SIPREC. The global-id in format shall be used to > > correlate. Please let me know in case any current SIPREC metadata > > attribute MUST be passed through this CTS link. > > > > > As for examples, the basic information as media type, labels, volume > > > etc. Any application level data can be relevant. Even indication of > > > encryption (for a case where RS is not encrypted) > > > > > > Leon > > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Charles Eckel > > (eckelcu) > > > Sent: Wednesday, June 29, 2011 7:17 PM > > > To: Elwell, John; Parthasarathi R (partr); siprec@ietf.org > > > Subject: Re: [siprec] Content (RFC 4796) attribute in SDP or XML > > > > > > I think it is sufficient, especially since we can assign new values > > > if necessary. > > > Are there any examples of what people think they might want to > > > capture in the SDP and/or metadata field? > > > > > > Cheers, > > > Charles > > > > > > > -----Original Message----- > > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > > Behalf Of Elwell, John > > > > Sent: Tuesday, June 28, 2011 3:11 AM > > > > To: Parthasarathi R (partr); siprec@ietf.org > > > > Subject: Re: [siprec] Content (RFC 4796) attribute in SDP or XML > > > > > > > > I would like other opinions on whether the SDP a=3Dcontent > > > attribute in > > > the RS SDP has the correct > > > > semantics for representing the content type of the > > recorded CS media > > > stream. > > > > > > > > John > > > > > > > > > -----Original Message----- > > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > > Sent: 28 June 2011 10:45 > > > > > To: Elwell, John; siprec@ietf.org > > > > > Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > > > > Subject: RE: Content (RFC 4796) attribute in SDP or XML > > > > > > > > > > John, > > > > > > > > > > In case if it is the argument of whether CS MS content > > > type or RS MS > > > > > > > > content type in the metadata, it is better for us to > > > re-open ticket > > > > > #71 > > > > > > > > (http://www.ietf.org/mail-archive/web/siprec/current/msg02106.html). > > > > > Please let me know your opinion here. > > > > > > > > > > The basic idea in metadata format is to re-use as much as SDP > > > > > attribute (like direction, content) in media level for > > RS dialog > > > > > (using SDP label attribute as a pointer) until otherwise > > > there is a > > > > > restriction in using in such manner. As per RFC 4796, > > there is no > > > > > such restriction and so, I prefer to reuse as content SDP > > > attribute > > > > > rather than introducing the new element for this > > > > > purpose. > > > > > > > > > > Thanks > > > > > Partha > > > > > > > > > > -----Original Message----- > > > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > > Sent: Monday, June 27, 2011 1:18 PM > > > > > To: Parthasarathi R (partr); siprec@ietf.org > > > > > Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > > > > Subject: RE: Content (RFC 4796) attribute in SDP or XML > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > > > Sent: 27 June 2011 08:08 > > > > > > To: siprec@ietf.org; Elwell, John > > > > > > Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > > > > > Subject: Content (RFC 4796) attribute in SDP or XML > > > > > > > > > > > > Hi all, > > > > > > > > > > > > As per the last interim SIPREC meeting, there is a > > consensus to > > > > > > describe the content of an MS using RFC 4796 & its > > > > > extension. As per > > > > > > RFC 4796, the multiple instance of content attribute > > is possible > > > to > > > > > > exist in SDP which shall be used in RS SDP. SRS shall group > > > > > the same > > > > > > media content types by "content" attribute in RS SDP. We are > > > > > > interested in knowing any specfic reason for this > > > attribute to be > > > > > > duplicated in Metadata XML. > > > > > [JRE] I don't have a reason for **duplication**. > > However, I think > > > > > there is a valid question to be asked whether the content > > > type of an > > > > > > > > MS should be represented: > > > > > A) in XML; or > > > > > B) in RS SDP as a=3Dcontent. > > > > > > > > > > The content type we are talking about is an MS content > > > type, i.e., > > > > > relating to the CS. One could argue that the > > > corresponding RS stream > > > > > > > > is NOT the same content type. For example: > > > > > - CS MS content type is "slides". > > > > > - RS media stream content type is "recording of slides". > > > > > > > > > > On this basis, I think the correct option for conveying the MS > > > content > > > > > type "slides" is A) (in the XML). > > > > > > > > > > Note that this would not involve duplication. The SDP a=3Dcontent > > > > > attribute is optional, so we need not use it for the RS. > > > > > > > > > > Perhaps my distinction is too theoretical, but I do > > feel a little > > > more > > > > > comfortable using the XML rather than the RS SDP. > > > > > > > > > > John (as individual) > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > Partha > > > > > > > > > > > > last Interim SIPREC meeting Note: > > > > > > > > > > > > Slide 7: On the question of how to describe the content > > > of an MS, > > > > > > there was no objection to basing this on the types in > > > the RFC 4796 > > > > > > > > > registry (new values could be specified via the appropriate > > > > > means if > > > > > > needed). Paul had a slight concern that you might be mixing > > > > > multiple > > > > > > CS MSs into a single RS media stream and whether this might > > > > > result in > > > > > > cases not describable in this way, but in the end > > accepted the > > > > > > consensus. It needs to be discussed on the list > > whether this is > > > > > > conveyed in XML or in the RS SDP a=3Dcontent attribute. > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > siprec mailing 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 Jul 5 11:05: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 AA79921F893D for ; Tue, 5 Jul 2011 11:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.757 X-Spam-Level: X-Spam-Status: No, score=-9.757 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, J_CHICKENPOX_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 5fkrCsIjI1iC for ; Tue, 5 Jul 2011 11:05:55 -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 6587921F891B for ; Tue, 5 Jul 2011 11:05:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=16953; q=dns/txt; s=iport; t=1309889154; x=1311098754; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=KOMGeyC1AkXQSfixxf1MgngHPbQZma7BeQm8ATZiA9c=; b=jSudVZqML6pEZEuqg0dgeAV3LcLF2FQIgtmaRn3Mb7JGdlVLLxzBn3kh rsqW2Yhx2hNwGTKuKhiy8jKMZTLEm/eotxV1rA2cesd5o9HjpmeVGsdZi d8a3nFJFl7Eli3dENOha4btpSSYnVHyV2UQxXOg/J7KWHUNEdD1TswJ87 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAAEdRE05Io8US/2dsb2JhbABTmFGPOHeIeqQ6nXmGNgSHPY96iz0 X-IronPort-AV: E=Sophos;i="4.65,481,1304294400"; d="scan'208";a="99768541" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-1.cisco.com with ESMTP; 05 Jul 2011 18:05:52 +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 p65I5pp3018193; Tue, 5 Jul 2011 18:05: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); Tue, 5 Jul 2011 23:35:51 +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, 5 Jul 2011 23:35:55 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Content (RFC 4796) attribute in SDP or XML Thread-Index: Acw0mPHhxfeVJEDcQLSYWo3IAZGl7wABDbXgACpfOfAADTnVAAA/CH7wAL12yxAADByJIAAdm3FgAADcErAAQaGFkAAC7JoQAAMpvCAAAObikA== References: <07465C1D981ABC41A344374066AE1A2C38AF6D40CC@TLVMBX01.nice.com> <07465C1D981ABC41A344374066AE1A2C38AF6D4376@TLVMBX01.nice.com> <07465C1D981ABC41A344374066AE1A2C38AFE9B1C0@TLVMBX01.nice.com> From: "Parthasarathi R (partr)" To: "Charles Eckel (eckelcu)" , "Leon Portman" , "Elwell, John" , X-OriginalArrivalTime: 05 Jul 2011 18:05:51.0851 (UTC) FILETIME=[2D2803B0:01CC3B3E] Subject: Re: [siprec] Content (RFC 4796) attribute in SDP or XML X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 18:05:56 -0000 John, Please read inline. Thanks Partha > -----Original Message----- > From: Charles Eckel (eckelcu)=20 > Sent: Tuesday, July 05, 2011 10:44 PM > To: Leon Portman; Elwell, John; Parthasarathi R (partr);=20 > siprec@ietf.org > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML >=20 > Okay by me. >=20 > Cheers, > Charles >=20 > > -----Original Message----- > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > Sent: Tuesday, July 05, 2011 8:42 AM > > To: Elwell, John; Parthasarathi R (partr); Charles Eckel (eckelcu);=20 > > siprec@ietf.org > > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML > >=20 > > I completely agree with the below. > >=20 > > Leon > >=20 > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Tuesday, July 05, 2011 5:44 PM > > To: Parthasarathi R (partr); Leon Portman; Charles Eckel (eckelcu);=20 > > siprec@ietf.org > > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML > >=20 > > (as chair) > > We should try to avoid opening up old issues. I think we=20 > had agreed that: > > - RS SDP describes the RS, and therefore just describes how=20 > recordable media is delivered to the SRS. > > It does not describe how media is delivered between CS=20 > endpoints as part of the CS. > > - Therefore anything to do with the CS (i.e., the session being=20 > > recorded) needs to be delivered to the SRS as metadata=20 > (i.e., in XML). > > - We don't see a need to standardize delivery of things=20 > like CS codecs=20 > > in the metadata, but that could be done using the extension=20 > mechanism. > >=20 Hope everyone agree here that CS SDP information could be passed as extension-data. attribute within may help to achieve this requirement. > > Focusing now on the content attribute, I don't think there is any=20 > > disagreement that the SRS needs to know the content type (e.g.,=20 > > presentation) of a media stream. The SRC can obtain this from the=20 > > a=3Dcontent attribute of the CS SDP. The discussion is about=20 > whether this content attribute should be conveyed to the SRS: > > A) as an a=3Dcontent attribute of the RS SDP, or > > B) within the metadata XML. > >=20 > > (as individual) > > According to past decisions, there is perhaps an argument=20 > for B). If,=20 > > for example, we wanted to convey the fact that a CS media=20 > stream was=20 > > subject to 256-bit encryption, this information would go in the XML=20 Here I have the doubt. In case 256-bit encryption is not used by RS SDP, Please let me know the reason for passing the key information to SRS because RS SDP is not encrypted in that fashion. > > (it can't go in the RS SDP, because the RS might not use=20 > 256-bit encryption. Similarly, one could argue that the=20 > content type of a CS media stream should go in the XML, not=20 > in the RS SDP. I'm seeing content-type attribute as one of the extension of SDP a=3D attribute. In general, it is possible to convert CS mediastream content type to RS media stream content type because SRC RS media stream is formed based on CS media stream except for the mixing scenarios > >=20 > > I could even imagine cases where the content type of a CS=20 > media stream=20 > > does not equal the content type of an RS media stream,=20 > e.g., where the=20 > > SRC combines the current speaker video and the room video into two=20 > > videos side-by-side in the same RS media stream.=20 RS media stream is a mixed content type stream of "current speaker video" and "room video" and the resultant shall be named as "mixed current speaker video & room video" which shall be passed as new content type extension to SRS In the=20 > metadata these would be two media streams, each with its own=20 > content type, but both would refer to the same RS media stream. > >=20 It will be problematic approach because the actual media and metadata are not related explicitly. As per the current description, there are two element with different unique-id uses same label in SDP with different XML element ("content-type") within them. The issue is whether media has stream1 behavior or stream2 behavior or mixed. We will able to extent XML element for having single interpretation but it is not fully clarified in the draft now. The bottom-up matching like stream1 & stream2 has same label element and it has to be grouped together is not explicit in this scenario. We need more investigation both information is required but not the actual media. Please correct me in I'm missing something > > John > >=20 > >=20 > > > -----Original Message----- > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > Sent: 04 July 2011 08:08 > > > To: Leon Portman; Charles Eckel (eckelcu); Elwell, John;=20 > > > siprec@ietf.org > > > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML > > > > > > Leon, > > > > > > Please read inline. > > > > > > Thanks > > > Partha > > > > > > > -----Original Message----- > > > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > > > Sent: Monday, July 04, 2011 12:11 PM > > > > To: Parthasarathi R (partr); Charles Eckel (eckelcu); Elwell,=20 > > > > John; siprec@ietf.org > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML > > > > > > > > Partha Hi > > > > > > > > Please see below. > > > > > > > > Leon > > > > > > > > -----Original Message----- > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > Sent: Sunday, July 03, 2011 7:50 PM > > > > To: Leon Portman; Charles Eckel (eckelcu); Elwell, John;=20 > > > > siprec@ietf.org > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML > > > > > > > > Leon, > > > > > > > > Please read inline. > > > > > > > > Thanks > > > > Partha > > > > > > > > -----Original Message----- > > > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > > > Sent: Sunday, July 03, 2011 4:13 PM > > > > To: Charles Eckel (eckelcu); Elwell, John; Parthasarathi R=20 > > > > (partr); siprec@ietf.org > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML > > > > > > > > I do prefer that metadata XML will be as self-contained as=20 > > > > possible and not rely on conveying some data via RS SDP. RS SDP=20 > > > > should only be used to recording establishment and=20 > negotiation and=20 > > > > not as a mechanism for metadata reporting. > > > > > > > > In case Metadata XML has to be self-contained, the=20 > > > > complete SDP has to be converted into XML format or=20 > else XML has=20 > > > > to have sort of XML attribute which carries SDP.=20 > > > > Creating mapping for each SDP attribute with metadata=20 > XML element=20 > > > > does not seems to be feasible > > > > > > > > [LeonP] But if CS SDP is different from RS SDP, anyway you will=20 > > > > need to encapsulate the original RS SDP, so why not in XML? > > > > > > I guess that the confusion is here. In the=20 > current format,=20 > > > RS SDP is only carried towards SRS and CS SDP is not forwarded. > > > This design > > > is closed as part of ticket #71 > > >=20 > (http://www.ietf.org/mail-archive/web/siprec/current/msg02106.html). > > > Please bring up with the usecase for CS SDP if required > > > > > > > > > > > Otherwise we will not be able to reuse same format for=20 > reporting=20 > > > > metadata via web services As per IETF-80 and=20 > last interim=20 > > > > meeting, there is no intent of reusing this metadata=20 > XML in other=20 > > > > protocol. In case reusing same format for webservice or XMPP is=20 > > > > the intent, the current metadata XML mechanism is not=20 > the appropriate. > > > > This was discussed in > > > >=20 > http://www.ietf.org/mail-archive/web/siprec/current/msg02151.html, > > > > > > >=20 > http://www.ietf.org/mail-archive/web/siprec/current/msg02155.html(1s > > > t > > > > point in format slide). In case you have difference of opinion=20 > > > > even after this multiple discussion, let us again=20 > discuss at IETF-81. > > > > > > > > > > > > [LeonP] I was not proposing replacing SIP with another=20 > transport=20 > > > > layer, just wanted to keep other options open. > > > > > > Current metadata format is customized for SIP=20 > transport. In=20 > > > case we need to keep the options open, the format has to be=20 > > > revisited from the scratch. In our analysis, we notice that REST=20 > > > architecture with Metadata XML is best fit for HTTP, XMPP=20 > > > > > > > I am > > > > very big supporter for metadata over SIP reporting > > > > > > > Thanks, Me too.. > > > > > > > or as dedicated SIP session. > > > > In case Metadata is separate session from RS, RS=20 > > > > attribute like RS-id MUST be included within XML. This was=20 > > > > discussed at=20 > > > > http://www.ietf.org/mail-archive/web/siprec/current/msg02013.h > > > tml. Could you please explain reason for the dedicated=20 > SIP > session=20 > > > for metadata. > > > > > > > > > > > > [LeonP] The main use case is Recording on Demand, that is=20 > > > > triggered by SRS. In such case it will be very useful=20 > to have just=20 > > > > one SIP session and send all metadata over it (like CTI > > > > link) and then only trigger recording (via external SRC > > > > interface) only for specific call segments. > > > > > > > I understand the current implementation wherein=20 > few of the=20 > > > metadata like CDR records is passed through non-sip=20 > interface. It is=20 > > > outside the scope of SIPREC. The global-id in format=20 > shall be used=20 > > > to correlate. Please let me know in case any current=20 > SIPREC metadata=20 > > > attribute MUST be passed through this CTS link. > > > > > > > As for examples, the basic information as media type, labels,=20 > > > > volume etc. Any application level data can be relevant. Even=20 > > > > indication of encryption (for a case where RS is not encrypted) > > > > > > > > Leon > > > > > > > > -----Original Message----- > > > > From: siprec-bounces@ietf.org > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Charles Eckel > > > (eckelcu) > > > > Sent: Wednesday, June 29, 2011 7:17 PM > > > > To: Elwell, John; Parthasarathi R (partr); siprec@ietf.org > > > > Subject: Re: [siprec] Content (RFC 4796) attribute in SDP or XML > > > > > > > > I think it is sufficient, especially since we can assign new=20 > > > > values if necessary. > > > > Are there any examples of what people think they might want to=20 > > > > capture in the SDP and/or metadata field? > > > > > > > > Cheers, > > > > Charles > > > > > > > > > -----Original Message----- > > > > > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org]=20 > > > > > On > > > > Behalf Of Elwell, John > > > > > Sent: Tuesday, June 28, 2011 3:11 AM > > > > > To: Parthasarathi R (partr); siprec@ietf.org > > > > > Subject: Re: [siprec] Content (RFC 4796) attribute in=20 > SDP or XML > > > > > > > > > > I would like other opinions on whether the SDP a=3Dcontent > > > > attribute in > > > > the RS SDP has the correct > > > > > semantics for representing the content type of the > > > recorded CS media > > > > stream. > > > > > > > > > > John > > > > > > > > > > > -----Original Message----- > > > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > > > Sent: 28 June 2011 10:45 > > > > > > To: Elwell, John; siprec@ietf.org > > > > > > Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > > > > > Subject: RE: Content (RFC 4796) attribute in SDP or XML > > > > > > > > > > > > John, > > > > > > > > > > > > In case if it is the argument of whether CS MS content > > > > type or RS MS > > > > > > > > > > content type in the metadata, it is better for us to > > > > re-open ticket > > > > > > #71 > > > > > > > > > >=20 > (http://www.ietf.org/mail-archive/web/siprec/current/msg02106.html). > > > > > > Please let me know your opinion here. > > > > > > > > > > > > The basic idea in metadata format is to re-use as=20 > much as SDP=20 > > > > > > attribute (like direction, content) in media level for > > > RS dialog > > > > > > (using SDP label attribute as a pointer) until otherwise > > > > there is a > > > > > > restriction in using in such manner. As per RFC 4796, > > > there is no > > > > > > such restriction and so, I prefer to reuse as content SDP > > > > attribute > > > > > > rather than introducing the new element for=20 > > > > > > this purpose. > > > > > > > > > > > > Thanks > > > > > > Partha > > > > > > > > > > > > -----Original Message----- > > > > > > From: Elwell, John=20 > [mailto:john.elwell@siemens-enterprise.com] > > > > > > Sent: Monday, June 27, 2011 1:18 PM > > > > > > To: Parthasarathi R (partr); siprec@ietf.org > > > > > > Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > > > > > Subject: RE: Content (RFC 4796) attribute in SDP or XML > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > > > > Sent: 27 June 2011 08:08 > > > > > > > To: siprec@ietf.org; Elwell, John > > > > > > > Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > > > > > > Subject: Content (RFC 4796) attribute in SDP or XML > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > As per the last interim SIPREC meeting, there is a > > > consensus to > > > > > > > describe the content of an MS using RFC 4796 & its > > > > > > extension. As per > > > > > > > RFC 4796, the multiple instance of content attribute > > > is possible > > > > to > > > > > > > exist in SDP which shall be used in RS SDP. SRS=20 > shall group > > > > > > the same > > > > > > > media content types by "content" attribute in RS=20 > SDP. We are=20 > > > > > > > interested in knowing any specfic reason for this > > > > attribute to be > > > > > > > duplicated in Metadata XML. > > > > > > [JRE] I don't have a reason for **duplication**. > > > However, I think > > > > > > there is a valid question to be asked whether the content > > > > type of an > > > > > > > > > > MS should be represented: > > > > > > A) in XML; or > > > > > > B) in RS SDP as a=3Dcontent. > > > > > > > > > > > > The content type we are talking about is an MS content > > > > type, i.e., > > > > > > relating to the CS. One could argue that the > > > > corresponding RS stream > > > > > > > > > > is NOT the same content type. For example: > > > > > > - CS MS content type is "slides". > > > > > > - RS media stream content type is "recording of slides". > > > > > > > > > > > > On this basis, I think the correct option for=20 > conveying the MS > > > > content > > > > > > type "slides" is A) (in the XML). > > > > > > > > > > > > Note that this would not involve duplication. The SDP=20 > > > > > > a=3Dcontent attribute is optional, so we need not use=20 > it for the RS. > > > > > > > > > > > > Perhaps my distinction is too theoretical, but I do > > > feel a little > > > > more > > > > > > comfortable using the XML rather than the RS SDP. > > > > > > > > > > > > John (as individual) > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > Partha > > > > > > > > > > > > > > last Interim SIPREC meeting Note: > > > > > > > > > > > > > > Slide 7: On the question of how to describe the content > > > > of an MS, > > > > > > > there was no objection to basing this on the types in > > > > the RFC 4796 > > > > > > > > > > > registry (new values could be specified via the=20 > appropriate > > > > > > means if > > > > > > > needed). Paul had a slight concern that you might=20 > be mixing > > > > > > multiple > > > > > > > CS MSs into a single RS media stream and whether=20 > this might > > > > > > result in > > > > > > > cases not describable in this way, but in the end > > > accepted the > > > > > > > consensus. It needs to be discussed on the list > > > whether this is > > > > > > > conveyed in XML or in the RS SDP a=3Dcontent attribute. > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > siprec mailing 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 Tue Jul 5 23:35: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 6FA8521F8686 for ; Tue, 5 Jul 2011 23:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.119 X-Spam-Level: X-Spam-Status: No, score=-106.119 tagged_above=-999 required=5 tests=[AWL=-0.120, 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 ehImLAfiEizu for ; Tue, 5 Jul 2011 23:35:24 -0700 (PDT) Received: from mail182.messagelabs.com (mail182.messagelabs.com [85.158.139.83]) by ietfa.amsl.com (Postfix) with SMTP id E5F9E21F8689 for ; Tue, 5 Jul 2011 23:35:22 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-10.tower-182.messagelabs.com!1309934120!10675316!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 32607 invoked from network); 6 Jul 2011 06:35:20 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-10.tower-182.messagelabs.com with SMTP; 6 Jul 2011 06:35:20 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id CD5E523F03E6; Wed, 6 Jul 2011 08:35:20 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 6 Jul 2011 08:35:20 +0200 From: "Elwell, John" To: "Parthasarathi R (partr)" , "Charles Eckel (eckelcu)" , Leon Portman , "siprec@ietf.org" Date: Wed, 6 Jul 2011 08:35:19 +0200 Thread-Topic: [siprec] Content (RFC 4796) attribute in SDP or XML Thread-Index: Acw0mPHhxfeVJEDcQLSYWo3IAZGl7wABDbXgACpfOfAADTnVAAA/CH7wAL12yxAADByJIAAdm3FgAADcErAAQaGFkAAC7JoQAAMpvCAAAObikAAasOng Message-ID: References: <07465C1D981ABC41A344374066AE1A2C38AF6D40CC@TLVMBX01.nice.com> <07465C1D981ABC41A344374066AE1A2C38AF6D4376@TLVMBX01.nice.com> <07465C1D981ABC41A344374066AE1A2C38AFE9B1C0@TLVMBX01.nice.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Content (RFC 4796) attribute in SDP or XML X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 06:35:25 -0000 > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > Sent: 05 July 2011 19:06 > To: Charles Eckel (eckelcu); Leon Portman; Elwell, John; > siprec@ietf.org > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML > > John, > > Please read inline. > > Thanks > Partha > > > -----Original Message----- > > From: Charles Eckel (eckelcu) > > Sent: Tuesday, July 05, 2011 10:44 PM > > To: Leon Portman; Elwell, John; Parthasarathi R (partr); > > siprec@ietf.org > > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML > > > > Okay by me. > > > > Cheers, > > Charles > > > > > -----Original Message----- > > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > > Sent: Tuesday, July 05, 2011 8:42 AM > > > To: Elwell, John; Parthasarathi R (partr); Charles Eckel > (eckelcu); > > > siprec@ietf.org > > > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML > > > > > > I completely agree with the below. > > > > > > Leon > > > > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > Sent: Tuesday, July 05, 2011 5:44 PM > > > To: Parthasarathi R (partr); Leon Portman; Charles Eckel > (eckelcu); > > > siprec@ietf.org > > > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML > > > > > > (as chair) > > > We should try to avoid opening up old issues. I think we > > had agreed that: > > > - RS SDP describes the RS, and therefore just describes how > > recordable media is delivered to the SRS. > > > It does not describe how media is delivered between CS > > endpoints as part of the CS. > > > - Therefore anything to do with the CS (i.e., the session being > > > recorded) needs to be delivered to the SRS as metadata > > (i.e., in XML). > > > - We don't see a need to standardize delivery of things > > like CS codecs > > > in the metadata, but that could be done using the extension > > mechanism. > > > > Hope everyone agree here that CS SDP information could be > passed as extension-data. attribute within > may help to achieve this requirement. [JRE] Or even as the standardized part of an MS element if we wish. > > > > Focusing now on the content attribute, I don't think there is any > > > disagreement that the SRS needs to know the content type (e.g., > > > presentation) of a media stream. The SRC can obtain this from the > > > a=3Dcontent attribute of the CS SDP. The discussion is about > > whether this content attribute should be conveyed to the SRS: > > > A) as an a=3Dcontent attribute of the RS SDP, or > > > B) within the metadata XML. > > > > > > (as individual) > > > According to past decisions, there is perhaps an argument > > for B). If, > > > for example, we wanted to convey the fact that a CS media > > stream was > > > subject to 256-bit encryption, this information would go > in the XML > > Here I have the doubt. In case 256-bit encryption is not used > by RS SDP, Please let me know the reason for passing the key > information > to SRS because RS SDP is not encrypted in that fashion. [JRE] I did not suggest passing the CS keying material to the SRS. I just s= uggested passing the information that the CS media stream used 256 bit encr= yption. Perhaps this was a bad example - it was just meant to illustrate th= e general principle that information about the CS should be passed in metad= ata XML. > > > > (it can't go in the RS SDP, because the RS might not use > > 256-bit encryption. Similarly, one could argue that the > > content type of a CS media stream should go in the XML, not > > in the RS SDP. > I'm seeing content-type attribute as one of the extension of > SDP a=3D attribute. In general, it is possible to convert CS mediastream > content type to RS media stream content type because SRC RS > media stream > is formed based on CS media stream except for the mixing scenarios > > > > > > > > I could even imagine cases where the content type of a CS > > media stream > > > does not equal the content type of an RS media stream, > > e.g., where the > > > SRC combines the current speaker video and the room video > into two > > > videos side-by-side in the same RS media stream. > > RS media stream is a mixed content type stream of "current > speaker video" and "room video" and the resultant shall be named as > "mixed current speaker video & room video" which shall be > passed as new > content type extension to SRS [JRE] Right, so you agree this can't be passed in the RS SDP. I would chall= enge the need to define (and register) a new RFC 4796 value "mixed current = speaker video & room video". We have two MS elements (representing the two = CS video streams for current speaker and room. Why can't we just place the = respective RFC 4796 content types in the respective MS elements? And why do= es it need to be as extension data - why can't it be standardized from day = one? John (as individual) > > In the > > metadata these would be two media streams, each with its own > > content type, but both would refer to the same RS media stream. > > > > It will be problematic approach because the actual media and > metadata are not related explicitly. As per the current description, > there are two element with different unique-id uses > same label > in SDP with different XML element ("content-type") within them. The > issue is whether media has stream1 behavior or stream2 behavior or > mixed. We will able to extent XML element for having single > interpretation but it is not fully clarified in the draft now. The > bottom-up matching like stream1 & stream2 has same label > element and it > has to be grouped together is not explicit in this scenario. We need > more investigation both information is required but not the actual > media. Please correct me in I'm missing something > > > > John > > > > > > > > > > -----Original Message----- > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > Sent: 04 July 2011 08:08 > > > > To: Leon Portman; Charles Eckel (eckelcu); Elwell, John; > > > > siprec@ietf.org > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML > > > > > > > > Leon, > > > > > > > > Please read inline. > > > > > > > > Thanks > > > > Partha > > > > > > > > > -----Original Message----- > > > > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > > > > Sent: Monday, July 04, 2011 12:11 PM > > > > > To: Parthasarathi R (partr); Charles Eckel (eckelcu); Elwell, > > > > > John; siprec@ietf.org > > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in > SDP or XML > > > > > > > > > > Partha Hi > > > > > > > > > > Please see below. > > > > > > > > > > Leon > > > > > > > > > > -----Original Message----- > > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > > Sent: Sunday, July 03, 2011 7:50 PM > > > > > To: Leon Portman; Charles Eckel (eckelcu); Elwell, John; > > > > > siprec@ietf.org > > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in > SDP or XML > > > > > > > > > > Leon, > > > > > > > > > > Please read inline. > > > > > > > > > > Thanks > > > > > Partha > > > > > > > > > > -----Original Message----- > > > > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > > > > Sent: Sunday, July 03, 2011 4:13 PM > > > > > To: Charles Eckel (eckelcu); Elwell, John; Parthasarathi R > > > > > (partr); siprec@ietf.org > > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in > SDP or XML > > > > > > > > > > I do prefer that metadata XML will be as self-contained as > > > > > possible and not rely on conveying some data via RS > SDP. RS SDP > > > > > should only be used to recording establishment and > > negotiation and > > > > > not as a mechanism for metadata reporting. > > > > > > > > > > In case Metadata XML has to be self-contained, the > > > > > complete SDP has to be converted into XML format or > > else XML has > > > > > to have sort of XML attribute which carries SDP. > > > > > Creating mapping for each SDP attribute with metadata > > XML element > > > > > does not seems to be feasible > > > > > > > > > > [LeonP] But if CS SDP is different from RS SDP, > anyway you will > > > > > need to encapsulate the original RS SDP, so why not in XML? > > > > > > > > I guess that the confusion is here. In the > > current format, > > > > RS SDP is only carried towards SRS and CS SDP is not forwarded. > > > > This design > > > > is closed as part of ticket #71 > > > > > > (http://www.ietf.org/mail-archive/web/siprec/current/msg02106.html). > > > > Please bring up with the usecase for CS SDP if required > > > > > > > > > > > > > > > Otherwise we will not be able to reuse same format for > > reporting > > > > > metadata via web services As per IETF-80 and > > last interim > > > > > meeting, there is no intent of reusing this metadata > > XML in other > > > > > protocol. In case reusing same format for webservice > or XMPP is > > > > > the intent, the current metadata XML mechanism is not > > the appropriate. > > > > > This was discussed in > > > > > > > http://www.ietf.org/mail-archive/web/siprec/current/msg02151.html, > > > > > > > > > > > http://www.ietf.org/mail-archive/web/siprec/current/msg02155.html(1s > > > > t > > > > > point in format slide). In case you have difference > of opinion > > > > > even after this multiple discussion, let us again > > discuss at IETF-81. > > > > > > > > > > > > > > > [LeonP] I was not proposing replacing SIP with another > > transport > > > > > layer, just wanted to keep other options open. > > > > > > > > Current metadata format is customized for SIP > > transport. In > > > > case we need to keep the options open, the format has to be > > > > revisited from the scratch. In our analysis, we notice > that REST > > > > architecture with Metadata XML is best fit for HTTP, XMPP > > > > > > > > > > I am > > > > > very big supporter for metadata over SIP reporting > > > > > > > > > Thanks, Me too.. > > > > > > > > > or as dedicated SIP session. > > > > > In case Metadata is separate session from RS, RS > > > > > attribute like RS-id MUST be included within XML. This was > > > > > discussed at > > > > > http://www.ietf.org/mail-archive/web/siprec/current/msg02013.h > > > > tml. Could you please explain reason for the dedicated > > SIP > session > > > > for metadata. > > > > > > > > > > > > > > > [LeonP] The main use case is Recording on Demand, that is > > > > > triggered by SRS. In such case it will be very useful > > to have just > > > > > one SIP session and send all metadata over it (like CTI > > > > > link) and then only trigger recording (via external SRC > > > > > interface) only for specific call segments. > > > > > > > > > I understand the current implementation wherein > > few of the > > > > metadata like CDR records is passed through non-sip > > interface. It is > > > > outside the scope of SIPREC. The global-id in format > > shall be used > > > > to correlate. Please let me know in case any current > > SIPREC metadata > > > > attribute MUST be passed through this CTS link. > > > > > > > > > As for examples, the basic information as media type, labels, > > > > > volume etc. Any application level data can be relevant. Even > > > > > indication of encryption (for a case where RS is not > encrypted) > > > > > > > > > > Leon > > > > > > > > > > -----Original Message----- > > > > > From: siprec-bounces@ietf.org > > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Charles Eckel > > > > (eckelcu) > > > > > Sent: Wednesday, June 29, 2011 7:17 PM > > > > > To: Elwell, John; Parthasarathi R (partr); siprec@ietf.org > > > > > Subject: Re: [siprec] Content (RFC 4796) attribute in > SDP or XML > > > > > > > > > > I think it is sufficient, especially since we can assign new > > > > > values if necessary. > > > > > Are there any examples of what people think they > might want to > > > > > capture in the SDP and/or metadata field? > > > > > > > > > > Cheers, > > > > > Charles > > > > > > > > > > > -----Original Message----- > > > > > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] > > > > > > On > > > > > Behalf Of Elwell, John > > > > > > Sent: Tuesday, June 28, 2011 3:11 AM > > > > > > To: Parthasarathi R (partr); siprec@ietf.org > > > > > > Subject: Re: [siprec] Content (RFC 4796) attribute in > > SDP or XML > > > > > > > > > > > > I would like other opinions on whether the SDP a=3Dcontent > > > > > attribute in > > > > > the RS SDP has the correct > > > > > > semantics for representing the content type of the > > > > recorded CS media > > > > > stream. > > > > > > > > > > > > John > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > > > > Sent: 28 June 2011 10:45 > > > > > > > To: Elwell, John; siprec@ietf.org > > > > > > > Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > > > > > > Subject: RE: Content (RFC 4796) attribute in SDP or XML > > > > > > > > > > > > > > John, > > > > > > > > > > > > > > In case if it is the argument of whether CS MS content > > > > > type or RS MS > > > > > > > > > > > > content type in the metadata, it is better for us to > > > > > re-open ticket > > > > > > > #71 > > > > > > > > > > > > > > (http://www.ietf.org/mail-archive/web/siprec/current/msg02106.html). > > > > > > > Please let me know your opinion here. > > > > > > > > > > > > > > The basic idea in metadata format is to re-use as > > much as SDP > > > > > > > attribute (like direction, content) in media level for > > > > RS dialog > > > > > > > (using SDP label attribute as a pointer) until otherwise > > > > > there is a > > > > > > > restriction in using in such manner. As per RFC 4796, > > > > there is no > > > > > > > such restriction and so, I prefer to reuse as content SDP > > > > > attribute > > > > > > > rather than introducing the new > element for > > > > > > > this purpose. > > > > > > > > > > > > > > Thanks > > > > > > > Partha > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Elwell, John > > [mailto:john.elwell@siemens-enterprise.com] > > > > > > > Sent: Monday, June 27, 2011 1:18 PM > > > > > > > To: Parthasarathi R (partr); siprec@ietf.org > > > > > > > Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > > > > > > Subject: RE: Content (RFC 4796) attribute in SDP or XML > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > > > > > Sent: 27 June 2011 08:08 > > > > > > > > To: siprec@ietf.org; Elwell, John > > > > > > > > Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > > > > > > > Subject: Content (RFC 4796) attribute in SDP or XML > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > As per the last interim SIPREC meeting, there is a > > > > consensus to > > > > > > > > describe the content of an MS using RFC 4796 & its > > > > > > > extension. As per > > > > > > > > RFC 4796, the multiple instance of content attribute > > > > is possible > > > > > to > > > > > > > > exist in SDP which shall be used in RS SDP. SRS > > shall group > > > > > > > the same > > > > > > > > media content types by "content" attribute in RS > > SDP. We are > > > > > > > > interested in knowing any specfic reason for this > > > > > attribute to be > > > > > > > > duplicated in Metadata XML. > > > > > > > [JRE] I don't have a reason for **duplication**. > > > > However, I think > > > > > > > there is a valid question to be asked whether the content > > > > > type of an > > > > > > > > > > > > MS should be represented: > > > > > > > A) in XML; or > > > > > > > B) in RS SDP as a=3Dcontent. > > > > > > > > > > > > > > The content type we are talking about is an MS content > > > > > type, i.e., > > > > > > > relating to the CS. One could argue that the > > > > > corresponding RS stream > > > > > > > > > > > > is NOT the same content type. For example: > > > > > > > - CS MS content type is "slides". > > > > > > > - RS media stream content type is "recording of slides". > > > > > > > > > > > > > > On this basis, I think the correct option for > > conveying the MS > > > > > content > > > > > > > type "slides" is A) (in the XML). > > > > > > > > > > > > > > Note that this would not involve duplication. The SDP > > > > > > > a=3Dcontent attribute is optional, so we need not use > > it for the RS. > > > > > > > > > > > > > > Perhaps my distinction is too theoretical, but I do > > > > feel a little > > > > > more > > > > > > > comfortable using the XML rather than the RS SDP. > > > > > > > > > > > > > > John (as individual) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > Partha > > > > > > > > > > > > > > > > last Interim SIPREC meeting Note: > > > > > > > > > > > > > > > > Slide 7: On the question of how to describe the content > > > > > of an MS, > > > > > > > > there was no objection to basing this on the types in > > > > > the RFC 4796 > > > > > > > > > > > > > registry (new values could be specified via the > > appropriate > > > > > > > means if > > > > > > > > needed). Paul had a slight concern that you might > > be mixing > > > > > > > multiple > > > > > > > > CS MSs into a single RS media stream and whether > > this might > > > > > > > result in > > > > > > > > cases not describable in this way, but in the end > > > > accepted the > > > > > > > > consensus. It needs to be discussed on the list > > > > whether this is > > > > > > > > conveyed in XML or in the RS SDP a=3Dcontent attribute. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > siprec mailing 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 Jul 6 00:08: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 809B821F8706; Wed, 6 Jul 2011 00:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 B39BSAsXPbVW; Wed, 6 Jul 2011 00:08:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2B221F86FC; Wed, 6 Jul 2011 00:08:44 -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: <20110706070844.22445.30989.idtracker@ietfa.amsl.com> Date: Wed, 06 Jul 2011 00:08:44 -0700 Cc: siprec@ietf.org Subject: [siprec] I-D Action: draft-ietf-siprec-metadata-02.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 07:08:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP Recording Working Group of the IE= TF. Title : Session Initiation Protocol (SIP) Recording Metadata Author(s) : Ram Mohan Ravindranath Parthasarathi Ravindran Paul Kyzivat Filename : draft-ietf-siprec-metadata-02.txt Pages : 34 Date : 2011-07-06 Session recording is a critical requirement in many communications environments such as call centers and financial trading. In some of these environments, all calls must be recorded for regulatory, compliance, and consumer protection reasons. Recording of a session is typically performed by sending a copy of a media stream to a recording device. This document describes the metadata model as viewed by Session Recording Server(SRS) and the Recording metadata format. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-siprec-metadata-02.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-metadata-02.txt From rmohanr@cisco.com Wed Jul 6 00:14: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 51D3921F86A3 for ; Wed, 6 Jul 2011 00:14:26 -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 S+uYVqrLTPKM for ; Wed, 6 Jul 2011 00:14:24 -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 D42AB21F86A0 for ; Wed, 6 Jul 2011 00:14:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=2365; q=dns/txt; s=iport; t=1309936464; x=1311146064; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=lkp3EydKV8yK6WFOkL2ZU5YfhBPkvLewarwKCqx94fk=; b=QwhqNnAymqG7Td3X4qiiPNsIP8wZGT4skfHMbYts0OcTPvvFjeRSg4uQ O9V0AfNEy3P7z5YLKedLmdrWPk6Sm40LbKmAqSkqKEmEgN3OK4Wb18aVQ DqSCt3ck+yGBG72CiGV0AY867B5g+jiAQhSxbmjeNwiyYN7hYpRtsYO/x M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwBAG0KFE5Io8UT/2dsb2JhbABTmFVCjnJ3rmOeMoY2BIdEj3+LQQ X-IronPort-AV: E=Sophos;i="4.65,484,1304294400"; d="scan'208";a="99857770" Received: from bgl-core-4.cisco.com ([72.163.197.19]) by ams-iport-1.cisco.com with ESMTP; 06 Jul 2011 07:14:19 +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 p667EJRW015820 for ; Wed, 6 Jul 2011 07:14:19 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Jul 2011 12:44: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, 6 Jul 2011 12:44:17 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD06E358B8@XMB-BGL-417.cisco.com> In-reply-to: <20110706070844.22445.30989.idtracker@ietfa.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] I-D Action: draft-ietf-siprec-metadata-02.txt Thread-Index: Acw7q5bK38sjpKMyRkK6ASMjVss1egAAB4rA References: <20110706070844.22445.30989.idtracker@ietfa.amsl.com> From: "Ram Mohan R (rmohanr)" To: X-OriginalArrivalTime: 06 Jul 2011 07:14:19.0001 (UTC) FILETIME=[526A3E90:01CC3BAC] Cc: "Paul Kyzivat \(pkyzivat\)" Subject: Re: [siprec] I-D Action: draft-ietf-siprec-metadata-02.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 07:14:26 -0000 Hello All, I have posted the ver 02 of metadata draft. It has the changes that were agreed in last interim (refer mail-thread) incorporated http://www.ietf.org/mail-archive/web/siprec/current/msg02173.html Also we have merged the format draft(individual) to the metadata draft (IETF draft) after the consensus http://www.ietf.org/mail-archive/web/siprec/current/msg02154.html Please review the metadata draft at http://www.ietf.org/id/draft-ietf-siprec-metadata-02.txt and provide your valuable comments. Regards, Ram > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of internet-drafts@ietf.org > Sent: Wednesday, July 06, 2011 12:39 PM > To: i-d-announce@ietf.org > Cc: siprec@ietf.org > Subject: [siprec] I-D Action: draft-ietf-siprec-metadata-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 > Title : Session Initiation Protocol (SIP) Recording > Metadata > Author(s) : Ram Mohan Ravindranath > Parthasarathi Ravindran > Paul Kyzivat > Filename : draft-ietf-siprec-metadata-02.txt > Pages : 34 > Date : 2011-07-06 >=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 session > is typically performed by sending a copy of a media stream to a > recording device. This document describes the metadata model as > viewed by Session Recording Server(SRS) and the Recording metadata > format. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-siprec-metadata-02.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-ietf-siprec-metadata-02.txt > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From rmohanr@cisco.com Wed Jul 6 00:33: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 1C75721F86BA for ; Wed, 6 Jul 2011 00:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 tagged_above=-999 required=5 tests=[AWL=-0.200, 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 mX3BmYX4Ow12 for ; Wed, 6 Jul 2011 00:33:22 -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 DCC3321F8513 for ; Wed, 6 Jul 2011 00:33:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=21276; q=dns/txt; s=iport; t=1309937601; x=1311147201; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=6XTlqPk59XGp6b0LRvv6USX2+wvKj5EUMy+F2RmdT8k=; b=gUWUPYSqVhkX1r5ntuQzbRBReTbsQVDwTPMHGsqlLKg5jtKRjlJ/WBoR K+VGaXby5XT02EP5fojyK4LJ9tIH/hpWU6Dx6qhfvH48ET5huMYVeL8Oc FPE5TR78iyo8j8fFo3EPWFi8sGdAaNYA2blxmFMt1PpOErrcN4ri+Z05i U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8AABEPFE5Io8UR/2dsb2JhbABTmFWPMneIeqVnnjSGNgSHRI9/i0E X-IronPort-AV: E=Sophos;i="4.65,484,1304294400"; d="scan'208";a="99861069" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-1.cisco.com with ESMTP; 06 Jul 2011 07:33:18 +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 p667XHrG007611; Wed, 6 Jul 2011 07:33:17 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Jul 2011 13:03: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: Wed, 6 Jul 2011 13:03:11 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD06E358D2@XMB-BGL-417.cisco.com> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Content (RFC 4796) attribute in SDP or XML Thread-Index: Acw0mPHhxfeVJEDcQLSYWo3IAZGl7wABDbXgACpfOfAADTnVAAA/CH7wAL12yxAADByJIAAdm3FgAADcErAAQaGFkAAC7JoQAAMpvCAAAObikAAasOngAAJiC3A= References: <07465C1D981ABC41A344374066AE1A2C38AF6D40CC@TLVMBX01.nice.com><07465C1D981ABC41A344374066AE1A2C38AF6D4376@TLVMBX01.nice.com><07465C1D981ABC41A344374066AE1A2C38AFE9B1C0@TLVMBX01.nice.com> From: "Ram Mohan R (rmohanr)" To: "Elwell, John" , "Parthasarathi R (partr)" , "Charles Eckel (eckelcu)" , "Leon Portman" , X-OriginalArrivalTime: 06 Jul 2011 07:33:17.0179 (UTC) FILETIME=[F8D26CB0:01CC3BAE] Subject: Re: [siprec] Content (RFC 4796) attribute in SDP or XML X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 07:33:24 -0000 Just on this one > RS media stream is a mixed content type stream of "current=20 > speaker video" and "room video" and the resultant shall be named as=20 > "mixed current speaker video & room video" which shall be passed as=20 > new content type extension to SRS [JRE] Right, so you agree this can't be passed in the RS SDP. I would challenge the need to define (and register) a new RFC 4796 value "mixed current speaker video & room video". We have two MS elements (representing the two CS video streams for current speaker and room. Why can't we just place the respective RFC 4796 content types in the respective MS elements? And why does it need to be as extension data - why can't it be standardized from day one? My thought here is since we have new content types "mixed current speaker video & room video" we need to register/extend RFC 4796 for the same and send in RS SDP. I would prefer this approach instead of sending it through recording metadata XML. Of course we need to discuss this in AVT to get their opinion. Regards, Ram > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Elwell, John > Sent: Wednesday, July 06, 2011 12:05 PM > To: Parthasarathi R (partr); Charles Eckel (eckelcu); Leon Portman; > siprec@ietf.org > Subject: Re: [siprec] Content (RFC 4796) attribute in SDP or XML >=20 >=20 >=20 > > -----Original Message----- > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > Sent: 05 July 2011 19:06 > > To: Charles Eckel (eckelcu); Leon Portman; Elwell, John; > > siprec@ietf.org > > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML > > > > John, > > > > Please read inline. > > > > Thanks > > Partha > > > > > -----Original Message----- > > > From: Charles Eckel (eckelcu) > > > Sent: Tuesday, July 05, 2011 10:44 PM > > > To: Leon Portman; Elwell, John; Parthasarathi R (partr); > > > siprec@ietf.org > > > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML > > > > > > Okay by me. > > > > > > Cheers, > > > Charles > > > > > > > -----Original Message----- > > > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > > > Sent: Tuesday, July 05, 2011 8:42 AM > > > > To: Elwell, John; Parthasarathi R (partr); Charles Eckel > > (eckelcu); > > > > siprec@ietf.org > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML > > > > > > > > I completely agree with the below. > > > > > > > > Leon > > > > > > > > -----Original Message----- > > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > Sent: Tuesday, July 05, 2011 5:44 PM > > > > To: Parthasarathi R (partr); Leon Portman; Charles Eckel > > (eckelcu); > > > > siprec@ietf.org > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML > > > > > > > > (as chair) > > > > We should try to avoid opening up old issues. I think we > > > had agreed that: > > > > - RS SDP describes the RS, and therefore just describes how > > > recordable media is delivered to the SRS. > > > > It does not describe how media is delivered between CS > > > endpoints as part of the CS. > > > > - Therefore anything to do with the CS (i.e., the session being > > > > recorded) needs to be delivered to the SRS as metadata > > > (i.e., in XML). > > > > - We don't see a need to standardize delivery of things > > > like CS codecs > > > > in the metadata, but that could be done using the extension > > > mechanism. > > > > > > Hope everyone agree here that CS SDP information could be > > passed as extension-data. attribute within > > may help to achieve this requirement. > [JRE] Or even as the standardized part of an MS element if we wish. >=20 > > > > > > Focusing now on the content attribute, I don't think there is any > > > > disagreement that the SRS needs to know the content type (e.g., > > > > presentation) of a media stream. The SRC can obtain this from the > > > > a=3Dcontent attribute of the CS SDP. The discussion is about > > > whether this content attribute should be conveyed to the SRS: > > > > A) as an a=3Dcontent attribute of the RS SDP, or > > > > B) within the metadata XML. > > > > > > > > (as individual) > > > > According to past decisions, there is perhaps an argument > > > for B). If, > > > > for example, we wanted to convey the fact that a CS media > > > stream was > > > > subject to 256-bit encryption, this information would go > > in the XML > > > > Here I have the doubt. In case 256-bit encryption is not > used > > by RS SDP, Please let me know the reason for passing the key > > information > > to SRS because RS SDP is not encrypted in that fashion. > [JRE] I did not suggest passing the CS keying material to the SRS. I > just suggested passing the information that the CS media stream used > 256 bit encryption. Perhaps this was a bad example - it was just meant > to illustrate the general principle that information about the CS > should be passed in metadata XML. >=20 > > > > > > (it can't go in the RS SDP, because the RS might not use > > > 256-bit encryption. Similarly, one could argue that the > > > content type of a CS media stream should go in the XML, not > > > in the RS SDP. > > I'm seeing content-type attribute as one of the extension of > > SDP a=3D attribute. In general, it is possible to convert CS > mediastream > > content type to RS media stream content type because SRC RS > > media stream > > is formed based on CS media stream except for the mixing scenarios > > > > > > > > > > > > I could even imagine cases where the content type of a CS > > > media stream > > > > does not equal the content type of an RS media stream, > > > e.g., where the > > > > SRC combines the current speaker video and the room video > > into two > > > > videos side-by-side in the same RS media stream. > > > > RS media stream is a mixed content type stream of "current > > speaker video" and "room video" and the resultant shall be named as > > "mixed current speaker video & room video" which shall be > > passed as new > > content type extension to SRS > [JRE] Right, so you agree this can't be passed in the RS SDP. I would > challenge the need to define (and register) a new RFC 4796 value "mixed > current speaker video & room video". We have two MS elements > (representing the two CS video streams for current speaker and room. > Why can't we just place the respective RFC 4796 content types in the > respective MS elements? And why does it need to be as extension data - > why can't it be standardized from day one? >=20 > John (as individual) >=20 > > > > In the > > > metadata these would be two media streams, each with its own > > > content type, but both would refer to the same RS media stream. > > > > > > It will be problematic approach because the actual media and > > metadata are not related explicitly. As per the current description, > > there are two element with different unique-id uses > > same label > > in SDP with different XML element ("content-type") within them. The > > issue is whether media has stream1 behavior or stream2 behavior or > > mixed. We will able to extent XML element for having single > > interpretation but it is not fully clarified in the draft now. The > > bottom-up matching like stream1 & stream2 has same label > > element and it > > has to be grouped together is not explicit in this scenario. We need > > more investigation both information is required but not the actual > > media. Please correct me in I'm missing something > > > > > > John > > > > > > > > > > > > > -----Original Message----- > > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > > Sent: 04 July 2011 08:08 > > > > > To: Leon Portman; Charles Eckel (eckelcu); Elwell, John; > > > > > siprec@ietf.org > > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or > XML > > > > > > > > > > Leon, > > > > > > > > > > Please read inline. > > > > > > > > > > Thanks > > > > > Partha > > > > > > > > > > > -----Original Message----- > > > > > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > > > > > Sent: Monday, July 04, 2011 12:11 PM > > > > > > To: Parthasarathi R (partr); Charles Eckel (eckelcu); Elwell, > > > > > > John; siprec@ietf.org > > > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in > > SDP or XML > > > > > > > > > > > > Partha Hi > > > > > > > > > > > > Please see below. > > > > > > > > > > > > Leon > > > > > > > > > > > > -----Original Message----- > > > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > > > Sent: Sunday, July 03, 2011 7:50 PM > > > > > > To: Leon Portman; Charles Eckel (eckelcu); Elwell, John; > > > > > > siprec@ietf.org > > > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in > > SDP or XML > > > > > > > > > > > > Leon, > > > > > > > > > > > > Please read inline. > > > > > > > > > > > > Thanks > > > > > > Partha > > > > > > > > > > > > -----Original Message----- > > > > > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > > > > > Sent: Sunday, July 03, 2011 4:13 PM > > > > > > To: Charles Eckel (eckelcu); Elwell, John; Parthasarathi R > > > > > > (partr); siprec@ietf.org > > > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in > > SDP or XML > > > > > > > > > > > > I do prefer that metadata XML will be as self-contained as > > > > > > possible and not rely on conveying some data via RS > > SDP. RS SDP > > > > > > should only be used to recording establishment and > > > negotiation and > > > > > > not as a mechanism for metadata reporting. > > > > > > > > > > > > In case Metadata XML has to be self-contained, the > > > > > > complete SDP has to be converted into XML format or > > > else XML has > > > > > > to have sort of XML attribute which carries SDP. > > > > > > Creating mapping for each SDP attribute with metadata > > > XML element > > > > > > does not seems to be feasible > > > > > > > > > > > > [LeonP] But if CS SDP is different from RS SDP, > > anyway you will > > > > > > need to encapsulate the original RS SDP, so why not in XML? > > > > > > > > > > I guess that the confusion is here. In the > > > current format, > > > > > RS SDP is only carried towards SRS and CS SDP is not forwarded. > > > > > This design > > > > > is closed as part of ticket #71 > > > > > > > > (http://www.ietf.org/mail- > archive/web/siprec/current/msg02106.html). > > > > > Please bring up with the usecase for CS SDP if required > > > > > > > > > > > > > > > > > > > Otherwise we will not be able to reuse same format for > > > reporting > > > > > > metadata via web services As per IETF-80 and > > > last interim > > > > > > meeting, there is no intent of reusing this metadata > > > XML in other > > > > > > protocol. In case reusing same format for webservice > > or XMPP is > > > > > > the intent, the current metadata XML mechanism is not > > > the appropriate. > > > > > > This was discussed in > > > > > > > > > http://www.ietf.org/mail-archive/web/siprec/current/msg02151.html, > > > > > > > > > > > > > > http://www.ietf.org/mail- > archive/web/siprec/current/msg02155.html(1s > > > > > t > > > > > > point in format slide). In case you have difference > > of opinion > > > > > > even after this multiple discussion, let us again > > > discuss at IETF-81. > > > > > > > > > > > > > > > > > > [LeonP] I was not proposing replacing SIP with another > > > transport > > > > > > layer, just wanted to keep other options open. > > > > > > > > > > Current metadata format is customized for SIP > > > transport. In > > > > > case we need to keep the options open, the format has to be > > > > > revisited from the scratch. In our analysis, we notice > > that REST > > > > > architecture with Metadata XML is best fit for HTTP, XMPP > > > > > > > > > > > > > I am > > > > > > very big supporter for metadata over SIP reporting > > > > > > > > > > > Thanks, Me too.. > > > > > > > > > > > or as dedicated SIP session. > > > > > > In case Metadata is separate session from RS, RS > > > > > > attribute like RS-id MUST be included within XML. This was > > > > > > discussed at > > > > > > http://www.ietf.org/mail- > archive/web/siprec/current/msg02013.h > > > > > tml. Could you please explain reason for the dedicated > > > SIP > session > > > > > for metadata. > > > > > > > > > > > > > > > > > > [LeonP] The main use case is Recording on Demand, that is > > > > > > triggered by SRS. In such case it will be very useful > > > to have just > > > > > > one SIP session and send all metadata over it (like CTI > > > > > > link) and then only trigger recording (via external SRC > > > > > > interface) only for specific call segments. > > > > > > > > > > > I understand the current implementation wherein > > > few of the > > > > > metadata like CDR records is passed through non-sip > > > interface. It is > > > > > outside the scope of SIPREC. The global-id in format > > > shall be used > > > > > to correlate. Please let me know in case any current > > > SIPREC metadata > > > > > attribute MUST be passed through this CTS link. > > > > > > > > > > > As for examples, the basic information as media type, labels, > > > > > > volume etc. Any application level data can be relevant. Even > > > > > > indication of encryption (for a case where RS is not > > encrypted) > > > > > > > > > > > > Leon > > > > > > > > > > > > -----Original Message----- > > > > > > From: siprec-bounces@ietf.org > > > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Charles Eckel > > > > > (eckelcu) > > > > > > Sent: Wednesday, June 29, 2011 7:17 PM > > > > > > To: Elwell, John; Parthasarathi R (partr); siprec@ietf.org > > > > > > Subject: Re: [siprec] Content (RFC 4796) attribute in > > SDP or XML > > > > > > > > > > > > I think it is sufficient, especially since we can assign new > > > > > > values if necessary. > > > > > > Are there any examples of what people think they > > might want to > > > > > > capture in the SDP and/or metadata field? > > > > > > > > > > > > Cheers, > > > > > > Charles > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: siprec-bounces@ietf.org > > > [mailto:siprec-bounces@ietf.org] > > > > > > > On > > > > > > Behalf Of Elwell, John > > > > > > > Sent: Tuesday, June 28, 2011 3:11 AM > > > > > > > To: Parthasarathi R (partr); siprec@ietf.org > > > > > > > Subject: Re: [siprec] Content (RFC 4796) attribute in > > > SDP or XML > > > > > > > > > > > > > > I would like other opinions on whether the SDP a=3Dcontent > > > > > > attribute in > > > > > > the RS SDP has the correct > > > > > > > semantics for representing the content type of the > > > > > recorded CS media > > > > > > stream. > > > > > > > > > > > > > > John > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > > > > > Sent: 28 June 2011 10:45 > > > > > > > > To: Elwell, John; siprec@ietf.org > > > > > > > > Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > > > > > > > Subject: RE: Content (RFC 4796) attribute in SDP or XML > > > > > > > > > > > > > > > > John, > > > > > > > > > > > > > > > > In case if it is the argument of whether CS MS content > > > > > > type or RS MS > > > > > > > > > > > > > > content type in the metadata, it is better for us to > > > > > > re-open ticket > > > > > > > > #71 > > > > > > > > > > > > > > > > > (http://www.ietf.org/mail- > archive/web/siprec/current/msg02106.html). > > > > > > > > Please let me know your opinion here. > > > > > > > > > > > > > > > > The basic idea in metadata format is to re-use as > > > much as SDP > > > > > > > > attribute (like direction, content) in media level for > > > > > RS dialog > > > > > > > > (using SDP label attribute as a pointer) until otherwise > > > > > > there is a > > > > > > > > restriction in using in such manner. As per RFC 4796, > > > > > there is no > > > > > > > > such restriction and so, I prefer to reuse as content SDP > > > > > > attribute > > > > > > > > rather than introducing the new > > element for > > > > > > > > this purpose. > > > > > > > > > > > > > > > > Thanks > > > > > > > > Partha > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Elwell, John > > > [mailto:john.elwell@siemens-enterprise.com] > > > > > > > > Sent: Monday, June 27, 2011 1:18 PM > > > > > > > > To: Parthasarathi R (partr); siprec@ietf.org > > > > > > > > Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > > > > > > > Subject: RE: Content (RFC 4796) attribute in SDP or XML > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > > > > > > Sent: 27 June 2011 08:08 > > > > > > > > > To: siprec@ietf.org; Elwell, John > > > > > > > > > Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > > > > > > > > Subject: Content (RFC 4796) attribute in SDP or XML > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > As per the last interim SIPREC meeting, there is a > > > > > consensus to > > > > > > > > > describe the content of an MS using RFC 4796 & its > > > > > > > > extension. As per > > > > > > > > > RFC 4796, the multiple instance of content attribute > > > > > is possible > > > > > > to > > > > > > > > > exist in SDP which shall be used in RS SDP. SRS > > > shall group > > > > > > > > the same > > > > > > > > > media content types by "content" attribute in RS > > > SDP. We are > > > > > > > > > interested in knowing any specfic reason for this > > > > > > attribute to be > > > > > > > > > duplicated in Metadata XML. > > > > > > > > [JRE] I don't have a reason for **duplication**. > > > > > However, I think > > > > > > > > there is a valid question to be asked whether the content > > > > > > type of an > > > > > > > > > > > > > > MS should be represented: > > > > > > > > A) in XML; or > > > > > > > > B) in RS SDP as a=3Dcontent. > > > > > > > > > > > > > > > > The content type we are talking about is an MS content > > > > > > type, i.e., > > > > > > > > relating to the CS. One could argue that the > > > > > > corresponding RS stream > > > > > > > > > > > > > > is NOT the same content type. For example: > > > > > > > > - CS MS content type is "slides". > > > > > > > > - RS media stream content type is "recording of slides". > > > > > > > > > > > > > > > > On this basis, I think the correct option for > > > conveying the MS > > > > > > content > > > > > > > > type "slides" is A) (in the XML). > > > > > > > > > > > > > > > > Note that this would not involve duplication. The SDP > > > > > > > > a=3Dcontent attribute is optional, so we need not use > > > it for the RS. > > > > > > > > > > > > > > > > Perhaps my distinction is too theoretical, but I do > > > > > feel a little > > > > > > more > > > > > > > > comfortable using the XML rather than the RS SDP. > > > > > > > > > > > > > > > > John (as individual) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > Partha > > > > > > > > > > > > > > > > > > last Interim SIPREC meeting Note: > > > > > > > > > > > > > > > > > > Slide 7: On the question of how to describe the content > > > > > > of an MS, > > > > > > > > > there was no objection to basing this on the types in > > > > > > the RFC 4796 > > > > > > > > > > > > > > > registry (new values could be specified via the > > > appropriate > > > > > > > > means if > > > > > > > > > needed). Paul had a slight concern that you might > > > be mixing > > > > > > > > multiple > > > > > > > > > CS MSs into a single RS media stream and whether > > > this might > > > > > > > > result in > > > > > > > > > cases not describable in this way, but in the end > > > > > accepted the > > > > > > > > > consensus. It needs to be discussed on the list > > > > > whether this is > > > > > > > > > conveyed in XML or in the RS SDP a=3Dcontent = attribute. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > siprec mailing list > > > > > > > siprec@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > _______________________________________________ > > > > > > siprec mailing 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 Jul 6 05:59: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 D66E021F867B for ; Wed, 6 Jul 2011 05:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.412 X-Spam-Level: X-Spam-Status: No, score=-106.412 tagged_above=-999 required=5 tests=[AWL=0.188, 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 XdEhvVT+DG3y for ; Wed, 6 Jul 2011 05:59:01 -0700 (PDT) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfa.amsl.com (Postfix) with SMTP id E3B6221F8676 for ; Wed, 6 Jul 2011 05:59:00 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1309957133!28901935!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 26576 invoked from network); 6 Jul 2011 12:58:53 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-11.tower-27.messagelabs.com with SMTP; 6 Jul 2011 12:58:53 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 74DA61EB83EF for ; Wed, 6 Jul 2011 14:58:59 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 6 Jul 2011 14:58:59 +0200 From: "Elwell, John" To: "siprec@ietf.org" Date: Wed, 6 Jul 2011 14:58:58 +0200 Thread-Topic: [siprec] I-D Action: draft-ietf-siprec-metadata-02.txt Thread-Index: Acw7q5bK38sjpKMyRkK6ASMjVss1egAAB4rAAAwLQrA= Message-ID: References: <20110706070844.22445.30989.idtracker@ietfa.amsl.com> <35BCE99A477D6A4986FB2216D8CF2CFD06E358B8@XMB-BGL-417.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD06E358B8@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] I-D Action: draft-ietf-siprec-metadata-02.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 12:59:01 -0000 Thanks to the editors for doing this merge. Now that we have all the metadata material together in one draft, it would = be an excellent time for folks to give it a careful read and get discussion= going on the list, so that we can identify key issues for the session in Q= uebec. Also, can the editors / authors of all the drafts let me know their require= ments for agenda slots? John =20 > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Ram Mohan R (rmohanr) > Sent: 06 July 2011 08:14 > To: siprec@ietf.org > Cc: Paul Kyzivat (pkyzivat) > Subject: Re: [siprec] I-D Action: draft-ietf-siprec-metadata-02.txt >=20 > Hello All, >=20 > I have posted the ver 02 of metadata draft. It has the=20 > changes that were > agreed in last interim (refer mail-thread) incorporated > http://www.ietf.org/mail-archive/web/siprec/current/msg02173.html >=20 > Also we have merged the format draft(individual) to the metadata draft > (IETF draft) after the consensus > http://www.ietf.org/mail-archive/web/siprec/current/msg02154.html >=20 > Please review the metadata draft at > http://www.ietf.org/id/draft-ietf-siprec-metadata-02.txt and provide > your valuable comments. >=20 > Regards, > Ram >=20 >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of internet-drafts@ietf.org > > Sent: Wednesday, July 06, 2011 12:39 PM > > To: i-d-announce@ietf.org > > Cc: siprec@ietf.org > > Subject: [siprec] I-D Action: draft-ietf-siprec-metadata-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 > > Title : Session Initiation Protocol (SIP) Recording > > Metadata > > Author(s) : Ram Mohan Ravindranath > > Parthasarathi Ravindran > > Paul Kyzivat > > Filename : draft-ietf-siprec-metadata-02.txt > > Pages : 34 > > Date : 2011-07-06 > >=20 > > Session recording is a critical requirement in many=20 > communications > > environments such as call centers and financial trading. In some > of > > these environments, all calls must be recorded for regulatory, > > compliance, and consumer protection reasons. Recording of a > session > > is typically performed by sending a copy of a media stream to a > > recording device. This document describes the metadata model as > > viewed by Session Recording Server(SRS) and the=20 > Recording metadata > > format. > >=20 > >=20 > > A URL for this Internet-Draft is: > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-siprec-metadata-02.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-ietf-siprec-metadata-02.txt > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > = From eckelcu@cisco.com Wed Jul 6 13:05: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 0494D21F8AE4 for ; Wed, 6 Jul 2011 13:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.074 X-Spam-Level: X-Spam-Status: No, score=-10.074 tagged_above=-999 required=5 tests=[AWL=-0.075, 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 IDj3QbfOIE7N for ; Wed, 6 Jul 2011 13:05:10 -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 4AFFC21F8ACC for ; Wed, 6 Jul 2011 13:05:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=24067; q=dns/txt; s=iport; t=1309982710; x=1311192310; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=gCrs16dG4lvcP5v6DDVdFfSwUVZBUyRHSFVNAJzDQsw=; b=O6erj0B3NZExjJwo8Q8BtSW9oMrOxZ4XGxtrbB6bbf92YuADL3N23mld 9Kesgh7nhItGYGD+vO8InyhRI8fNoqhCUGGZG/Sb/VAQEPLq9kH55RlBz lrg/rTSt3Zo0f8/0Am6vrbg6GgmA1G37LIKE3uvmVlFSASPdgJZP9Cbaq w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvIAAKS/FE6rRDoG/2dsb2JhbABTmFqPLneIeqUangmGNwSHRo9+i1o X-IronPort-AV: E=Sophos;i="4.65,488,1304294400"; d="scan'208";a="362649477" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-5.cisco.com with ESMTP; 06 Jul 2011 20:05:07 +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 p66K57Bc024046; Wed, 6 Jul 2011 20:05:07 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, 6 Jul 2011 13:05:07 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Jul 2011 13:05:05 -0700 Message-ID: In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD06E358D2@XMB-BGL-417.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [siprec] Content (RFC 4796) attribute in SDP or XML thread-index: Acw0mPHhxfeVJEDcQLSYWo3IAZGl7wABDbXgACpfOfAADTnVAAA/CH7wAL12yxAADByJIAAdm3FgAADcErAAQaGFkAAC7JoQAAMpvCAAAObikAAasOngAAJiC3AAGcWykA== References: <07465C1D981ABC41A344374066AE1A2C38AF6D40CC@TLVMBX01.nice.com><07465C1D981ABC41A344374066AE1A2C38AF6D4376@TLVMBX01.nice.com><07465C1D981ABC41A344374066AE1A2C38AFE9B1C0@TLVMBX01.nice.com> <35BCE99A477D6A4986FB2216D8CF2CFD06E358D2@XMB-BGL-417.cisco.com> From: "Charles Eckel (eckelcu)" To: "Ram Mohan R (rmohanr)" , "Elwell, John" , "Parthasarathi R (partr)" , "Leon Portman" , X-OriginalArrivalTime: 06 Jul 2011 20:05:07.0383 (UTC) FILETIME=[00994C70:01CC3C18] Subject: Re: [siprec] Content (RFC 4796) attribute in SDP or XML X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 20:05:12 -0000 RFC 4796 has registered the following values: slides RFC 4796 Presentation slides speaker RFC 4796 Image from the speaker sl RFC 4796 Sign language main RFC 4796 Main media stream alt RFC 4796 Alternative media stream Suppose we register the following new values: siprec1 RFC xxxx SIPREC value 1 siprec2 RFC xxxx SIPREC value 2 siprec3 RFC xxxx SIPREC value 3 If the CS has a media lines with the following content attributes CS MS1 - slides CS MS2 - main CS MS3 - siprec1 CS MS4 - siprec2 SRC sends two media streams to RS. RS MS1 is essentially CS MS1. RS MS2 is some composition of CS MS2, CS MS3 and CS MS4. This could be represented using the content attribute as: RS MS1 - slides RS MS2 - main, siprec1, siprec2 If this is all we think is required, using the content attribute does seem sufficient. However, my understanding is people want to be able to convey something other than the simple concatenation of content attribute values, and for that reason, prefer to use XML. In this case, the desired set of values is not bound by anything we will define in SIPREC. That is my understanding as to why XML is preferred over the RFC 4796 content attribute. Cheers, Charles > -----Original Message----- > From: Ram Mohan R (rmohanr) > Sent: Wednesday, July 06, 2011 12:33 AM > To: Elwell, John; Parthasarathi R (partr); Charles Eckel (eckelcu); Leon Portman; siprec@ietf.org > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML >=20 > Just on this one >=20 > > RS media stream is a mixed content type stream of "current > > speaker video" and "room video" and the resultant shall be named as > > "mixed current speaker video & room video" which shall be passed as > > new content type extension to SRS > [JRE] Right, so you agree this can't be passed in the RS SDP. I would challenge the need to define > (and register) a new RFC 4796 value "mixed current speaker video & room video". We have two MS > elements (representing the two CS video streams for current speaker and room. Why can't we just place > the respective RFC 4796 content types in the respective MS elements? And why does it need to be as > extension data - why can't it be standardized from day one? >=20 > My thought here is since we have new content types "mixed current speaker video & room video" we need > to register/extend RFC 4796 for the same and send in RS SDP. I would prefer this approach instead of > sending it through recording metadata XML. Of course we need to discuss this in AVT to get their > opinion. >=20 > Regards, > Ram >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Elwell, John > > Sent: Wednesday, July 06, 2011 12:05 PM > > To: Parthasarathi R (partr); Charles Eckel (eckelcu); Leon Portman; > > siprec@ietf.org > > Subject: Re: [siprec] Content (RFC 4796) attribute in SDP or XML > > > > > > > > > -----Original Message----- > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > Sent: 05 July 2011 19:06 > > > To: Charles Eckel (eckelcu); Leon Portman; Elwell, John; > > > siprec@ietf.org > > > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML > > > > > > John, > > > > > > Please read inline. > > > > > > Thanks > > > Partha > > > > > > > -----Original Message----- > > > > From: Charles Eckel (eckelcu) > > > > Sent: Tuesday, July 05, 2011 10:44 PM > > > > To: Leon Portman; Elwell, John; Parthasarathi R (partr); > > > > siprec@ietf.org > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML > > > > > > > > Okay by me. > > > > > > > > Cheers, > > > > Charles > > > > > > > > > -----Original Message----- > > > > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > > > > Sent: Tuesday, July 05, 2011 8:42 AM > > > > > To: Elwell, John; Parthasarathi R (partr); Charles Eckel > > > (eckelcu); > > > > > siprec@ietf.org > > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML > > > > > > > > > > I completely agree with the below. > > > > > > > > > > Leon > > > > > > > > > > -----Original Message----- > > > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > > Sent: Tuesday, July 05, 2011 5:44 PM > > > > > To: Parthasarathi R (partr); Leon Portman; Charles Eckel > > > (eckelcu); > > > > > siprec@ietf.org > > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML > > > > > > > > > > (as chair) > > > > > We should try to avoid opening up old issues. I think we > > > > had agreed that: > > > > > - RS SDP describes the RS, and therefore just describes how > > > > recordable media is delivered to the SRS. > > > > > It does not describe how media is delivered between CS > > > > endpoints as part of the CS. > > > > > - Therefore anything to do with the CS (i.e., the session being > > > > > recorded) needs to be delivered to the SRS as metadata > > > > (i.e., in XML). > > > > > - We don't see a need to standardize delivery of things > > > > like CS codecs > > > > > in the metadata, but that could be done using the extension > > > > mechanism. > > > > > > > > Hope everyone agree here that CS SDP information could be > > > passed as extension-data. attribute within > > > may help to achieve this requirement. > > [JRE] Or even as the standardized part of an MS element if we wish. > > > > > > > > > > Focusing now on the content attribute, I don't think there is any > > > > > disagreement that the SRS needs to know the content type (e.g., > > > > > presentation) of a media stream. The SRC can obtain this from the > > > > > a=3Dcontent attribute of the CS SDP. The discussion is about > > > > whether this content attribute should be conveyed to the SRS: > > > > > A) as an a=3Dcontent attribute of the RS SDP, or > > > > > B) within the metadata XML. > > > > > > > > > > (as individual) > > > > > According to past decisions, there is perhaps an argument > > > > for B). If, > > > > > for example, we wanted to convey the fact that a CS media > > > > stream was > > > > > subject to 256-bit encryption, this information would go > > > in the XML > > > > > > Here I have the doubt. In case 256-bit encryption is not > > used > > > by RS SDP, Please let me know the reason for passing the key > > > information > > > to SRS because RS SDP is not encrypted in that fashion. > > [JRE] I did not suggest passing the CS keying material to the SRS. I > > just suggested passing the information that the CS media stream used > > 256 bit encryption. Perhaps this was a bad example - it was just meant > > to illustrate the general principle that information about the CS > > should be passed in metadata XML. > > > > > > > > > > (it can't go in the RS SDP, because the RS might not use > > > > 256-bit encryption. Similarly, one could argue that the > > > > content type of a CS media stream should go in the XML, not > > > > in the RS SDP. > > > I'm seeing content-type attribute as one of the extension of > > > SDP a=3D attribute. In general, it is possible to convert CS > > mediastream > > > content type to RS media stream content type because SRC RS > > > media stream > > > is formed based on CS media stream except for the mixing scenarios > > > > > > > > > > > > > > > > I could even imagine cases where the content type of a CS > > > > media stream > > > > > does not equal the content type of an RS media stream, > > > > e.g., where the > > > > > SRC combines the current speaker video and the room video > > > into two > > > > > videos side-by-side in the same RS media stream. > > > > > > RS media stream is a mixed content type stream of "current > > > speaker video" and "room video" and the resultant shall be named as > > > "mixed current speaker video & room video" which shall be > > > passed as new > > > content type extension to SRS > > [JRE] Right, so you agree this can't be passed in the RS SDP. I would > > challenge the need to define (and register) a new RFC 4796 value "mixed > > current speaker video & room video". We have two MS elements > > (representing the two CS video streams for current speaker and room. > > Why can't we just place the respective RFC 4796 content types in the > > respective MS elements? And why does it need to be as extension data - > > why can't it be standardized from day one? > > > > John (as individual) > > > > > > > > In the > > > > metadata these would be two media streams, each with its own > > > > content type, but both would refer to the same RS media stream. > > > > > > > > It will be problematic approach because the actual media and > > > metadata are not related explicitly. As per the current description, > > > there are two element with different unique-id uses > > > same label > > > in SDP with different XML element ("content-type") within them. The > > > issue is whether media has stream1 behavior or stream2 behavior or > > > mixed. We will able to extent XML element for having single > > > interpretation but it is not fully clarified in the draft now. The > > > bottom-up matching like stream1 & stream2 has same label > > > element and it > > > has to be grouped together is not explicit in this scenario. We need > > > more investigation both information is required but not the actual > > > media. Please correct me in I'm missing something > > > > > > > > John > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > > > Sent: 04 July 2011 08:08 > > > > > > To: Leon Portman; Charles Eckel (eckelcu); Elwell, John; > > > > > > siprec@ietf.org > > > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or > > XML > > > > > > > > > > > > Leon, > > > > > > > > > > > > Please read inline. > > > > > > > > > > > > Thanks > > > > > > Partha > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > > > > > > Sent: Monday, July 04, 2011 12:11 PM > > > > > > > To: Parthasarathi R (partr); Charles Eckel (eckelcu); Elwell, > > > > > > > John; siprec@ietf.org > > > > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in > > > SDP or XML > > > > > > > > > > > > > > Partha Hi > > > > > > > > > > > > > > Please see below. > > > > > > > > > > > > > > Leon > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > > > > Sent: Sunday, July 03, 2011 7:50 PM > > > > > > > To: Leon Portman; Charles Eckel (eckelcu); Elwell, John; > > > > > > > siprec@ietf.org > > > > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in > > > SDP or XML > > > > > > > > > > > > > > Leon, > > > > > > > > > > > > > > Please read inline. > > > > > > > > > > > > > > Thanks > > > > > > > Partha > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > > > > > > Sent: Sunday, July 03, 2011 4:13 PM > > > > > > > To: Charles Eckel (eckelcu); Elwell, John; Parthasarathi R > > > > > > > (partr); siprec@ietf.org > > > > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in > > > SDP or XML > > > > > > > > > > > > > > I do prefer that metadata XML will be as self-contained as > > > > > > > possible and not rely on conveying some data via RS > > > SDP. RS SDP > > > > > > > should only be used to recording establishment and > > > > negotiation and > > > > > > > not as a mechanism for metadata reporting. > > > > > > > > > > > > > > In case Metadata XML has to be self-contained, the > > > > > > > complete SDP has to be converted into XML format or > > > > else XML has > > > > > > > to have sort of XML attribute which carries SDP. > > > > > > > Creating mapping for each SDP attribute with metadata > > > > XML element > > > > > > > does not seems to be feasible > > > > > > > > > > > > > > [LeonP] But if CS SDP is different from RS SDP, > > > anyway you will > > > > > > > need to encapsulate the original RS SDP, so why not in XML? > > > > > > > > > > > > I guess that the confusion is here. In the > > > > current format, > > > > > > RS SDP is only carried towards SRS and CS SDP is not forwarded. > > > > > > This design > > > > > > is closed as part of ticket #71 > > > > > > > > > > (http://www.ietf.org/mail- > > archive/web/siprec/current/msg02106.html). > > > > > > Please bring up with the usecase for CS SDP if required > > > > > > > > > > > > > > > > > > > > > > > Otherwise we will not be able to reuse same format for > > > > reporting > > > > > > > metadata via web services As per IETF-80 and > > > > last interim > > > > > > > meeting, there is no intent of reusing this metadata > > > > XML in other > > > > > > > protocol. In case reusing same format for webservice > > > or XMPP is > > > > > > > the intent, the current metadata XML mechanism is not > > > > the appropriate. > > > > > > > This was discussed in > > > > > > > > > > > http://www.ietf.org/mail-archive/web/siprec/current/msg02151.html, > > > > > > > > > > > > > > > > > http://www.ietf.org/mail- > > archive/web/siprec/current/msg02155.html(1s > > > > > > t > > > > > > > point in format slide). In case you have difference > > > of opinion > > > > > > > even after this multiple discussion, let us again > > > > discuss at IETF-81. > > > > > > > > > > > > > > > > > > > > > [LeonP] I was not proposing replacing SIP with another > > > > transport > > > > > > > layer, just wanted to keep other options open. > > > > > > > > > > > > Current metadata format is customized for SIP > > > > transport. In > > > > > > case we need to keep the options open, the format has to be > > > > > > revisited from the scratch. In our analysis, we notice > > > that REST > > > > > > architecture with Metadata XML is best fit for HTTP, XMPP > > > > > > > > > > > > > > > > I am > > > > > > > very big supporter for metadata over SIP reporting > > > > > > > > > > > > > Thanks, Me too.. > > > > > > > > > > > > > or as dedicated SIP session. > > > > > > > In case Metadata is separate session from RS, RS > > > > > > > attribute like RS-id MUST be included within XML. This was > > > > > > > discussed at > > > > > > > http://www.ietf.org/mail- > > archive/web/siprec/current/msg02013.h > > > > > > tml. Could you please explain reason for the dedicated > > > > SIP > session > > > > > > for metadata. > > > > > > > > > > > > > > > > > > > > > [LeonP] The main use case is Recording on Demand, that is > > > > > > > triggered by SRS. In such case it will be very useful > > > > to have just > > > > > > > one SIP session and send all metadata over it (like CTI > > > > > > > link) and then only trigger recording (via external SRC > > > > > > > interface) only for specific call segments. > > > > > > > > > > > > > I understand the current implementation wherein > > > > few of the > > > > > > metadata like CDR records is passed through non-sip > > > > interface. It is > > > > > > outside the scope of SIPREC. The global-id in format > > > > shall be used > > > > > > to correlate. Please let me know in case any current > > > > SIPREC metadata > > > > > > attribute MUST be passed through this CTS link. > > > > > > > > > > > > > As for examples, the basic information as media type, labels, > > > > > > > volume etc. Any application level data can be relevant. Even > > > > > > > indication of encryption (for a case where RS is not > > > encrypted) > > > > > > > > > > > > > > Leon > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: siprec-bounces@ietf.org > > > > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Charles Eckel > > > > > > (eckelcu) > > > > > > > Sent: Wednesday, June 29, 2011 7:17 PM > > > > > > > To: Elwell, John; Parthasarathi R (partr); siprec@ietf.org > > > > > > > Subject: Re: [siprec] Content (RFC 4796) attribute in > > > SDP or XML > > > > > > > > > > > > > > I think it is sufficient, especially since we can assign new > > > > > > > values if necessary. > > > > > > > Are there any examples of what people think they > > > might want to > > > > > > > capture in the SDP and/or metadata field? > > > > > > > > > > > > > > Cheers, > > > > > > > Charles > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: siprec-bounces@ietf.org > > > > [mailto:siprec-bounces@ietf.org] > > > > > > > > On > > > > > > > Behalf Of Elwell, John > > > > > > > > Sent: Tuesday, June 28, 2011 3:11 AM > > > > > > > > To: Parthasarathi R (partr); siprec@ietf.org > > > > > > > > Subject: Re: [siprec] Content (RFC 4796) attribute in > > > > SDP or XML > > > > > > > > > > > > > > > > I would like other opinions on whether the SDP = a=3Dcontent > > > > > > > attribute in > > > > > > > the RS SDP has the correct > > > > > > > > semantics for representing the content type of the > > > > > > recorded CS media > > > > > > > stream. > > > > > > > > > > > > > > > > John > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > > > > > > Sent: 28 June 2011 10:45 > > > > > > > > > To: Elwell, John; siprec@ietf.org > > > > > > > > > Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > > > > > > > > Subject: RE: Content (RFC 4796) attribute in SDP or XML > > > > > > > > > > > > > > > > > > John, > > > > > > > > > > > > > > > > > > In case if it is the argument of whether CS MS content > > > > > > > type or RS MS > > > > > > > > > > > > > > > > content type in the metadata, it is better for us to > > > > > > > re-open ticket > > > > > > > > > #71 > > > > > > > > > > > > > > > > > > > > (http://www.ietf.org/mail- > > archive/web/siprec/current/msg02106.html). > > > > > > > > > Please let me know your opinion here. > > > > > > > > > > > > > > > > > > The basic idea in metadata format is to re-use as > > > > much as SDP > > > > > > > > > attribute (like direction, content) in media level for > > > > > > RS dialog > > > > > > > > > (using SDP label attribute as a pointer) until otherwise > > > > > > > there is a > > > > > > > > > restriction in using in such manner. As per RFC 4796, > > > > > > there is no > > > > > > > > > such restriction and so, I prefer to reuse as content SDP > > > > > > > attribute > > > > > > > > > rather than introducing the new > > > element for > > > > > > > > > this purpose. > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > Partha > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Elwell, John > > > > [mailto:john.elwell@siemens-enterprise.com] > > > > > > > > > Sent: Monday, June 27, 2011 1:18 PM > > > > > > > > > To: Parthasarathi R (partr); siprec@ietf.org > > > > > > > > > Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > > > > > > > > Subject: RE: Content (RFC 4796) attribute in SDP or XML > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > > > > > > > Sent: 27 June 2011 08:08 > > > > > > > > > > To: siprec@ietf.org; Elwell, John > > > > > > > > > > Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > > > > > > > > > Subject: Content (RFC 4796) attribute in SDP or XML > > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > > > As per the last interim SIPREC meeting, there is a > > > > > > consensus to > > > > > > > > > > describe the content of an MS using RFC 4796 & its > > > > > > > > > extension. As per > > > > > > > > > > RFC 4796, the multiple instance of content attribute > > > > > > is possible > > > > > > > to > > > > > > > > > > exist in SDP which shall be used in RS SDP. SRS > > > > shall group > > > > > > > > > the same > > > > > > > > > > media content types by "content" attribute in RS > > > > SDP. We are > > > > > > > > > > interested in knowing any specfic reason for this > > > > > > > attribute to be > > > > > > > > > > duplicated in Metadata XML. > > > > > > > > > [JRE] I don't have a reason for **duplication**. > > > > > > However, I think > > > > > > > > > there is a valid question to be asked whether the content > > > > > > > type of an > > > > > > > > > > > > > > > > MS should be represented: > > > > > > > > > A) in XML; or > > > > > > > > > B) in RS SDP as a=3Dcontent. > > > > > > > > > > > > > > > > > > The content type we are talking about is an MS content > > > > > > > type, i.e., > > > > > > > > > relating to the CS. One could argue that the > > > > > > > corresponding RS stream > > > > > > > > > > > > > > > > is NOT the same content type. For example: > > > > > > > > > - CS MS content type is "slides". > > > > > > > > > - RS media stream content type is "recording of slides". > > > > > > > > > > > > > > > > > > On this basis, I think the correct option for > > > > conveying the MS > > > > > > > content > > > > > > > > > type "slides" is A) (in the XML). > > > > > > > > > > > > > > > > > > Note that this would not involve duplication. The SDP > > > > > > > > > a=3Dcontent attribute is optional, so we need not use > > > > it for the RS. > > > > > > > > > > > > > > > > > > Perhaps my distinction is too theoretical, but I do > > > > > > feel a little > > > > > > > more > > > > > > > > > comfortable using the XML rather than the RS SDP. > > > > > > > > > > > > > > > > > > John (as individual) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > > > Partha > > > > > > > > > > > > > > > > > > > > last Interim SIPREC meeting Note: > > > > > > > > > > > > > > > > > > > > Slide 7: On the question of how to describe the content > > > > > > > of an MS, > > > > > > > > > > there was no objection to basing this on the types in > > > > > > > the RFC 4796 > > > > > > > > > > > > > > > > > registry (new values could be specified via the > > > > appropriate > > > > > > > > > means if > > > > > > > > > > needed). Paul had a slight concern that you might > > > > be mixing > > > > > > > > > multiple > > > > > > > > > > CS MSs into a single RS media stream and whether > > > > this might > > > > > > > > > result in > > > > > > > > > > cases not describable in this way, but in the end > > > > > > accepted the > > > > > > > > > > consensus. It needs to be discussed on the list > > > > > > whether this is > > > > > > > > > > conveyed in XML or in the RS SDP a=3Dcontent attribute. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > siprec mailing list > > > > > > > > siprec@ietf.org > > > > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > _______________________________________________ > > > > > > > siprec mailing list > > > > > > > siprec@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec From pkyzivat@alum.mit.edu Wed Jul 6 14:28: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 E3E0C21F8AE3 for ; Wed, 6 Jul 2011 14:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[AWL=0.402, 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 FUSnFxd51d14 for ; Wed, 6 Jul 2011 14:28:04 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by ietfa.amsl.com (Postfix) with ESMTP id 749DE21F8B11 for ; Wed, 6 Jul 2011 14:28:03 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta04.westchester.pa.mail.comcast.net with comcast id 4lS01h0010xGWP854lU3mW; Wed, 06 Jul 2011 21:28:03 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta12.westchester.pa.mail.comcast.net with comcast id 4lSz1h01K0tdiYw3YlTqpF; Wed, 06 Jul 2011 21:27:59 +0000 Message-ID: <4E14D321.1030902@alum.mit.edu> Date: Wed, 06 Jul 2011 17:26:57 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: siprec@ietf.org References: <07465C1D981ABC41A344374066AE1A2C38AF6D40CC@TLVMBX01.nice.com><07465C1D981ABC41A344374066AE1A2C38AF6D4376@TLVMBX01.nice.com><07465C1D981ABC41A344374066AE1A2C38AFE9B1C0@TLVMBX01.nice.com> <35BCE99A477D6A4986FB2216D8CF2CFD06E358D2@XMB-BGL-417.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] Content (RFC 4796) attribute in SDP or XML X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 21:28:06 -0000 On 7/6/11 4:05 PM, Charles Eckel (eckelcu) wrote: > RFC 4796 has registered the following values: > > slides RFC 4796 Presentation slides > speaker RFC 4796 Image from the speaker > sl RFC 4796 Sign language > main RFC 4796 Main media stream > alt RFC 4796 Alternative media stream > > Suppose we register the following new values: > > siprec1 RFC xxxx SIPREC value 1 > siprec2 RFC xxxx SIPREC value 2 > siprec3 RFC xxxx SIPREC value 3 I don't get it. What is the purpose of siprecN? I can perhaps see using a new value to indicate: this stream contains some content from a stream that failed to indicate what sort of content it contained. But you only need one value for that. Thanks, Paul > If the CS has a media lines with the following content attributes > > CS MS1 - slides > CS MS2 - main > CS MS3 - siprec1 > CS MS4 - siprec2 > > SRC sends two media streams to RS. RS MS1 is essentially CS MS1. RS MS2 > is some composition of CS MS2, CS MS3 and CS MS4. > This could be represented using the content attribute as: > > RS MS1 - slides > RS MS2 - main, siprec1, siprec2 > > If this is all we think is required, using the content attribute does > seem sufficient. However, my understanding is people want to be able to > convey something other than the simple concatenation of content > attribute values, and for that reason, prefer to use XML. In this case, > the desired set of values is not bound by anything we will define in > SIPREC. That is my understanding as to why XML is preferred over the RFC > 4796 content attribute. > > Cheers, > Charles From partr@cisco.com Wed Jul 6 22:05: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 DA4F421F899B for ; Wed, 6 Jul 2011 22:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.169 X-Spam-Level: X-Spam-Status: No, score=-10.169 tagged_above=-999 required=5 tests=[AWL=0.430, 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 IZX3OJBvL9qx for ; Wed, 6 Jul 2011 22:05:40 -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 E18CD21F87B0 for ; Wed, 6 Jul 2011 22:05:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=2823; q=dns/txt; s=iport; t=1310015139; x=1311224739; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=5IgUBuJaOJ3blBEPafLm6ZqfkxlEcCpROhb9Y3InUJk=; b=RLKpPB1MHZMU+BTTnCtpNz77XBIMM845PeU/CfOKoVVMIXWOCPZH1IBQ 4rxFLWqmc7Riig8HK2xkxmseqA/RXZKgVyMmzQdXNrjRnG2fv+xj5ukza HbYmqniSLJWTiQ1P65HiuUCFB7fcfsmJvU997fMoxcwzvRbOEmBUF4Bgv M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUBAIY9FU5Io8UT/2dsb2JhbABTEJhUjzN3iHulSJ19hjcEh0eQBYsEPw X-IronPort-AV: E=Sophos;i="4.65,491,1304294400"; d="scan'208";a="40951228" Received: from bgl-core-4.cisco.com ([72.163.197.19]) by ams-iport-2.cisco.com with ESMTP; 07 Jul 2011 05:05:37 +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 p6755ZC1025597; Thu, 7 Jul 2011 05:05:37 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Jul 2011 10:35:29 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Jul 2011 10:35:28 +0530 Message-ID: In-Reply-To: <4E14D321.1030902@alum.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Content (RFC 4796) attribute in SDP or XML Thread-Index: Acw8I597SxHKkCVXTs+cYW+H/m4zLwAMTkkg References: <07465C1D981ABC41A344374066AE1A2C38AF6D40CC@TLVMBX01.nice.com><07465C1D981ABC41A344374066AE1A2C38AF6D4376@TLVMBX01.nice.com><07465C1D981ABC41A344374066AE1A2C38AFE9B1C0@TLVMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD06E358D2@XMB-BGL-417.cisco.com> <4E14D3 21.1030902@alum.mit.edu> From: "Parthasarathi R (partr)" To: "Paul Kyzivat" , X-OriginalArrivalTime: 07 Jul 2011 05:05:29.0450 (UTC) FILETIME=[7DA81CA0:01CC3C63] Subject: Re: [siprec] Content (RFC 4796) attribute in SDP or XML X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 05:05:41 -0000 Hi all, Please read inline Thanks Partha=20 > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Thursday, July 07, 2011 2:57 AM > To: siprec@ietf.org > Subject: Re: [siprec] Content (RFC 4796) attribute in SDP or XML >=20 > On 7/6/11 4:05 PM, Charles Eckel (eckelcu) wrote: > > RFC 4796 has registered the following values: > > > > slides RFC 4796 Presentation slides > > speaker RFC 4796 Image from the speaker > > sl RFC 4796 Sign language > > main RFC 4796 Main media stream > > alt RFC 4796 Alternative media stream > > > > Suppose we register the following new values: > > > > siprec1 RFC xxxx SIPREC value 1 > > siprec2 RFC xxxx SIPREC value 2 > > siprec3 RFC xxxx SIPREC value 3 >=20 > I don't get it. What is the purpose of siprecN? I guess that new values for the different mixed stream like side-by-side video & active user video, speaker + Slides, etc... >=20 > I can perhaps see using a new value to indicate: this stream=20 > contains some content from a stream that failed to indicate=20 > what sort of content it contained. But you only need one=20 > value for that. >=20 > Thanks, > Paul >=20 > > If the CS has a media lines with the following content attributes > > > > CS MS1 - slides > > CS MS2 - main > > CS MS3 - siprec1 > > CS MS4 - siprec2 > > > > SRC sends two media streams to RS. RS MS1 is essentially CS MS1. RS=20 > > MS2 is some composition of CS MS2, CS MS3 and CS MS4. > > This could be represented using the content attribute as: > > > > RS MS1 - slides > > RS MS2 - main, siprec1, siprec2 > > > > If this is all we think is required, using the content=20 > attribute does=20 > > seem sufficient. I agree with Charles till here and my understanding is same However, my understanding is people want=20 > to be able=20 > > to convey something other than the simple concatenation of content=20 > > attribute values, and for that reason, prefer to use XML.=20 I'm interested in knowing the intent apart from the above mentioned because I could not visualize. In this=20 > > case, the desired set of values is not bound by anything we will=20 > > define in SIPREC. That is my understanding as to why XML is=20 > preferred=20 > > over the RFC > > 4796 content attribute. > > > > Cheers, > > Charles > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec >=20 From rmohanr@cisco.com Wed Jul 6 22:17: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 DA81B21F88DB for ; Wed, 6 Jul 2011 22:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.149 X-Spam-Level: X-Spam-Status: No, score=-10.149 tagged_above=-999 required=5 tests=[AWL=-0.150, 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 1IEHvrizjINB for ; Wed, 6 Jul 2011 22:17:10 -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 8416321F888F for ; Wed, 6 Jul 2011 22:17:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=26040; q=dns/txt; s=iport; t=1310015829; x=1311225429; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=dDUk1GLG0KXc+EUOnrKwvjGkZWpuGlYpXSLQrMHiK6A=; b=FAl3sYgM0WBIwheTcSiZRj4olkBRfXLo6nN1JN7eQWuSwOIyAGCl6ARg JTwdLcfA39/WMxGWlHJ4vvWrnArVkMU6UHPPL37lP/yAlkDMJQ4aAOUNc WCupulLCYqXlW3FsSFt90lUTOmDyOOkfcB2tFm1jSIxLqmQP498yLFFin E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUBACNAFU5Io8UQ/2dsb2JhbABTmGSPM3eIe6VdnXqGNwSHR5AFi0M X-IronPort-AV: E=Sophos;i="4.65,491,1304294400"; d="scan'208";a="100042515" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-1.cisco.com with ESMTP; 07 Jul 2011 05:17:05 +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 p675GwAX003337; Thu, 7 Jul 2011 05:17:04 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Jul 2011 10:46:42 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Jul 2011 10:46:40 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD06F4F9B0@XMB-BGL-417.cisco.com> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Content (RFC 4796) attribute in SDP or XML Thread-Index: Acw0mPHhxfeVJEDcQLSYWo3IAZGl7wABDbXgACpfOfAADTnVAAA/CH7wAL12yxAADByJIAAdm3FgAADcErAAQaGFkAAC7JoQAAMpvCAAAObikAAasOngAAJiC3AAGcWykAATt97A References: <07465C1D981ABC41A344374066AE1A2C38AF6D40CC@TLVMBX01.nice.com><07465C1D981ABC41A344374066AE1A2C38AF6D4376@TLVMBX01.nice.com><07465C1D981ABC41A344374066AE1A2C38AFE9B1C0@TLVMBX01.nice.com> <35BCE99A477D6A4986FB2216D8CF2CFD06E358D2@XMB-BGL-417.cisco.com> From: "Ram Mohan R (rmohanr)" To: "Charles Eckel (eckelcu)" , "Elwell, John" , "Parthasarathi R (partr)" , "Leon Portman" , X-OriginalArrivalTime: 07 Jul 2011 05:16:42.0351 (UTC) FILETIME=[0EBCA7F0:01CC3C65] Subject: Re: [siprec] Content (RFC 4796) attribute in SDP or XML X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 05:17:13 -0000 Inline > -----Original Message----- > From: Charles Eckel (eckelcu) > Sent: Thursday, July 07, 2011 1:35 AM > To: Ram Mohan R (rmohanr); 'Elwell, John'; Parthasarathi R (partr); > 'Leon Portman'; 'siprec@ietf.org' > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML >=20 > RFC 4796 has registered the following values: >=20 > slides RFC 4796 Presentation slides > speaker RFC 4796 Image from the speaker > sl RFC 4796 Sign language > main RFC 4796 Main media stream > alt RFC 4796 Alternative media stream >=20 > Suppose we register the following new values: >=20 > siprec1 RFC xxxx SIPREC value 1 > siprec2 RFC xxxx SIPREC value 2 > siprec3 RFC xxxx SIPREC value 3 >=20 > If the CS has a media lines with the following content attributes >=20 > CS MS1 - slides > CS MS2 - main > CS MS3 - siprec1 > CS MS4 - siprec2 >=20 > SRC sends two media streams to RS. RS MS1 is essentially CS MS1. RS MS2 > is some composition of CS MS2, CS MS3 and CS MS4. > This could be represented using the content attribute as: >=20 > RS MS1 - slides > RS MS2 - main, siprec1, siprec2 >=20 > If this is all we think is required, using the content attribute does > seem sufficient. However, my understanding is people want to be able to > convey something other than the simple concatenation of content > attribute values, and for that reason, prefer to use XML. In this case, > the desired set of values is not bound by anything we will define in > SIPREC. That is my understanding as to why XML is preferred over the > RFC 4796 content attribute. Yes that's my thought too. Extending content attribute ( by registering new values if required) may be sufficient for SIPREC and we may be able to use content attribute in RS SDP to indicate the content-type. I would like to hear on what other things we wish to convey using content for which we need XML. Regards, Ram >=20 > Cheers, > Charles >=20 >=20 > > -----Original Message----- > > From: Ram Mohan R (rmohanr) > > Sent: Wednesday, July 06, 2011 12:33 AM > > To: Elwell, John; Parthasarathi R (partr); Charles Eckel (eckelcu); > Leon Portman; siprec@ietf.org > > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML > > > > Just on this one > > > > > RS media stream is a mixed content type stream of "current > > > speaker video" and "room video" and the resultant shall be named as > > > "mixed current speaker video & room video" which shall be passed as > > > new content type extension to SRS > > [JRE] Right, so you agree this can't be passed in the RS SDP. I would > challenge the need to define > > (and register) a new RFC 4796 value "mixed current speaker video & > room video". We have two MS > > elements (representing the two CS video streams for current speaker > and room. Why can't we just place > > the respective RFC 4796 content types in the respective MS elements? > And why does it need to be as > > extension data - why can't it be standardized from day one? > > > > My thought here is since we have new content types "mixed current > speaker video & room video" we need > > to register/extend RFC 4796 for the same and send in RS SDP. I would > prefer this approach instead of > > sending it through recording metadata XML. Of course we need to > discuss this in AVT to get their > > opinion. > > > > Regards, > > Ram > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > > Behalf Of Elwell, John > > > Sent: Wednesday, July 06, 2011 12:05 PM > > > To: Parthasarathi R (partr); Charles Eckel (eckelcu); Leon Portman; > > > siprec@ietf.org > > > Subject: Re: [siprec] Content (RFC 4796) attribute in SDP or XML > > > > > > > > > > > > > -----Original Message----- > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > Sent: 05 July 2011 19:06 > > > > To: Charles Eckel (eckelcu); Leon Portman; Elwell, John; > > > > siprec@ietf.org > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML > > > > > > > > John, > > > > > > > > Please read inline. > > > > > > > > Thanks > > > > Partha > > > > > > > > > -----Original Message----- > > > > > From: Charles Eckel (eckelcu) > > > > > Sent: Tuesday, July 05, 2011 10:44 PM > > > > > To: Leon Portman; Elwell, John; Parthasarathi R (partr); > > > > > siprec@ietf.org > > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or > XML > > > > > > > > > > Okay by me. > > > > > > > > > > Cheers, > > > > > Charles > > > > > > > > > > > -----Original Message----- > > > > > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > > > > > Sent: Tuesday, July 05, 2011 8:42 AM > > > > > > To: Elwell, John; Parthasarathi R (partr); Charles Eckel > > > > (eckelcu); > > > > > > siprec@ietf.org > > > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or > XML > > > > > > > > > > > > I completely agree with the below. > > > > > > > > > > > > Leon > > > > > > > > > > > > -----Original Message----- > > > > > > From: Elwell, John [mailto:john.elwell@siemens- > enterprise.com] > > > > > > Sent: Tuesday, July 05, 2011 5:44 PM > > > > > > To: Parthasarathi R (partr); Leon Portman; Charles Eckel > > > > (eckelcu); > > > > > > siprec@ietf.org > > > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or > XML > > > > > > > > > > > > (as chair) > > > > > > We should try to avoid opening up old issues. I think we > > > > > had agreed that: > > > > > > - RS SDP describes the RS, and therefore just describes how > > > > > recordable media is delivered to the SRS. > > > > > > It does not describe how media is delivered between CS > > > > > endpoints as part of the CS. > > > > > > - Therefore anything to do with the CS (i.e., the session > being > > > > > > recorded) needs to be delivered to the SRS as metadata > > > > > (i.e., in XML). > > > > > > - We don't see a need to standardize delivery of things > > > > > like CS codecs > > > > > > in the metadata, but that could be done using the extension > > > > > mechanism. > > > > > > > > > > Hope everyone agree here that CS SDP information could > be > > > > passed as extension-data. attribute within data> > > > > may help to achieve this requirement. > > > [JRE] Or even as the standardized part of an MS element if we wish. > > > > > > > > > > > > > Focusing now on the content attribute, I don't think there is > any > > > > > > disagreement that the SRS needs to know the content type > (e.g., > > > > > > presentation) of a media stream. The SRC can obtain this from > the > > > > > > a=3Dcontent attribute of the CS SDP. The discussion is about > > > > > whether this content attribute should be conveyed to the SRS: > > > > > > A) as an a=3Dcontent attribute of the RS SDP, or > > > > > > B) within the metadata XML. > > > > > > > > > > > > (as individual) > > > > > > According to past decisions, there is perhaps an argument > > > > > for B). If, > > > > > > for example, we wanted to convey the fact that a CS media > > > > > stream was > > > > > > subject to 256-bit encryption, this information would go > > > > in the XML > > > > > > > > Here I have the doubt. In case 256-bit encryption is not > > > used > > > > by RS SDP, Please let me know the reason for passing the key > > > > information > > > > to SRS because RS SDP is not encrypted in that fashion. > > > [JRE] I did not suggest passing the CS keying material to the SRS. > I > > > just suggested passing the information that the CS media stream > used > > > 256 bit encryption. Perhaps this was a bad example - it was just > meant > > > to illustrate the general principle that information about the CS > > > should be passed in metadata XML. > > > > > > > > > > > > > (it can't go in the RS SDP, because the RS might not use > > > > > 256-bit encryption. Similarly, one could argue that the > > > > > content type of a CS media stream should go in the XML, not > > > > > in the RS SDP. > > > > I'm seeing content-type attribute as one of the > extension of > > > > SDP a=3D attribute. In general, it is possible to convert CS > > > mediastream > > > > content type to RS media stream content type because SRC RS > > > > media stream > > > > is formed based on CS media stream except for the mixing > scenarios > > > > > > > > > > > > > > > > > > > > I could even imagine cases where the content type of a CS > > > > > media stream > > > > > > does not equal the content type of an RS media stream, > > > > > e.g., where the > > > > > > SRC combines the current speaker video and the room video > > > > into two > > > > > > videos side-by-side in the same RS media stream. > > > > > > > > RS media stream is a mixed content type stream of > "current > > > > speaker video" and "room video" and the resultant shall be named > as > > > > "mixed current speaker video & room video" which shall be > > > > passed as new > > > > content type extension to SRS > > > [JRE] Right, so you agree this can't be passed in the RS SDP. I > would > > > challenge the need to define (and register) a new RFC 4796 value > "mixed > > > current speaker video & room video". We have two MS elements > > > (representing the two CS video streams for current speaker and > room. > > > Why can't we just place the respective RFC 4796 content types in > the > > > respective MS elements? And why does it need to be as extension > data - > > > why can't it be standardized from day one? > > > > > > John (as individual) > > > > > > > > > > > In the > > > > > metadata these would be two media streams, each with its own > > > > > content type, but both would refer to the same RS media stream. > > > > > > > > > > It will be problematic approach because the actual media > and > > > > metadata are not related explicitly. As per the current > description, > > > > there are two element with different unique-id uses > > > > same label > > > > in SDP with different XML element ("content-type") within them. > The > > > > issue is whether media has stream1 behavior or stream2 behavior > or > > > > mixed. We will able to extent XML element for having single > > > > interpretation but it is not fully clarified in the draft now. > The > > > > bottom-up matching like stream1 & stream2 has same label > > > > element and it > > > > has to be grouped together is not explicit in this scenario. We > need > > > > more investigation both information is required but not the > actual > > > > media. Please correct me in I'm missing something > > > > > > > > > > John > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > > > > Sent: 04 July 2011 08:08 > > > > > > > To: Leon Portman; Charles Eckel (eckelcu); Elwell, John; > > > > > > > siprec@ietf.org > > > > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP > or > > > XML > > > > > > > > > > > > > > Leon, > > > > > > > > > > > > > > Please read inline. > > > > > > > > > > > > > > Thanks > > > > > > > Partha > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > > > > > > > Sent: Monday, July 04, 2011 12:11 PM > > > > > > > > To: Parthasarathi R (partr); Charles Eckel (eckelcu); > Elwell, > > > > > > > > John; siprec@ietf.org > > > > > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in > > > > SDP or XML > > > > > > > > > > > > > > > > Partha Hi > > > > > > > > > > > > > > > > Please see below. > > > > > > > > > > > > > > > > Leon > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > > > > > Sent: Sunday, July 03, 2011 7:50 PM > > > > > > > > To: Leon Portman; Charles Eckel (eckelcu); Elwell, John; > > > > > > > > siprec@ietf.org > > > > > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in > > > > SDP or XML > > > > > > > > > > > > > > > > Leon, > > > > > > > > > > > > > > > > Please read inline. > > > > > > > > > > > > > > > > Thanks > > > > > > > > Partha > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > > > > > > > Sent: Sunday, July 03, 2011 4:13 PM > > > > > > > > To: Charles Eckel (eckelcu); Elwell, John; Parthasarathi > R > > > > > > > > (partr); siprec@ietf.org > > > > > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in > > > > SDP or XML > > > > > > > > > > > > > > > > I do prefer that metadata XML will be as self-contained > as > > > > > > > > possible and not rely on conveying some data via RS > > > > SDP. RS SDP > > > > > > > > should only be used to recording establishment and > > > > > negotiation and > > > > > > > > not as a mechanism for metadata reporting. > > > > > > > > > > > > > > > > In case Metadata XML has to be self-contained, > the > > > > > > > > complete SDP has to be converted into XML format or > > > > > else XML has > > > > > > > > to have sort of XML attribute which carries > SDP. > > > > > > > > Creating mapping for each SDP attribute with metadata > > > > > XML element > > > > > > > > does not seems to be feasible > > > > > > > > > > > > > > > > [LeonP] But if CS SDP is different from RS SDP, > > > > anyway you will > > > > > > > > need to encapsulate the original RS SDP, so why not in > XML? > > > > > > > > > > > > > > I guess that the confusion is here. In the > > > > > current format, > > > > > > > RS SDP is only carried towards SRS and CS SDP is not > forwarded. > > > > > > > This design > > > > > > > is closed as part of ticket #71 > > > > > > > > > > > > (http://www.ietf.org/mail- > > > archive/web/siprec/current/msg02106.html). > > > > > > > Please bring up with the usecase for CS SDP if required > > > > > > > > > > > > > > > > > > > > > > > > > > > Otherwise we will not be able to reuse same format for > > > > > reporting > > > > > > > > metadata via web services As per IETF-80 and > > > > > last interim > > > > > > > > meeting, there is no intent of reusing this metadata > > > > > XML in other > > > > > > > > protocol. In case reusing same format for webservice > > > > or XMPP is > > > > > > > > the intent, the current metadata XML mechanism is not > > > > > the appropriate. > > > > > > > > This was discussed in > > > > > > > > > > > > > http://www.ietf.org/mail- > archive/web/siprec/current/msg02151.html, > > > > > > > > > > > > > > > > > > > > http://www.ietf.org/mail- > > > archive/web/siprec/current/msg02155.html(1s > > > > > > > t > > > > > > > > point in format slide). In case you have difference > > > > of opinion > > > > > > > > even after this multiple discussion, let us again > > > > > discuss at IETF-81. > > > > > > > > > > > > > > > > > > > > > > > > [LeonP] I was not proposing replacing SIP with another > > > > > transport > > > > > > > > layer, just wanted to keep other options open. > > > > > > > > > > > > > > Current metadata format is customized for SIP > > > > > transport. In > > > > > > > case we need to keep the options open, the format has to be > > > > > > > revisited from the scratch. In our analysis, we notice > > > > that REST > > > > > > > architecture with Metadata XML is best fit for HTTP, XMPP > > > > > > > > > > > > > > > > > > > I am > > > > > > > > very big supporter for metadata over SIP reporting > > > > > > > > > > > > > > > Thanks, Me too.. > > > > > > > > > > > > > > > or as dedicated SIP session. > > > > > > > > In case Metadata is separate session from RS, RS > > > > > > > > attribute like RS-id MUST be included within XML. This > was > > > > > > > > discussed at > > > > > > > > http://www.ietf.org/mail- > > > archive/web/siprec/current/msg02013.h > > > > > > > tml. Could you please explain reason for the dedicated > > > > > SIP > session > > > > > > > for metadata. > > > > > > > > > > > > > > > > > > > > > > > > [LeonP] The main use case is Recording on Demand, that is > > > > > > > > triggered by SRS. In such case it will be very useful > > > > > to have just > > > > > > > > one SIP session and send all metadata over it (like CTI > > > > > > > > link) and then only trigger recording (via external SRC > > > > > > > > interface) only for specific call segments. > > > > > > > > > > > > > > > I understand the current implementation wherein > > > > > few of the > > > > > > > metadata like CDR records is passed through non-sip > > > > > interface. It is > > > > > > > outside the scope of SIPREC. The global-id in format > > > > > shall be used > > > > > > > to correlate. Please let me know in case any current > > > > > SIPREC metadata > > > > > > > attribute MUST be passed through this CTS link. > > > > > > > > > > > > > > > As for examples, the basic information as media type, > labels, > > > > > > > > volume etc. Any application level data can be relevant. > Even > > > > > > > > indication of encryption (for a case where RS is not > > > > encrypted) > > > > > > > > > > > > > > > > Leon > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: siprec-bounces@ietf.org > > > > > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Charles > Eckel > > > > > > > (eckelcu) > > > > > > > > Sent: Wednesday, June 29, 2011 7:17 PM > > > > > > > > To: Elwell, John; Parthasarathi R (partr); > siprec@ietf.org > > > > > > > > Subject: Re: [siprec] Content (RFC 4796) attribute in > > > > SDP or XML > > > > > > > > > > > > > > > > I think it is sufficient, especially since we can assign > new > > > > > > > > values if necessary. > > > > > > > > Are there any examples of what people think they > > > > might want to > > > > > > > > capture in the SDP and/or metadata field? > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Charles > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: siprec-bounces@ietf.org > > > > > [mailto:siprec-bounces@ietf.org] > > > > > > > > > On > > > > > > > > Behalf Of Elwell, John > > > > > > > > > Sent: Tuesday, June 28, 2011 3:11 AM > > > > > > > > > To: Parthasarathi R (partr); siprec@ietf.org > > > > > > > > > Subject: Re: [siprec] Content (RFC 4796) attribute in > > > > > SDP or XML > > > > > > > > > > > > > > > > > > I would like other opinions on whether the SDP > a=3Dcontent > > > > > > > > attribute in > > > > > > > > the RS SDP has the correct > > > > > > > > > semantics for representing the content type of the > > > > > > > recorded CS media > > > > > > > > stream. > > > > > > > > > > > > > > > > > > John > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Parthasarathi R (partr) > [mailto:partr@cisco.com] > > > > > > > > > > Sent: 28 June 2011 10:45 > > > > > > > > > > To: Elwell, John; siprec@ietf.org > > > > > > > > > > Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > > > > > > > > > Subject: RE: Content (RFC 4796) attribute in SDP or > XML > > > > > > > > > > > > > > > > > > > > John, > > > > > > > > > > > > > > > > > > > > In case if it is the argument of whether CS MS > content > > > > > > > > type or RS MS > > > > > > > > > > > > > > > > > > content type in the metadata, it is better for us to > > > > > > > > re-open ticket > > > > > > > > > > #71 > > > > > > > > > > > > > > > > > > > > > > > (http://www.ietf.org/mail- > > > archive/web/siprec/current/msg02106.html). > > > > > > > > > > Please let me know your opinion here. > > > > > > > > > > > > > > > > > > > > The basic idea in metadata format is to re-use as > > > > > much as SDP > > > > > > > > > > attribute (like direction, content) in media level > for > > > > > > > RS dialog > > > > > > > > > > (using SDP label attribute as a pointer) until > otherwise > > > > > > > > there is a > > > > > > > > > > restriction in using in such manner. As per RFC 4796, > > > > > > > there is no > > > > > > > > > > such restriction and so, I prefer to reuse as content > SDP > > > > > > > > attribute > > > > > > > > > > rather than introducing the new > > > > element for > > > > > > > > > > this purpose. > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > Partha > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Elwell, John > > > > > [mailto:john.elwell@siemens-enterprise.com] > > > > > > > > > > Sent: Monday, June 27, 2011 1:18 PM > > > > > > > > > > To: Parthasarathi R (partr); siprec@ietf.org > > > > > > > > > > Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > > > > > > > > > Subject: RE: Content (RFC 4796) attribute in SDP or > XML > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Parthasarathi R (partr) > [mailto:partr@cisco.com] > > > > > > > > > > > Sent: 27 June 2011 08:08 > > > > > > > > > > > To: siprec@ietf.org; Elwell, John > > > > > > > > > > > Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > > > > > > > > > > Subject: Content (RFC 4796) attribute in SDP or XML > > > > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > > > > > As per the last interim SIPREC meeting, there is a > > > > > > > consensus to > > > > > > > > > > > describe the content of an MS using RFC 4796 & its > > > > > > > > > > extension. As per > > > > > > > > > > > RFC 4796, the multiple instance of content > attribute > > > > > > > is possible > > > > > > > > to > > > > > > > > > > > exist in SDP which shall be used in RS SDP. SRS > > > > > shall group > > > > > > > > > > the same > > > > > > > > > > > media content types by "content" attribute in RS > > > > > SDP. We are > > > > > > > > > > > interested in knowing any specfic reason for this > > > > > > > > attribute to be > > > > > > > > > > > duplicated in Metadata XML. > > > > > > > > > > [JRE] I don't have a reason for **duplication**. > > > > > > > However, I think > > > > > > > > > > there is a valid question to be asked whether the > content > > > > > > > > type of an > > > > > > > > > > > > > > > > > > MS should be represented: > > > > > > > > > > A) in XML; or > > > > > > > > > > B) in RS SDP as a=3Dcontent. > > > > > > > > > > > > > > > > > > > > The content type we are talking about is an MS > content > > > > > > > > type, i.e., > > > > > > > > > > relating to the CS. One could argue that the > > > > > > > > corresponding RS stream > > > > > > > > > > > > > > > > > > is NOT the same content type. For example: > > > > > > > > > > - CS MS content type is "slides". > > > > > > > > > > - RS media stream content type is "recording of > slides". > > > > > > > > > > > > > > > > > > > > On this basis, I think the correct option for > > > > > conveying the MS > > > > > > > > content > > > > > > > > > > type "slides" is A) (in the XML). > > > > > > > > > > > > > > > > > > > > Note that this would not involve duplication. The SDP > > > > > > > > > > a=3Dcontent attribute is optional, so we need not = use > > > > > it for the RS. > > > > > > > > > > > > > > > > > > > > Perhaps my distinction is too theoretical, but I do > > > > > > > feel a little > > > > > > > > more > > > > > > > > > > comfortable using the XML rather than the RS SDP. > > > > > > > > > > > > > > > > > > > > John (as individual) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > > > > > Partha > > > > > > > > > > > > > > > > > > > > > > last Interim SIPREC meeting Note: > > > > > > > > > > > > > > > > > > > > > > Slide 7: On the question of how to describe the > content > > > > > > > > of an MS, > > > > > > > > > > > there was no objection to basing this on the types > in > > > > > > > > the RFC 4796 > > > > > > > > > > > > > > > > > > > registry (new values could be specified via the > > > > > appropriate > > > > > > > > > > means if > > > > > > > > > > > needed). Paul had a slight concern that you might > > > > > be mixing > > > > > > > > > > multiple > > > > > > > > > > > CS MSs into a single RS media stream and whether > > > > > this might > > > > > > > > > > result in > > > > > > > > > > > cases not describable in this way, but in the end > > > > > > > accepted the > > > > > > > > > > > consensus. It needs to be discussed on the list > > > > > > > whether this is > > > > > > > > > > > conveyed in XML or in the RS SDP a=3Dcontent > attribute. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > siprec mailing list > > > > > > > > > siprec@ietf.org > > > > > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > _______________________________________________ > > > > > > > > siprec mailing 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 Jul 7 00:06: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 5BC0F21F85BC for ; Thu, 7 Jul 2011 00:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.123 X-Spam-Level: X-Spam-Status: No, score=-106.123 tagged_above=-999 required=5 tests=[AWL=-0.124, 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 xVV66uLPlbS9 for ; Thu, 7 Jul 2011 00:06:09 -0700 (PDT) Received: from mail182.messagelabs.com (mail182.messagelabs.com [85.158.139.83]) by ietfa.amsl.com (Postfix) with SMTP id 779B321F850F for ; Thu, 7 Jul 2011 00:06:07 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1310022365!7975053!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 20014 invoked from network); 7 Jul 2011 07:06:06 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-3.tower-182.messagelabs.com with SMTP; 7 Jul 2011 07:06:06 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id E50791EB83ED; Thu, 7 Jul 2011 09:06:05 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 7 Jul 2011 09:06:05 +0200 From: "Elwell, John" To: "Charles Eckel (eckelcu)" , "Ram Mohan R (rmohanr)" , "Parthasarathi R (partr)" , Leon Portman , "siprec@ietf.org" Date: Thu, 7 Jul 2011 09:06:04 +0200 Thread-Topic: [siprec] Content (RFC 4796) attribute in SDP or XML Thread-Index: Acw0mPHhxfeVJEDcQLSYWo3IAZGl7wABDbXgACpfOfAADTnVAAA/CH7wAL12yxAADByJIAAdm3FgAADcErAAQaGFkAAC7JoQAAMpvCAAAObikAAasOngAAJiC3AAGcWykAAW4scQ Message-ID: References: <07465C1D981ABC41A344374066AE1A2C38AF6D40CC@TLVMBX01.nice.com><07465C1D981ABC41A344374066AE1A2C38AF6D4376@TLVMBX01.nice.com><07465C1D981ABC41A344374066AE1A2C38AFE9B1C0@TLVMBX01.nice.com> <35BCE99A477D6A4986FB2216D8CF2CFD06E358D2@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] Content (RFC 4796) attribute in SDP or XML X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 07:06:11 -0000 Charles, I see how it COULD be done in the way you describe. I just feel it is archi= tecturally wrong to describe the CS MS as part of the RS MS description (i.= e., the RS SDP). However, I can also give a more specific reason. Suppose CS MS1 is slides a= nd CS MS2 is speaker video. But the XML does not tell me that CS MS1 is sli= des and CS MS1 is speaker video. Both CS MS1 and CS MS2 are combined into R= S MS1 (slides + speaker). The XML metadata tells me that at a given time Pa= rticipant P1 contributed to CS MS1 and P2 contributed to CS MS2. How can I = tell that P1 contributed to slides and P2 contributed to speaker? See also below: > -----Original Message----- > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > Sent: 06 July 2011 21:05 > To: Ram Mohan R (rmohanr); Elwell, John; Parthasarathi R > (partr); Leon Portman; siprec@ietf.org > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML > > RFC 4796 has registered the following values: > > slides RFC 4796 Presentation slides > speaker RFC 4796 Image from the speaker > sl RFC 4796 Sign language > main RFC 4796 Main media stream > alt RFC 4796 Alternative media stream > > Suppose we register the following new values: > > siprec1 RFC xxxx SIPREC value 1 > siprec2 RFC xxxx SIPREC value 2 > siprec3 RFC xxxx SIPREC value 3 > > If the CS has a media lines with the following content attributes > > CS MS1 - slides > CS MS2 - main > CS MS3 - siprec1 > CS MS4 - siprec2 > > SRC sends two media streams to RS. RS MS1 is essentially CS > MS1. RS MS2 > is some composition of CS MS2, CS MS3 and CS MS4. > This could be represented using the content attribute as: > > RS MS1 - slides > RS MS2 - main, siprec1, siprec2 > > If this is all we think is required, using the content attribute does > seem sufficient. However, my understanding is people want to > be able to > convey something other than the simple concatenation of content > attribute values, and for that reason, prefer to use XML. In > this case, > the desired set of values is not bound by anything we will define in > SIPREC. That is my understanding as to why XML is preferred > over the RFC > 4796 content attribute. [JRE] That was not my motivation, but perhaps others had that in mind. John (as individual) > > Cheers, > Charles > > > > -----Original Message----- > > From: Ram Mohan R (rmohanr) > > Sent: Wednesday, July 06, 2011 12:33 AM > > To: Elwell, John; Parthasarathi R (partr); Charles Eckel (eckelcu); > Leon Portman; siprec@ietf.org > > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML > > > > Just on this one > > > > > RS media stream is a mixed content type stream > of "current > > > speaker video" and "room video" and the resultant shall > be named as > > > "mixed current speaker video & room video" which shall be > passed as > > > new content type extension to SRS > > [JRE] Right, so you agree this can't be passed in the RS > SDP. I would > challenge the need to define > > (and register) a new RFC 4796 value "mixed current speaker video & > room video". We have two MS > > elements (representing the two CS video streams for current speaker > and room. Why can't we just place > > the respective RFC 4796 content types in the respective MS elements? > And why does it need to be as > > extension data - why can't it be standardized from day one? > > > > My thought here is since we have new content types "mixed current > speaker video & room video" we need > > to register/extend RFC 4796 for the same and send in RS SDP. I would > prefer this approach instead of > > sending it through recording metadata XML. Of course we need to > discuss this in AVT to get their > > opinion. > > > > Regards, > > Ram > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > > Behalf Of Elwell, John > > > Sent: Wednesday, July 06, 2011 12:05 PM > > > To: Parthasarathi R (partr); Charles Eckel (eckelcu); > Leon Portman; > > > siprec@ietf.org > > > Subject: Re: [siprec] Content (RFC 4796) attribute in SDP or XML > > > > > > > > > > > > > -----Original Message----- > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > Sent: 05 July 2011 19:06 > > > > To: Charles Eckel (eckelcu); Leon Portman; Elwell, John; > > > > siprec@ietf.org > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML > > > > > > > > John, > > > > > > > > Please read inline. > > > > > > > > Thanks > > > > Partha > > > > > > > > > -----Original Message----- > > > > > From: Charles Eckel (eckelcu) > > > > > Sent: Tuesday, July 05, 2011 10:44 PM > > > > > To: Leon Portman; Elwell, John; Parthasarathi R (partr); > > > > > siprec@ietf.org > > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in > SDP or XML > > > > > > > > > > Okay by me. > > > > > > > > > > Cheers, > > > > > Charles > > > > > > > > > > > -----Original Message----- > > > > > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > > > > > Sent: Tuesday, July 05, 2011 8:42 AM > > > > > > To: Elwell, John; Parthasarathi R (partr); Charles Eckel > > > > (eckelcu); > > > > > > siprec@ietf.org > > > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or > XML > > > > > > > > > > > > I completely agree with the below. > > > > > > > > > > > > Leon > > > > > > > > > > > > -----Original Message----- > > > > > > From: Elwell, John > [mailto:john.elwell@siemens-enterprise.com] > > > > > > Sent: Tuesday, July 05, 2011 5:44 PM > > > > > > To: Parthasarathi R (partr); Leon Portman; Charles Eckel > > > > (eckelcu); > > > > > > siprec@ietf.org > > > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or > XML > > > > > > > > > > > > (as chair) > > > > > > We should try to avoid opening up old issues. I think we > > > > > had agreed that: > > > > > > - RS SDP describes the RS, and therefore just describes how > > > > > recordable media is delivered to the SRS. > > > > > > It does not describe how media is delivered between CS > > > > > endpoints as part of the CS. > > > > > > - Therefore anything to do with the CS (i.e., the session > being > > > > > > recorded) needs to be delivered to the SRS as metadata > > > > > (i.e., in XML). > > > > > > - We don't see a need to standardize delivery of things > > > > > like CS codecs > > > > > > in the metadata, but that could be done using the extension > > > > > mechanism. > > > > > > > > > > Hope everyone agree here that CS SDP > information could be > > > > passed as extension-data. attribute within > > > > > may help to achieve this requirement. > > > [JRE] Or even as the standardized part of an MS element > if we wish. > > > > > > > > > > > > > Focusing now on the content attribute, I don't > think there is > any > > > > > > disagreement that the SRS needs to know the content type > (e.g., > > > > > > presentation) of a media stream. The SRC can obtain > this from > the > > > > > > a=3Dcontent attribute of the CS SDP. The discussion is about > > > > > whether this content attribute should be conveyed to the SRS: > > > > > > A) as an a=3Dcontent attribute of the RS SDP, or > > > > > > B) within the metadata XML. > > > > > > > > > > > > (as individual) > > > > > > According to past decisions, there is perhaps an argument > > > > > for B). If, > > > > > > for example, we wanted to convey the fact that a CS media > > > > > stream was > > > > > > subject to 256-bit encryption, this information would go > > > > in the XML > > > > > > > > Here I have the doubt. In case 256-bit > encryption is not > > > used > > > > by RS SDP, Please let me know the reason for passing the key > > > > information > > > > to SRS because RS SDP is not encrypted in that fashion. > > > > [JRE] I did not suggest passing the CS keying material to > the SRS. I > > > just suggested passing the information that the CS media > stream used > > > 256 bit encryption. Perhaps this was a bad example - it was just > meant > > > to illustrate the general principle that information about the CS > > > should be passed in metadata XML. > > > > > > > > > > > > > (it can't go in the RS SDP, because the RS might not use > > > > > 256-bit encryption. Similarly, one could argue that the > > > > > content type of a CS media stream should go in the XML, not > > > > > in the RS SDP. > > > > I'm seeing content-type attribute as one of > the extension > of > > > > SDP a=3D attribute. In general, it is possible to convert CS > > > mediastream > > > > content type to RS media stream content type because SRC RS > > > > media stream > > > > is formed based on CS media stream except for the > mixing scenarios > > > > > > > > > > > > > > > > > > > > I could even imagine cases where the content type of a CS > > > > > media stream > > > > > > does not equal the content type of an RS media stream, > > > > > e.g., where the > > > > > > SRC combines the current speaker video and the room video > > > > into two > > > > > > videos side-by-side in the same RS media stream. > > > > > > > > RS media stream is a mixed content type stream of > "current > > > > speaker video" and "room video" and the resultant shall be named > as > > > > "mixed current speaker video & room video" which shall be > > > > passed as new > > > > content type extension to SRS > > > [JRE] Right, so you agree this can't be passed in the RS SDP. I > would > > > challenge the need to define (and register) a new RFC 4796 value > "mixed > > > current speaker video & room video". We have two MS elements > > > (representing the two CS video streams for current > speaker and room. > > > Why can't we just place the respective RFC 4796 content > types in the > > > respective MS elements? And why does it need to be as > extension data > - > > > why can't it be standardized from day one? > > > > > > John (as individual) > > > > > > > > > > > In the > > > > > metadata these would be two media streams, each with its own > > > > > content type, but both would refer to the same RS > media stream. > > > > > > > > > > It will be problematic approach because the > actual media > and > > > > metadata are not related explicitly. As per the current > description, > > > > there are two element with different unique-id uses > > > > same label > > > > in SDP with different XML element ("content-type") within them. > The > > > > issue is whether media has stream1 behavior or stream2 > behavior or > > > > mixed. We will able to extent XML element for having single > > > > interpretation but it is not fully clarified in the > draft now. The > > > > bottom-up matching like stream1 & stream2 has same label > > > > element and it > > > > has to be grouped together is not explicit in this scenario. We > need > > > > more investigation both information is required but not > the actual > > > > media. Please correct me in I'm missing something > > > > > > > > > > John > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > > > > Sent: 04 July 2011 08:08 > > > > > > > To: Leon Portman; Charles Eckel (eckelcu); Elwell, John; > > > > > > > siprec@ietf.org > > > > > > > Subject: RE: [siprec] Content (RFC 4796) > attribute in SDP or > > > XML > > > > > > > > > > > > > > Leon, > > > > > > > > > > > > > > Please read inline. > > > > > > > > > > > > > > Thanks > > > > > > > Partha > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > > > > > > > Sent: Monday, July 04, 2011 12:11 PM > > > > > > > > To: Parthasarathi R (partr); Charles Eckel (eckelcu); > Elwell, > > > > > > > > John; siprec@ietf.org > > > > > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in > > > > SDP or XML > > > > > > > > > > > > > > > > Partha Hi > > > > > > > > > > > > > > > > Please see below. > > > > > > > > > > > > > > > > Leon > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > > > > > Sent: Sunday, July 03, 2011 7:50 PM > > > > > > > > To: Leon Portman; Charles Eckel (eckelcu); Elwell, John; > > > > > > > > siprec@ietf.org > > > > > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in > > > > SDP or XML > > > > > > > > > > > > > > > > Leon, > > > > > > > > > > > > > > > > Please read inline. > > > > > > > > > > > > > > > > Thanks > > > > > > > > Partha > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > > > > > > > Sent: Sunday, July 03, 2011 4:13 PM > > > > > > > > To: Charles Eckel (eckelcu); Elwell, John; > Parthasarathi R > > > > > > > > (partr); siprec@ietf.org > > > > > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in > > > > SDP or XML > > > > > > > > > > > > > > > > I do prefer that metadata XML will be as > self-contained as > > > > > > > > possible and not rely on conveying some data via RS > > > > SDP. RS SDP > > > > > > > > should only be used to recording establishment and > > > > > negotiation and > > > > > > > > not as a mechanism for metadata reporting. > > > > > > > > > > > > > > > > In case Metadata XML has to be self-contained, > the > > > > > > > > complete SDP has to be converted into XML format or > > > > > else XML has > > > > > > > > to have sort of XML attribute which > carries SDP. > > > > > > > > Creating mapping for each SDP attribute with metadata > > > > > XML element > > > > > > > > does not seems to be feasible > > > > > > > > > > > > > > > > [LeonP] But if CS SDP is different from RS SDP, > > > > anyway you will > > > > > > > > need to encapsulate the original RS SDP, so why not in > XML? > > > > > > > > > > > > > > I guess that the confusion is here. In the > > > > > current format, > > > > > > > RS SDP is only carried towards SRS and CS SDP is not > forwarded. > > > > > > > This design > > > > > > > is closed as part of ticket #71 > > > > > > > > > > > > (http://www.ietf.org/mail- > > > archive/web/siprec/current/msg02106.html). > > > > > > > Please bring up with the usecase for CS SDP if required > > > > > > > > > > > > > > > > > > > > > > > > > > > Otherwise we will not be able to reuse same format for > > > > > reporting > > > > > > > > metadata via web services As per IETF-80 and > > > > > last interim > > > > > > > > meeting, there is no intent of reusing this metadata > > > > > XML in other > > > > > > > > protocol. In case reusing same format for webservice > > > > or XMPP is > > > > > > > > the intent, the current metadata XML mechanism is not > > > > > the appropriate. > > > > > > > > This was discussed in > > > > > > > > > > > > > > http://www.ietf.org/mail-archive/web/siprec/current/msg02151.html, > > > > > > > > > > > > > > > > > > > > http://www.ietf.org/mail- > > > archive/web/siprec/current/msg02155.html(1s > > > > > > > t > > > > > > > > point in format slide). In case you have difference > > > > of opinion > > > > > > > > even after this multiple discussion, let us again > > > > > discuss at IETF-81. > > > > > > > > > > > > > > > > > > > > > > > > [LeonP] I was not proposing replacing SIP with another > > > > > transport > > > > > > > > layer, just wanted to keep other options open. > > > > > > > > > > > > > > Current metadata format is customized for SIP > > > > > transport. In > > > > > > > case we need to keep the options open, the format > has to be > > > > > > > revisited from the scratch. In our analysis, we notice > > > > that REST > > > > > > > architecture with Metadata XML is best fit for HTTP, XMPP > > > > > > > > > > > > > > > > > > > I am > > > > > > > > very big supporter for metadata over SIP reporting > > > > > > > > > > > > > > > Thanks, Me too.. > > > > > > > > > > > > > > > or as dedicated SIP session. > > > > > > > > In case Metadata is separate session > from RS, RS > > > > > > > > attribute like RS-id MUST be included within > XML. This was > > > > > > > > discussed at > > > > > > > > http://www.ietf.org/mail- > > > archive/web/siprec/current/msg02013.h > > > > > > > tml. Could you please explain reason for the dedicated > > > > > SIP > session > > > > > > > for metadata. > > > > > > > > > > > > > > > > > > > > > > > > [LeonP] The main use case is Recording on > Demand, that is > > > > > > > > triggered by SRS. In such case it will be very useful > > > > > to have just > > > > > > > > one SIP session and send all metadata over it (like CTI > > > > > > > > link) and then only trigger recording (via external SRC > > > > > > > > interface) only for specific call segments. > > > > > > > > > > > > > > > I understand the current implementation wherein > > > > > few of the > > > > > > > metadata like CDR records is passed through non-sip > > > > > interface. It is > > > > > > > outside the scope of SIPREC. The global-id in format > > > > > shall be used > > > > > > > to correlate. Please let me know in case any current > > > > > SIPREC metadata > > > > > > > attribute MUST be passed through this CTS link. > > > > > > > > > > > > > > > As for examples, the basic information as media type, > labels, > > > > > > > > volume etc. Any application level data can be relevant. > Even > > > > > > > > indication of encryption (for a case where RS is not > > > > encrypted) > > > > > > > > > > > > > > > > Leon > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: siprec-bounces@ietf.org > > > > > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Charles > Eckel > > > > > > > (eckelcu) > > > > > > > > Sent: Wednesday, June 29, 2011 7:17 PM > > > > > > > > To: Elwell, John; Parthasarathi R (partr); > siprec@ietf.org > > > > > > > > Subject: Re: [siprec] Content (RFC 4796) attribute in > > > > SDP or XML > > > > > > > > > > > > > > > > I think it is sufficient, especially since we can assign > new > > > > > > > > values if necessary. > > > > > > > > Are there any examples of what people think they > > > > might want to > > > > > > > > capture in the SDP and/or metadata field? > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Charles > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: siprec-bounces@ietf.org > > > > > [mailto:siprec-bounces@ietf.org] > > > > > > > > > On > > > > > > > > Behalf Of Elwell, John > > > > > > > > > Sent: Tuesday, June 28, 2011 3:11 AM > > > > > > > > > To: Parthasarathi R (partr); siprec@ietf.org > > > > > > > > > Subject: Re: [siprec] Content (RFC 4796) attribute in > > > > > SDP or XML > > > > > > > > > > > > > > > > > > I would like other opinions on whether the > SDP a=3Dcontent > > > > > > > > attribute in > > > > > > > > the RS SDP has the correct > > > > > > > > > semantics for representing the content type of the > > > > > > > recorded CS media > > > > > > > > stream. > > > > > > > > > > > > > > > > > > John > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Parthasarathi R (partr) > [mailto:partr@cisco.com] > > > > > > > > > > Sent: 28 June 2011 10:45 > > > > > > > > > > To: Elwell, John; siprec@ietf.org > > > > > > > > > > Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > > > > > > > > > Subject: RE: Content (RFC 4796) attribute in SDP or > XML > > > > > > > > > > > > > > > > > > > > John, > > > > > > > > > > > > > > > > > > > > In case if it is the argument of whether CS > MS content > > > > > > > > type or RS MS > > > > > > > > > > > > > > > > > > content type in the metadata, it is better for us to > > > > > > > > re-open ticket > > > > > > > > > > #71 > > > > > > > > > > > > > > > > > > > > > > > (http://www.ietf.org/mail- > > > archive/web/siprec/current/msg02106.html). > > > > > > > > > > Please let me know your opinion here. > > > > > > > > > > > > > > > > > > > > The basic idea in metadata format is to re-use as > > > > > much as SDP > > > > > > > > > > attribute (like direction, content) in > media level for > > > > > > > RS dialog > > > > > > > > > > (using SDP label attribute as a pointer) until > otherwise > > > > > > > > there is a > > > > > > > > > > restriction in using in such manner. As per > RFC 4796, > > > > > > > there is no > > > > > > > > > > such restriction and so, I prefer to reuse > as content > SDP > > > > > > > > attribute > > > > > > > > > > rather than introducing the new > > > > element for > > > > > > > > > > this purpose. > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > Partha > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Elwell, John > > > > > [mailto:john.elwell@siemens-enterprise.com] > > > > > > > > > > Sent: Monday, June 27, 2011 1:18 PM > > > > > > > > > > To: Parthasarathi R (partr); siprec@ietf.org > > > > > > > > > > Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > > > > > > > > > Subject: RE: Content (RFC 4796) attribute in SDP or > XML > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Parthasarathi R (partr) > [mailto:partr@cisco.com] > > > > > > > > > > > Sent: 27 June 2011 08:08 > > > > > > > > > > > To: siprec@ietf.org; Elwell, John > > > > > > > > > > > Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > > > > > > > > > > Subject: Content (RFC 4796) attribute in > SDP or XML > > > > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > > > > > As per the last interim SIPREC meeting, there is a > > > > > > > consensus to > > > > > > > > > > > describe the content of an MS using RFC 4796 & its > > > > > > > > > > extension. As per > > > > > > > > > > > RFC 4796, the multiple instance of > content attribute > > > > > > > is possible > > > > > > > > to > > > > > > > > > > > exist in SDP which shall be used in RS SDP. SRS > > > > > shall group > > > > > > > > > > the same > > > > > > > > > > > media content types by "content" attribute in RS > > > > > SDP. We are > > > > > > > > > > > interested in knowing any specfic reason for this > > > > > > > > attribute to be > > > > > > > > > > > duplicated in Metadata XML. > > > > > > > > > > [JRE] I don't have a reason for **duplication**. > > > > > > > However, I think > > > > > > > > > > there is a valid question to be asked whether the > content > > > > > > > > type of an > > > > > > > > > > > > > > > > > > MS should be represented: > > > > > > > > > > A) in XML; or > > > > > > > > > > B) in RS SDP as a=3Dcontent. > > > > > > > > > > > > > > > > > > > > The content type we are talking about is an > MS content > > > > > > > > type, i.e., > > > > > > > > > > relating to the CS. One could argue that the > > > > > > > > corresponding RS stream > > > > > > > > > > > > > > > > > > is NOT the same content type. For example: > > > > > > > > > > - CS MS content type is "slides". > > > > > > > > > > - RS media stream content type is "recording of > slides". > > > > > > > > > > > > > > > > > > > > On this basis, I think the correct option for > > > > > conveying the MS > > > > > > > > content > > > > > > > > > > type "slides" is A) (in the XML). > > > > > > > > > > > > > > > > > > > > Note that this would not involve > duplication. The SDP > > > > > > > > > > a=3Dcontent attribute is optional, so we need not use > > > > > it for the RS. > > > > > > > > > > > > > > > > > > > > Perhaps my distinction is too theoretical, but I do > > > > > > > feel a little > > > > > > > > more > > > > > > > > > > comfortable using the XML rather than the RS SDP. > > > > > > > > > > > > > > > > > > > > John (as individual) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > > > > > Partha > > > > > > > > > > > > > > > > > > > > > > last Interim SIPREC meeting Note: > > > > > > > > > > > > > > > > > > > > > > Slide 7: On the question of how to describe the > content > > > > > > > > of an MS, > > > > > > > > > > > there was no objection to basing this on the types > in > > > > > > > > the RFC 4796 > > > > > > > > > > > > > > > > > > > registry (new values could be specified via the > > > > > appropriate > > > > > > > > > > means if > > > > > > > > > > > needed). Paul had a slight concern that you might > > > > > be mixing > > > > > > > > > > multiple > > > > > > > > > > > CS MSs into a single RS media stream and whether > > > > > this might > > > > > > > > > > result in > > > > > > > > > > > cases not describable in this way, but in the end > > > > > > > accepted the > > > > > > > > > > > consensus. It needs to be discussed on the list > > > > > > > whether this is > > > > > > > > > > > conveyed in XML or in the RS SDP a=3Dcontent > attribute. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > siprec mailing list > > > > > > > > > siprec@ietf.org > > > > > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > _______________________________________________ > > > > > > > > siprec mailing 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 Jul 7 05:02: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 956361F0C34 for ; Thu, 7 Jul 2011 05:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.923 X-Spam-Level: X-Spam-Status: No, score=-9.923 tagged_above=-999 required=5 tests=[AWL=0.076, 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 xXGrIhlwbSwv for ; Thu, 7 Jul 2011 05:02: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 629089E8004 for ; Thu, 7 Jul 2011 05:02:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=30778; q=dns/txt; s=iport; t=1310040130; x=1311249730; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=LCbKiyQk1Hu+Wdn4+mttNJuIjkvWSzYj+zX6KGLZqmY=; b=GFeeecGuzgTq2+hHS2JyfYvY5RsOpPGBEf+xZeJzOjtC7icCINM2mSf/ R3kiVFK4Bau5OsugAXaUXJc+H5XzgF577zU4kCa6rfWk/0XwsrnjRZ82x em00EkB+A8CQCUCpYAVFBpH/SC3Edl43Sut/wkj7zUIpeEfh0qefUfrJ8 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoBAL6eFU5Io8UT/2dsb2JhbABTmGWPNXeIe6UynW2GOASHR5AFi0M X-IronPort-AV: E=Sophos;i="4.65,493,1304294400"; d="scan'208";a="100120396" Received: from bgl-core-4.cisco.com ([72.163.197.19]) by ams-iport-1.cisco.com with ESMTP; 07 Jul 2011 12:02:07 +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 p67C27Cm003410; Thu, 7 Jul 2011 12:02:07 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Jul 2011 17:32:07 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Jul 2011 17:32:04 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Content (RFC 4796) attribute in SDP or XML Thread-Index: Acw0mPHhxfeVJEDcQLSYWo3IAZGl7wABDbXgACpfOfAADTnVAAA/CH7wAL12yxAADByJIAAdm3FgAADcErAAQaGFkAAC7JoQAAMpvCAAAObikAAasOngAAJiC3AAGcWykAAW4scQAAPQnyA= References: <07465C1D981ABC41A344374066AE1A2C38AF6D40CC@TLVMBX01.nice.com><07465C1D981ABC41A344374066AE1A2C38AF6D4376@TLVMBX01.nice.com><07465C1D981ABC41A344374066AE1A2C38AFE9B1C0@TLVMBX01.nice.com> <35BCE99A477D6A4986FB2216D8CF2CFD06E358D2@XMB-BGL-417.cisco.com> From: "Parthasarathi R (partr)" To: "Elwell, John" , "Charles Eckel (eckelcu)" , "Ram Mohan R (rmohanr)" , "Leon Portman" , X-OriginalArrivalTime: 07 Jul 2011 12:02:07.0272 (UTC) FILETIME=[B1850A80:01CC3C9D] Subject: Re: [siprec] Content (RFC 4796) attribute in SDP or XML X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 12:02:13 -0000 John, I understand your mixed video scenario. In case of mixed audio or video, it is not possible to retrieve the complete information in SRS as it is pre-mixed at SRC. It is one of the motivation for having two m-line with non-mixed stream to SRS. The similar issue is raised by Charles earlier for mixed audio stream wherein current speaker (participant) has to be noticed using metadata XML. Even in case of mixed audio stream, the loss of some information is unavoidable. Hope you agree here. In case the intent is to create the infrastructure wherein the mixed stream should not loose the information, then we need the separate discussion. I will write the separate mail thread for the architecture clarification in SRC wherein CS is handling by one SIP UA instance and RS is handled as separate SIP UA instance. =20 SDP is reused for RS media description, in case it is not possible for SDP to express about specific media description then it is better to generically develop the extension like IANA registration for RFC 4796 which helps for other similar mixing applications as well.=20 >From the metadata perspective, Stream in XML is pointing to m-line of SDP using label attributes. SDP points to raw media. XML is used to create association which is not possible in SDP. Participant, session to Stream grouping is not possible to achieve in SDP which forces us to look for XML representation. But in case of content-type scenario, it is possible to make it happen.=20 Please read inline Thanks Partha =20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > Sent: Thursday, July 07, 2011 12:36 PM > To: Charles Eckel (eckelcu); Ram Mohan R (rmohanr);=20 > Parthasarathi R (partr); Leon Portman; siprec@ietf.org > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML >=20 > Charles, >=20 > I see how it COULD be done in the way you describe. I just=20 > feel it is architecturally wrong to describe the CS MS as=20 > part of the RS MS description (i.e., the RS SDP). In case the intent is to pass CS MS description, I agree with you. IIRC, charles proposed to use the explicit mixed content-type which is more appropriate to be passed in RS SDP to provide the description about that specific media. >=20 > However, I can also give a more specific reason. Suppose CS=20 > MS1 is slides and CS MS2 is speaker video. But the XML does=20 > not tell me that CS MS1 is slides and CS MS1 is speaker=20 > video. Both CS MS1 and CS MS2 are combined into RS MS1=20 > (slides + speaker).=20 The question here is how it is possible for any UA to represent (slides+speaker) in SDP? In case it is not well defined, let us work for it The XML metadata tells me that at a given=20 > time Participant P1 contributed to CS MS1 and P2 contributed=20 > to CS MS2. How can I tell that P1 contributed to slides and=20 > P2 contributed to speaker? In the mixed stream, we lose the data in SRC because actual media is mixed. The system shall be designed to send the media stream separately or we have to find the generic way to group the stream together =20 >=20 > See also below: >=20 > > -----Original Message----- > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > Sent: 06 July 2011 21:05 > > To: Ram Mohan R (rmohanr); Elwell, John; Parthasarathi R=20 > (partr); Leon=20 > > Portman; siprec@ietf.org > > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML > > > > RFC 4796 has registered the following values: > > > > slides RFC 4796 Presentation slides > > speaker RFC 4796 Image from the speaker > > sl RFC 4796 Sign language > > main RFC 4796 Main media stream > > alt RFC 4796 Alternative media stream > > > > Suppose we register the following new values: > > > > siprec1 RFC xxxx SIPREC value 1 > > siprec2 RFC xxxx SIPREC value 2 > > siprec3 RFC xxxx SIPREC value 3 > > > > If the CS has a media lines with the following content attributes > > > > CS MS1 - slides > > CS MS2 - main > > CS MS3 - siprec1 > > CS MS4 - siprec2 > > > > SRC sends two media streams to RS. RS MS1 is essentially CS MS1. RS=20 > > MS2 is some composition of CS MS2, CS MS3 and CS MS4. > > This could be represented using the content attribute as: > > > > RS MS1 - slides > > RS MS2 - main, siprec1, siprec2 > > > > If this is all we think is required, using the content=20 > attribute does=20 > > seem sufficient. However, my understanding is people want=20 > to be able=20 > > to convey something other than the simple concatenation of content=20 > > attribute values, and for that reason, prefer to use XML. In this=20 > > case, the desired set of values is not bound by anything we will=20 > > define in SIPREC. That is my understanding as to why XML is=20 > preferred=20 > > over the RFC > > 4796 content attribute. > [JRE] That was not my motivation, but perhaps others had that in mind. >=20 > John (as individual) >=20 > > > > Cheers, > > Charles > > > > > > > -----Original Message----- > > > From: Ram Mohan R (rmohanr) > > > Sent: Wednesday, July 06, 2011 12:33 AM > > > To: Elwell, John; Parthasarathi R (partr); Charles Eckel=20 > (eckelcu); > > Leon Portman; siprec@ietf.org > > > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML > > > > > > Just on this one > > > > > > > RS media stream is a mixed content type stream > > of "current > > > > speaker video" and "room video" and the resultant shall > > be named as > > > > "mixed current speaker video & room video" which shall be > > passed as > > > > new content type extension to SRS > > > [JRE] Right, so you agree this can't be passed in the RS > > SDP. I would > > challenge the need to define > > > (and register) a new RFC 4796 value "mixed current speaker video & > > room video". We have two MS > > > elements (representing the two CS video streams for=20 > current speaker > > and room. Why can't we just place > > > the respective RFC 4796 content types in the respective=20 > MS elements? > > And why does it need to be as > > > extension data - why can't it be standardized from day one? > > > > > > My thought here is since we have new content types "mixed current > > speaker video & room video" we need > > > to register/extend RFC 4796 for the same and send in RS=20 > SDP. I would > > prefer this approach instead of > > > sending it through recording metadata XML. Of course we need to > > discuss this in AVT to get their > > > opinion. > > > > > > Regards, > > > Ram > > > > > > > -----Original Message----- > > > > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On=20 > > > > Behalf Of Elwell, John > > > > Sent: Wednesday, July 06, 2011 12:05 PM > > > > To: Parthasarathi R (partr); Charles Eckel (eckelcu); > > Leon Portman; > > > > siprec@ietf.org > > > > Subject: Re: [siprec] Content (RFC 4796) attribute in SDP or XML > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > > Sent: 05 July 2011 19:06 > > > > > To: Charles Eckel (eckelcu); Leon Portman; Elwell, John;=20 > > > > > siprec@ietf.org > > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in=20 > SDP or XML > > > > > > > > > > John, > > > > > > > > > > Please read inline. > > > > > > > > > > Thanks > > > > > Partha > > > > > > > > > > > -----Original Message----- > > > > > > From: Charles Eckel (eckelcu) > > > > > > Sent: Tuesday, July 05, 2011 10:44 PM > > > > > > To: Leon Portman; Elwell, John; Parthasarathi R (partr);=20 > > > > > > siprec@ietf.org > > > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in > > SDP or XML > > > > > > > > > > > > Okay by me. > > > > > > > > > > > > Cheers, > > > > > > Charles > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > > > > > > Sent: Tuesday, July 05, 2011 8:42 AM > > > > > > > To: Elwell, John; Parthasarathi R (partr); Charles Eckel > > > > > (eckelcu); > > > > > > > siprec@ietf.org > > > > > > > Subject: RE: [siprec] Content (RFC 4796)=20 > attribute in SDP or > > XML > > > > > > > > > > > > > > I completely agree with the below. > > > > > > > > > > > > > > Leon > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Elwell, John > > [mailto:john.elwell@siemens-enterprise.com] > > > > > > > Sent: Tuesday, July 05, 2011 5:44 PM > > > > > > > To: Parthasarathi R (partr); Leon Portman; Charles Eckel > > > > > (eckelcu); > > > > > > > siprec@ietf.org > > > > > > > Subject: RE: [siprec] Content (RFC 4796)=20 > attribute in SDP or > > XML > > > > > > > > > > > > > > (as chair) > > > > > > > We should try to avoid opening up old issues. I think we > > > > > > had agreed that: > > > > > > > - RS SDP describes the RS, and therefore just=20 > describes how > > > > > > recordable media is delivered to the SRS. > > > > > > > It does not describe how media is delivered between CS > > > > > > endpoints as part of the CS. > > > > > > > - Therefore anything to do with the CS (i.e., the session > > being > > > > > > > recorded) needs to be delivered to the SRS as metadata > > > > > > (i.e., in XML). > > > > > > > - We don't see a need to standardize delivery of things > > > > > > like CS codecs > > > > > > > in the metadata, but that could be done using the=20 > extension > > > > > > mechanism. > > > > > > > > > > > > Hope everyone agree here that CS SDP > > information could be > > > > > passed as extension-data. attribute within > > > > > > > may help to achieve this requirement. > > > > [JRE] Or even as the standardized part of an MS element > > if we wish. > > > > > > > > > > > > > > > > Focusing now on the content attribute, I don't > > think there is > > any > > > > > > > disagreement that the SRS needs to know the content type > > (e.g., > > > > > > > presentation) of a media stream. The SRC can obtain > > this from > > the > > > > > > > a=3Dcontent attribute of the CS SDP. The discussion is = about > > > > > > whether this content attribute should be conveyed=20 > to the SRS: > > > > > > > A) as an a=3Dcontent attribute of the RS SDP, or > > > > > > > B) within the metadata XML. > > > > > > > > > > > > > > (as individual) > > > > > > > According to past decisions, there is perhaps an argument > > > > > > for B). If, > > > > > > > for example, we wanted to convey the fact that a CS media > > > > > > stream was > > > > > > > subject to 256-bit encryption, this information would go > > > > > in the XML > > > > > > > > > > Here I have the doubt. In case 256-bit > > encryption is not > > > > used > > > > > by RS SDP, Please let me know the reason for passing the key=20 > > > > > information to SRS because RS SDP is not encrypted in that=20 > > > > > fashion. > > > > > > [JRE] I did not suggest passing the CS keying material to > > the SRS. I > > > > just suggested passing the information that the CS media > > stream used > > > > 256 bit encryption. Perhaps this was a bad example - it was just > > meant > > > > to illustrate the general principle that information=20 > about the CS=20 > > > > should be passed in metadata XML. > > > > > > > > > > > > > > > > (it can't go in the RS SDP, because the RS might not use > > > > > > 256-bit encryption. Similarly, one could argue that the=20 > > > > > > content type of a CS media stream should go in the=20 > XML, not in=20 > > > > > > the RS SDP. > > > > > I'm seeing content-type attribute as one of > > the extension > > of > > > > > SDP a=3D attribute. In general, it is possible to convert CS > > > > mediastream > > > > > content type to RS media stream content type because SRC RS=20 > > > > > media stream is formed based on CS media stream except for the > > mixing scenarios > > > > > > > > > > > > > > > > > > > > > > > > I could even imagine cases where the content type of a CS > > > > > > media stream > > > > > > > does not equal the content type of an RS media stream, > > > > > > e.g., where the > > > > > > > SRC combines the current speaker video and the room video > > > > > into two > > > > > > > videos side-by-side in the same RS media stream. > > > > > > > > > > RS media stream is a mixed content type stream of > > "current > > > > > speaker video" and "room video" and the resultant=20 > shall be named > > as > > > > > "mixed current speaker video & room video" which=20 > shall be passed=20 > > > > > as new content type extension to SRS > > > > [JRE] Right, so you agree this can't be passed in the RS SDP. I > > would > > > > challenge the need to define (and register) a new RFC 4796 value > > "mixed > > > > current speaker video & room video". We have two MS elements=20 > > > > (representing the two CS video streams for current > > speaker and room. > > > > Why can't we just place the respective RFC 4796 content > > types in the > > > > respective MS elements? And why does it need to be as > > extension data > > - > > > > why can't it be standardized from day one? > > > > > > > > John (as individual) > > > > > > > > > > > > > > In the > > > > > > metadata these would be two media streams, each=20 > with its own=20 > > > > > > content type, but both would refer to the same RS > > media stream. > > > > > > > > > > > > It will be problematic approach because the > > actual media > > and > > > > > metadata are not related explicitly. As per the current > > description, > > > > > there are two element with different unique-id uses=20 > > > > > same label in SDP with different XML element ("content-type")=20 > > > > > within them. > > The > > > > > issue is whether media has stream1 behavior or stream2 > > behavior or > > > > > mixed. We will able to extent XML element for having single=20 > > > > > interpretation but it is not fully clarified in the > > draft now. The > > > > > bottom-up matching like stream1 & stream2 has same=20 > label element=20 > > > > > and it has to be grouped together is not explicit in this=20 > > > > > scenario. We > > need > > > > > more investigation both information is required but not > > the actual > > > > > media. Please correct me in I'm missing something > > > > > > > > > > > > John > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > > > > > Sent: 04 July 2011 08:08 > > > > > > > > To: Leon Portman; Charles Eckel (eckelcu);=20 > Elwell, John;=20 > > > > > > > > siprec@ietf.org > > > > > > > > Subject: RE: [siprec] Content (RFC 4796) > > attribute in SDP or > > > > XML > > > > > > > > > > > > > > > > Leon, > > > > > > > > > > > > > > > > Please read inline. > > > > > > > > > > > > > > > > Thanks > > > > > > > > Partha > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > > > > > > > > Sent: Monday, July 04, 2011 12:11 PM > > > > > > > > > To: Parthasarathi R (partr); Charles Eckel (eckelcu); > > Elwell, > > > > > > > > > John; siprec@ietf.org > > > > > > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in > > > > > SDP or XML > > > > > > > > > > > > > > > > > > Partha Hi > > > > > > > > > > > > > > > > > > Please see below. > > > > > > > > > > > > > > > > > > Leon > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > > > > > > Sent: Sunday, July 03, 2011 7:50 PM > > > > > > > > > To: Leon Portman; Charles Eckel (eckelcu);=20 > Elwell, John;=20 > > > > > > > > > siprec@ietf.org > > > > > > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in > > > > > SDP or XML > > > > > > > > > > > > > > > > > > Leon, > > > > > > > > > > > > > > > > > > Please read inline. > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > Partha > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > > > > > > > > Sent: Sunday, July 03, 2011 4:13 PM > > > > > > > > > To: Charles Eckel (eckelcu); Elwell, John; > > Parthasarathi R > > > > > > > > > (partr); siprec@ietf.org > > > > > > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in > > > > > SDP or XML > > > > > > > > > > > > > > > > > > I do prefer that metadata XML will be as > > self-contained as > > > > > > > > > possible and not rely on conveying some data via RS > > > > > SDP. RS SDP > > > > > > > > > should only be used to recording establishment and > > > > > > negotiation and > > > > > > > > > not as a mechanism for metadata reporting. > > > > > > > > > > > > > > > > > > In case Metadata XML has to be=20 > self-contained, > > the > > > > > > > > > complete SDP has to be converted into XML format or > > > > > > else XML has > > > > > > > > > to have sort of XML attribute which > > carries SDP. > > > > > > > > > Creating mapping for each SDP attribute with metadata > > > > > > XML element > > > > > > > > > does not seems to be feasible > > > > > > > > > > > > > > > > > > [LeonP] But if CS SDP is different from RS SDP, > > > > > anyway you will > > > > > > > > > need to encapsulate the original RS SDP, so why not in > > XML? > > > > > > > > > > > > > > > > I guess that the confusion is here. In the > > > > > > current format, > > > > > > > > RS SDP is only carried towards SRS and CS SDP is not > > forwarded. > > > > > > > > This design > > > > > > > > is closed as part of ticket #71 > > > > > > > > > > > > > > (http://www.ietf.org/mail- > > > > archive/web/siprec/current/msg02106.html). > > > > > > > > Please bring up with the usecase for CS SDP if required > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Otherwise we will not be able to reuse same format for > > > > > > reporting > > > > > > > > > metadata via web services As per IETF-80 and > > > > > > last interim > > > > > > > > > meeting, there is no intent of reusing this metadata > > > > > > XML in other > > > > > > > > > protocol. In case reusing same format for webservice > > > > > or XMPP is > > > > > > > > > the intent, the current metadata XML mechanism is not > > > > > > the appropriate. > > > > > > > > > This was discussed in > > > > > > > > > > > > > > > > > http://www.ietf.org/mail-archive/web/siprec/current/msg02151.html, > > > > > > > > > > > > > > > > > > > > > > > http://www.ietf.org/mail- > > > > archive/web/siprec/current/msg02155.html(1s > > > > > > > > t > > > > > > > > > point in format slide). In case you have difference > > > > > of opinion > > > > > > > > > even after this multiple discussion, let us again > > > > > > discuss at IETF-81. > > > > > > > > > > > > > > > > > > > > > > > > > > > [LeonP] I was not proposing replacing SIP with another > > > > > > transport > > > > > > > > > layer, just wanted to keep other options open. > > > > > > > > > > > > > > > > Current metadata format is customized for SIP > > > > > > transport. In > > > > > > > > case we need to keep the options open, the format > > has to be > > > > > > > > revisited from the scratch. In our analysis, we notice > > > > > that REST > > > > > > > > architecture with Metadata XML is best fit for=20 > HTTP, XMPP > > > > > > > > > > > > > > > > > > > > > > I am > > > > > > > > > very big supporter for metadata over SIP reporting > > > > > > > > > > > > > > > > > Thanks, Me too.. > > > > > > > > > > > > > > > > > or as dedicated SIP session. > > > > > > > > > In case Metadata is separate session > > from RS, RS > > > > > > > > > attribute like RS-id MUST be included within > > XML. This was > > > > > > > > > discussed at > > > > > > > > > http://www.ietf.org/mail- > > > > archive/web/siprec/current/msg02013.h > > > > > > > > tml. Could you please explain reason for the dedicated > > > > > > SIP > session > > > > > > > > for metadata. > > > > > > > > > > > > > > > > > > > > > > > > > > > [LeonP] The main use case is Recording on > > Demand, that is > > > > > > > > > triggered by SRS. In such case it will be very useful > > > > > > to have just > > > > > > > > > one SIP session and send all metadata over it=20 > (like CTI > > > > > > > > > link) and then only trigger recording (via=20 > external SRC > > > > > > > > > interface) only for specific call segments. > > > > > > > > > > > > > > > > > I understand the current implementation wherein > > > > > > few of the > > > > > > > > metadata like CDR records is passed through non-sip > > > > > > interface. It is > > > > > > > > outside the scope of SIPREC. The global-id in format > > > > > > shall be used > > > > > > > > to correlate. Please let me know in case any current > > > > > > SIPREC metadata > > > > > > > > attribute MUST be passed through this CTS link.=20 > > > > > > > > > > > > > > > > > > As for examples, the basic information as media type, > > labels, > > > > > > > > > volume etc. Any application level data can be=20 > relevant. > > Even > > > > > > > > > indication of encryption (for a case where RS is not > > > > > encrypted) > > > > > > > > > > > > > > > > > > Leon > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: siprec-bounces@ietf.org=20 > > > > > > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Charles > > Eckel > > > > > > > > (eckelcu) > > > > > > > > > Sent: Wednesday, June 29, 2011 7:17 PM > > > > > > > > > To: Elwell, John; Parthasarathi R (partr); > > siprec@ietf.org > > > > > > > > > Subject: Re: [siprec] Content (RFC 4796) attribute in > > > > > SDP or XML > > > > > > > > > > > > > > > > > > I think it is sufficient, especially since we=20 > can assign > > new > > > > > > > > > values if necessary. > > > > > > > > > Are there any examples of what people think they > > > > > might want to > > > > > > > > > capture in the SDP and/or metadata field? > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > Charles > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: siprec-bounces@ietf.org > > > > > > [mailto:siprec-bounces@ietf.org] > > > > > > > > > > On > > > > > > > > > Behalf Of Elwell, John > > > > > > > > > > Sent: Tuesday, June 28, 2011 3:11 AM > > > > > > > > > > To: Parthasarathi R (partr); siprec@ietf.org > > > > > > > > > > Subject: Re: [siprec] Content (RFC 4796)=20 > attribute in > > > > > > SDP or XML > > > > > > > > > > > > > > > > > > > > I would like other opinions on whether the > > SDP a=3Dcontent > > > > > > > > > attribute in > > > > > > > > > the RS SDP has the correct > > > > > > > > > > semantics for representing the content type of the > > > > > > > > recorded CS media > > > > > > > > > stream. > > > > > > > > > > > > > > > > > > > > John > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Parthasarathi R (partr) > > [mailto:partr@cisco.com] > > > > > > > > > > > Sent: 28 June 2011 10:45 > > > > > > > > > > > To: Elwell, John; siprec@ietf.org > > > > > > > > > > > Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > > > > > > > > > > Subject: RE: Content (RFC 4796) attribute=20 > in SDP or > > XML > > > > > > > > > > > > > > > > > > > > > > John, > > > > > > > > > > > > > > > > > > > > > > In case if it is the argument of whether CS > > MS content > > > > > > > > > type or RS MS > > > > > > > > > > > > > > > > > > > > content type in the metadata, it is=20 > better for us to > > > > > > > > > re-open ticket > > > > > > > > > > > #71 > > > > > > > > > > > > > > > > > > > > > > > > > > (http://www.ietf.org/mail- > > > > archive/web/siprec/current/msg02106.html). > > > > > > > > > > > Please let me know your opinion here. > > > > > > > > > > > > > > > > > > > > > > The basic idea in metadata format is to re-use as > > > > > > much as SDP > > > > > > > > > > > attribute (like direction, content) in > > media level for > > > > > > > > RS dialog > > > > > > > > > > > (using SDP label attribute as a pointer) until > > otherwise > > > > > > > > > there is a > > > > > > > > > > > restriction in using in such manner. As per > > RFC 4796, > > > > > > > > there is no > > > > > > > > > > > such restriction and so, I prefer to reuse > > as content > > SDP > > > > > > > > > attribute > > > > > > > > > > > rather than introducing the new > > > > > element for > > > > > > > > > > > this purpose. > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > Partha > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Elwell, John > > > > > > [mailto:john.elwell@siemens-enterprise.com] > > > > > > > > > > > Sent: Monday, June 27, 2011 1:18 PM > > > > > > > > > > > To: Parthasarathi R (partr); siprec@ietf.org > > > > > > > > > > > Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > > > > > > > > > > Subject: RE: Content (RFC 4796) attribute=20 > in SDP or > > XML > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: Parthasarathi R (partr) > > [mailto:partr@cisco.com] > > > > > > > > > > > > Sent: 27 June 2011 08:08 > > > > > > > > > > > > To: siprec@ietf.org; Elwell, John > > > > > > > > > > > > Cc: Ram Mohan R (rmohanr); Paul Kyzivat=20 > (pkyzivat) > > > > > > > > > > > > Subject: Content (RFC 4796) attribute in > > SDP or XML > > > > > > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > > > > > > > As per the last interim SIPREC meeting,=20 > there is a > > > > > > > > consensus to > > > > > > > > > > > > describe the content of an MS using RFC=20 > 4796 & its > > > > > > > > > > > extension. As per > > > > > > > > > > > > RFC 4796, the multiple instance of > > content attribute > > > > > > > > is possible > > > > > > > > > to > > > > > > > > > > > > exist in SDP which shall be used in RS SDP. SRS > > > > > > shall group > > > > > > > > > > > the same > > > > > > > > > > > > media content types by "content" attribute in RS > > > > > > SDP. We are > > > > > > > > > > > > interested in knowing any specfic=20 > reason for this > > > > > > > > > attribute to be > > > > > > > > > > > > duplicated in Metadata XML. > > > > > > > > > > > [JRE] I don't have a reason for **duplication**. > > > > > > > > However, I think > > > > > > > > > > > there is a valid question to be asked whether the > > content > > > > > > > > > type of an > > > > > > > > > > > > > > > > > > > > MS should be represented: > > > > > > > > > > > A) in XML; or > > > > > > > > > > > B) in RS SDP as a=3Dcontent. > > > > > > > > > > > > > > > > > > > > > > The content type we are talking about is an > > MS content > > > > > > > > > type, i.e., > > > > > > > > > > > relating to the CS. One could argue that the > > > > > > > > > corresponding RS stream > > > > > > > > > > > > > > > > > > > > is NOT the same content type. For example: > > > > > > > > > > > - CS MS content type is "slides". > > > > > > > > > > > - RS media stream content type is "recording of > > slides". > > > > > > > > > > > > > > > > > > > > > > On this basis, I think the correct option for > > > > > > conveying the MS > > > > > > > > > content > > > > > > > > > > > type "slides" is A) (in the XML). > > > > > > > > > > > > > > > > > > > > > > Note that this would not involve > > duplication. The SDP > > > > > > > > > > > a=3Dcontent attribute is optional, so we=20 > need not use > > > > > > it for the RS. > > > > > > > > > > > > > > > > > > > > > > Perhaps my distinction is too=20 > theoretical, but I do > > > > > > > > feel a little > > > > > > > > > more > > > > > > > > > > > comfortable using the XML rather than the RS SDP. > > > > > > > > > > > > > > > > > > > > > > John (as individual) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > > > > > > > Partha > > > > > > > > > > > > > > > > > > > > > > > > last Interim SIPREC meeting Note: > > > > > > > > > > > > > > > > > > > > > > > > Slide 7: On the question of how to describe the > > content > > > > > > > > > of an MS, > > > > > > > > > > > > there was no objection to basing this=20 > on the types > > in > > > > > > > > > the RFC 4796 > > > > > > > > > > > > > > > > > > > > > registry (new values could be specified via the > > > > > > appropriate > > > > > > > > > > > means if > > > > > > > > > > > > needed). Paul had a slight concern that=20 > you might > > > > > > be mixing > > > > > > > > > > > multiple > > > > > > > > > > > > CS MSs into a single RS media stream and whether > > > > > > this might > > > > > > > > > > > result in > > > > > > > > > > > > cases not describable in this way, but=20 > in the end > > > > > > > > accepted the > > > > > > > > > > > > consensus. It needs to be discussed on the list > > > > > > > > whether this is > > > > > > > > > > > > conveyed in XML or in the RS SDP a=3Dcontent > > attribute. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > siprec mailing list > > > > > > > > > > siprec@ietf.org > > > > > > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > > _______________________________________________ > > > > > > > > > siprec mailing 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 Jul 7 05:06: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 7C5D09E800A for ; Thu, 7 Jul 2011 05:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.231 X-Spam-Level: X-Spam-Status: No, score=-10.231 tagged_above=-999 required=5 tests=[AWL=0.367, 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 EAaWiyp9BOld for ; Thu, 7 Jul 2011 05:06:45 -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 9F5599E8007 for ; Thu, 7 Jul 2011 05:06:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=1894; q=dns/txt; s=iport; t=1310040405; x=1311250005; h=mime-version:subject:date:message-id:from:to; bh=X4d7Re5ovMANIFdHDhkyJxXbs4eacq2aocxDWbW4FB4=; b=MeFHKiIGZI2dTP41UfLqGZFsyOqfezmh3QELDYI5SMvqbi5AtoSHbIyv B8uhfoApajMmSSZ4G3Pv2cqkhF32KTUWznzyKiiS9hu44ciObcy3Sw2lC 8WT8/G+QfEq1TOPySHGY808R/RAx++G4WLBpgvD4H3nS63qQDHKw0lR6b 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIHAO+fFU5Io8UT/2dsb2JhbABTmSeOdHetFYEinW2GOASHR5AFi0M X-IronPort-AV: E=Sophos;i="4.65,493,1304294400"; d="scan'208,217";a="100121172" Received: from bgl-core-4.cisco.com ([72.163.197.19]) by ams-iport-1.cisco.com with ESMTP; 07 Jul 2011 12:06:44 +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 p67C6h0H004035 for ; Thu, 7 Jul 2011 12:06:43 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Jul 2011 17:36:43 +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_01CC3C9E.56191AD8" Date: Thu, 7 Jul 2011 17:36:41 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Caller preference information in Metadata Thread-Index: Acw8nlS7CXumifrDQ9SGZ9au5tuPnQ== From: "Parthasarathi R (partr)" To: X-OriginalArrivalTime: 07 Jul 2011 12:06:43.0551 (UTC) FILETIME=[5631DEF0:01CC3C9E] Subject: [siprec] Caller preference information in 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: Thu, 07 Jul 2011 12:06:46 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC3C9E.56191AD8 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi all, =20 Caller preference (RFC 3841) information about CS is possible to be passed in extension data of participant. The caller preference like "automata" shall be passed in SIPREC metadata itself in case folks are interested. Please let me know whether "caller preference" attribute shall be added under participant block. =20 Thanks Partha ------_=_NextPart_001_01CC3C9E.56191AD8 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi=20 all,
 
Caller = preference=20 (RFC 3841) information about CS is possible to be passed in extension = data of=20 participant. The caller preference like "automata" shall be passed in = SIPREC=20 metadata itself in case folks are interested. Please let me know whether = "caller=20 preference" attribute shall be added under participant=20 block.
 
Thanks
Partha
------_=_NextPart_001_01CC3C9E.56191AD8-- From john.elwell@siemens-enterprise.com Thu Jul 7 06:34: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 B94591F0C48 for ; Thu, 7 Jul 2011 06:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.116 X-Spam-Level: X-Spam-Status: No, score=-106.116 tagged_above=-999 required=5 tests=[AWL=-0.117, 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 ndRpOzYpu0Go for ; Thu, 7 Jul 2011 06:34:39 -0700 (PDT) Received: from mail182.messagelabs.com (mail182.messagelabs.com [85.158.139.83]) by ietfa.amsl.com (Postfix) with SMTP id A2E131F0C46 for ; Thu, 7 Jul 2011 06:34:38 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-6.tower-182.messagelabs.com!1310045676!10802357!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 17232 invoked from network); 7 Jul 2011 13:34:36 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-6.tower-182.messagelabs.com with SMTP; 7 Jul 2011 13:34:36 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id BD92023F03E2; Thu, 7 Jul 2011 15:34:36 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 7 Jul 2011 15:34:36 +0200 From: "Elwell, John" To: "Parthasarathi R (partr)" , "Charles Eckel (eckelcu)" , "Ram Mohan R (rmohanr)" , Leon Portman , "siprec@ietf.org" Date: Thu, 7 Jul 2011 15:34:34 +0200 Thread-Topic: [siprec] Content (RFC 4796) attribute in SDP or XML Thread-Index: Acw0mPHhxfeVJEDcQLSYWo3IAZGl7wABDbXgACpfOfAADTnVAAA/CH7wAL12yxAADByJIAAdm3FgAADcErAAQaGFkAAC7JoQAAMpvCAAAObikAAasOngAAJiC3AAGcWykAAW4scQAAPQnyAACOotkA== Message-ID: References: <07465C1D981ABC41A344374066AE1A2C38AF6D40CC@TLVMBX01.nice.com><07465C1D981ABC41A344374066AE1A2C38AF6D4376@TLVMBX01.nice.com><07465C1D981ABC41A344374066AE1A2C38AFE9B1C0@TLVMBX01.nice.com> <35BCE99A477D6A4986FB2216D8CF2CFD06E358D2@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] Content (RFC 4796) attribute in SDP or XML X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 13:34:41 -0000 > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > Sent: 07 July 2011 13:02 > To: Elwell, John; Charles Eckel (eckelcu); Ram Mohan R > (rmohanr); Leon Portman; siprec@ietf.org > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML > > John, > > I understand your mixed video scenario. In case of mixed > audio or video, > it is not possible to retrieve the complete information in > SRS as it is > pre-mixed at SRC. It is one of the motivation for having two > m-line with > non-mixed stream to SRS. The similar issue is raised by > Charles earlier > for mixed audio stream wherein current speaker (participant) has to be > noticed using metadata XML. Even in case of mixed audio > stream, the loss > of some information is unavoidable. Hope you agree here. In case the > intent is to create the infrastructure wherein the mixed stream should > not loose the information, then we need the separate discussion. > > I will write the separate mail thread for the architecture > clarification > in SRC wherein CS is handling by one SIP UA instance and RS is handled > as separate SIP UA instance. > > SDP is reused for RS media description, in case it is not possible for > SDP to express about specific media description then it is better to > generically develop the extension like IANA registration for RFC 4796 > which helps for other similar mixing applications as well. [JRE] Yes, I am in agreement with using the IANA registry for RFC 4796, and= extending it where necessary. My only question was whether these values ar= e most appropriately sent in SDP or in XML. > > From the metadata perspective, Stream in XML is pointing to m-line of > SDP using label attributes. [JRE] Yes, I had forgotten that. I recall an earlier misunderstanding to do= with this. I don't think that is clear in the metadata draft, so I will co= mment separately on that. However, if this is the common understanding, I c= an see that using the a=3Dcontent attribute in the RS SDP would be a viable= solution. John (as individual) > SDP points to raw media. XML is used to > create association which is not possible in SDP. Participant, > session to > Stream grouping is not possible to achieve in SDP which forces us to > look for XML representation. But in case of content-type scenario, it > is possible to make it happen. > > Please read inline > > Thanks > Partha > > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Thursday, July 07, 2011 12:36 PM > > To: Charles Eckel (eckelcu); Ram Mohan R (rmohanr); > > Parthasarathi R (partr); Leon Portman; siprec@ietf.org > > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML > > > > Charles, > > > > I see how it COULD be done in the way you describe. I just > > feel it is architecturally wrong to describe the CS MS as > > part of the RS MS description (i.e., the RS SDP). > > In case the intent is to pass CS MS description, I agree with > you. IIRC, charles proposed to use the explicit mixed > content-type which > is more appropriate to be passed in RS SDP to provide the description > about that specific media. > > > > > However, I can also give a more specific reason. Suppose CS > > MS1 is slides and CS MS2 is speaker video. But the XML does > > not tell me that CS MS1 is slides and CS MS1 is speaker > > video. Both CS MS1 and CS MS2 are combined into RS MS1 > > (slides + speaker). > > The question here is how it is possible for any UA > to represent > (slides+speaker) in SDP? In case it is not well defined, let > us work for > it > > The XML metadata tells me that at a given > > time Participant P1 contributed to CS MS1 and P2 contributed > > to CS MS2. How can I tell that P1 contributed to slides and > > P2 contributed to speaker? > > In the mixed stream, we lose the data in SRC because actual > media is mixed. The system shall be designed to send the media stream > separately or we have to find the generic way to group the stream > together > > > > > See also below: > > > > > -----Original Message----- > > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > Sent: 06 July 2011 21:05 > > > To: Ram Mohan R (rmohanr); Elwell, John; Parthasarathi R > > (partr); Leon > > > Portman; siprec@ietf.org > > > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML > > > > > > RFC 4796 has registered the following values: > > > > > > slides RFC 4796 Presentation slides > > > speaker RFC 4796 Image from the speaker > > > sl RFC 4796 Sign language > > > main RFC 4796 Main media stream > > > alt RFC 4796 Alternative media stream > > > > > > Suppose we register the following new values: > > > > > > siprec1 RFC xxxx SIPREC value 1 > > > siprec2 RFC xxxx SIPREC value 2 > > > siprec3 RFC xxxx SIPREC value 3 > > > > > > If the CS has a media lines with the following content attributes > > > > > > CS MS1 - slides > > > CS MS2 - main > > > CS MS3 - siprec1 > > > CS MS4 - siprec2 > > > > > > SRC sends two media streams to RS. RS MS1 is essentially > CS MS1. RS > > > MS2 is some composition of CS MS2, CS MS3 and CS MS4. > > > This could be represented using the content attribute as: > > > > > > RS MS1 - slides > > > RS MS2 - main, siprec1, siprec2 > > > > > > If this is all we think is required, using the content > > attribute does > > > seem sufficient. However, my understanding is people want > > to be able > > > to convey something other than the simple concatenation > of content > > > attribute values, and for that reason, prefer to use XML. In this > > > case, the desired set of values is not bound by anything we will > > > define in SIPREC. That is my understanding as to why XML is > > preferred > > > over the RFC > > > 4796 content attribute. > > [JRE] That was not my motivation, but perhaps others had > that in mind. > > > > John (as individual) > > > > > > > > Cheers, > > > Charles > > > > > > > > > > -----Original Message----- > > > > From: Ram Mohan R (rmohanr) > > > > Sent: Wednesday, July 06, 2011 12:33 AM > > > > To: Elwell, John; Parthasarathi R (partr); Charles Eckel > > (eckelcu); > > > Leon Portman; siprec@ietf.org > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML > > > > > > > > Just on this one > > > > > > > > > RS media stream is a mixed content type stream > > > of "current > > > > > speaker video" and "room video" and the resultant shall > > > be named as > > > > > "mixed current speaker video & room video" which shall be > > > passed as > > > > > new content type extension to SRS > > > > [JRE] Right, so you agree this can't be passed in the RS > > > SDP. I would > > > challenge the need to define > > > > (and register) a new RFC 4796 value "mixed current > speaker video & > > > room video". We have two MS > > > > elements (representing the two CS video streams for > > current speaker > > > and room. Why can't we just place > > > > the respective RFC 4796 content types in the respective > > MS elements? > > > And why does it need to be as > > > > extension data - why can't it be standardized from day one? > > > > > > > > My thought here is since we have new content types > "mixed current > > > speaker video & room video" we need > > > > to register/extend RFC 4796 for the same and send in RS > > SDP. I would > > > prefer this approach instead of > > > > sending it through recording metadata XML. Of course we need to > > > discuss this in AVT to get their > > > > opinion. > > > > > > > > Regards, > > > > Ram > > > > > > > > > -----Original Message----- > > > > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On > > > > > Behalf Of Elwell, John > > > > > Sent: Wednesday, July 06, 2011 12:05 PM > > > > > To: Parthasarathi R (partr); Charles Eckel (eckelcu); > > > Leon Portman; > > > > > siprec@ietf.org > > > > > Subject: Re: [siprec] Content (RFC 4796) attribute in > SDP or XML > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > > > Sent: 05 July 2011 19:06 > > > > > > To: Charles Eckel (eckelcu); Leon Portman; Elwell, John; > > > > > > siprec@ietf.org > > > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in > > SDP or XML > > > > > > > > > > > > John, > > > > > > > > > > > > Please read inline. > > > > > > > > > > > > Thanks > > > > > > Partha > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Charles Eckel (eckelcu) > > > > > > > Sent: Tuesday, July 05, 2011 10:44 PM > > > > > > > To: Leon Portman; Elwell, John; Parthasarathi R (partr); > > > > > > > siprec@ietf.org > > > > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in > > > SDP or XML > > > > > > > > > > > > > > Okay by me. > > > > > > > > > > > > > > Cheers, > > > > > > > Charles > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > > > > > > > Sent: Tuesday, July 05, 2011 8:42 AM > > > > > > > > To: Elwell, John; Parthasarathi R (partr); Charles Eckel > > > > > > (eckelcu); > > > > > > > > siprec@ietf.org > > > > > > > > Subject: RE: [siprec] Content (RFC 4796) > > attribute in SDP or > > > XML > > > > > > > > > > > > > > > > I completely agree with the below. > > > > > > > > > > > > > > > > Leon > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Elwell, John > > > [mailto:john.elwell@siemens-enterprise.com] > > > > > > > > Sent: Tuesday, July 05, 2011 5:44 PM > > > > > > > > To: Parthasarathi R (partr); Leon Portman; Charles Eckel > > > > > > (eckelcu); > > > > > > > > siprec@ietf.org > > > > > > > > Subject: RE: [siprec] Content (RFC 4796) > > attribute in SDP or > > > XML > > > > > > > > > > > > > > > > (as chair) > > > > > > > > We should try to avoid opening up old issues. I think we > > > > > > > had agreed that: > > > > > > > > - RS SDP describes the RS, and therefore just > > describes how > > > > > > > recordable media is delivered to the SRS. > > > > > > > > It does not describe how media is delivered between CS > > > > > > > endpoints as part of the CS. > > > > > > > > - Therefore anything to do with the CS (i.e., > the session > > > being > > > > > > > > recorded) needs to be delivered to the SRS as metadata > > > > > > > (i.e., in XML). > > > > > > > > - We don't see a need to standardize delivery of things > > > > > > > like CS codecs > > > > > > > > in the metadata, but that could be done using the > > extension > > > > > > > mechanism. > > > > > > > > > > > > > > Hope everyone agree here that CS SDP > > > information could be > > > > > > passed as extension-data. attribute within > > > > > > > > > may help to achieve this requirement. > > > > > [JRE] Or even as the standardized part of an MS element > > > if we wish. > > > > > > > > > > > > > > > > > > > Focusing now on the content attribute, I don't > > > think there is > > > any > > > > > > > > disagreement that the SRS needs to know the content type > > > (e.g., > > > > > > > > presentation) of a media stream. The SRC can obtain > > > this from > > > the > > > > > > > > a=3Dcontent attribute of the CS SDP. The > discussion is about > > > > > > > whether this content attribute should be conveyed > > to the SRS: > > > > > > > > A) as an a=3Dcontent attribute of the RS SDP, or > > > > > > > > B) within the metadata XML. > > > > > > > > > > > > > > > > (as individual) > > > > > > > > According to past decisions, there is perhaps > an argument > > > > > > > for B). If, > > > > > > > > for example, we wanted to convey the fact that > a CS media > > > > > > > stream was > > > > > > > > subject to 256-bit encryption, this information would go > > > > > > in the XML > > > > > > > > > > > > Here I have the doubt. In case 256-bit > > > encryption is not > > > > > used > > > > > > by RS SDP, Please let me know the reason for > passing the key > > > > > > information to SRS because RS SDP is not encrypted in that > > > > > > fashion. > > > > > > > > [JRE] I did not suggest passing the CS keying material to > > > the SRS. I > > > > > just suggested passing the information that the CS media > > > stream used > > > > > 256 bit encryption. Perhaps this was a bad example - > it was just > > > meant > > > > > to illustrate the general principle that information > > about the CS > > > > > should be passed in metadata XML. > > > > > > > > > > > > > > > > > > > (it can't go in the RS SDP, because the RS might not use > > > > > > > 256-bit encryption. Similarly, one could argue that the > > > > > > > content type of a CS media stream should go in the > > XML, not in > > > > > > > the RS SDP. > > > > > > I'm seeing content-type attribute as one of > > > the extension > > > of > > > > > > SDP a=3D attribute. In general, it is possible to convert CS > > > > > mediastream > > > > > > content type to RS media stream content type because SRC RS > > > > > > media stream is formed based on CS media stream > except for the > > > mixing scenarios > > > > > > > > > > > > > > > > > > > > > > > > > > > > I could even imagine cases where the content > type of a CS > > > > > > > media stream > > > > > > > > does not equal the content type of an RS media stream, > > > > > > > e.g., where the > > > > > > > > SRC combines the current speaker video and the > room video > > > > > > into two > > > > > > > > videos side-by-side in the same RS media stream. > > > > > > > > > > > > RS media stream is a mixed content type stream of > > > "current > > > > > > speaker video" and "room video" and the resultant > > shall be named > > > as > > > > > > "mixed current speaker video & room video" which > > shall be passed > > > > > > as new content type extension to SRS > > > > > [JRE] Right, so you agree this can't be passed in the > RS SDP. I > > > would > > > > > challenge the need to define (and register) a new RFC > 4796 value > > > "mixed > > > > > current speaker video & room video". We have two MS elements > > > > > (representing the two CS video streams for current > > > speaker and room. > > > > > Why can't we just place the respective RFC 4796 content > > > types in the > > > > > respective MS elements? And why does it need to be as > > > extension data > > > - > > > > > why can't it be standardized from day one? > > > > > > > > > > John (as individual) > > > > > > > > > > > > > > > > > In the > > > > > > > metadata these would be two media streams, each > > with its own > > > > > > > content type, but both would refer to the same RS > > > media stream. > > > > > > > > > > > > > > It will be problematic approach because the > > > actual media > > > and > > > > > > metadata are not related explicitly. As per the current > > > description, > > > > > > there are two element with different > unique-id uses > > > > > > same label in SDP with different XML element > ("content-type") > > > > > > within them. > > > The > > > > > > issue is whether media has stream1 behavior or stream2 > > > behavior or > > > > > > mixed. We will able to extent XML element for having single > > > > > > interpretation but it is not fully clarified in the > > > draft now. The > > > > > > bottom-up matching like stream1 & stream2 has same > > label element > > > > > > and it has to be grouped together is not explicit in this > > > > > > scenario. We > > > need > > > > > > more investigation both information is required but not > > > the actual > > > > > > media. Please correct me in I'm missing something > > > > > > > > > > > > > > John > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > > > > > > Sent: 04 July 2011 08:08 > > > > > > > > > To: Leon Portman; Charles Eckel (eckelcu); > > Elwell, John; > > > > > > > > > siprec@ietf.org > > > > > > > > > Subject: RE: [siprec] Content (RFC 4796) > > > attribute in SDP or > > > > > XML > > > > > > > > > > > > > > > > > > Leon, > > > > > > > > > > > > > > > > > > Please read inline. > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > Partha > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > > > > > > > > > Sent: Monday, July 04, 2011 12:11 PM > > > > > > > > > > To: Parthasarathi R (partr); Charles Eckel > (eckelcu); > > > Elwell, > > > > > > > > > > John; siprec@ietf.org > > > > > > > > > > Subject: RE: [siprec] Content (RFC 4796) > attribute in > > > > > > SDP or XML > > > > > > > > > > > > > > > > > > > > Partha Hi > > > > > > > > > > > > > > > > > > > > Please see below. > > > > > > > > > > > > > > > > > > > > Leon > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Parthasarathi R (partr) > [mailto:partr@cisco.com] > > > > > > > > > > Sent: Sunday, July 03, 2011 7:50 PM > > > > > > > > > > To: Leon Portman; Charles Eckel (eckelcu); > > Elwell, John; > > > > > > > > > > siprec@ietf.org > > > > > > > > > > Subject: RE: [siprec] Content (RFC 4796) > attribute in > > > > > > SDP or XML > > > > > > > > > > > > > > > > > > > > Leon, > > > > > > > > > > > > > > > > > > > > Please read inline. > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > Partha > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > > > > > > > > > Sent: Sunday, July 03, 2011 4:13 PM > > > > > > > > > > To: Charles Eckel (eckelcu); Elwell, John; > > > Parthasarathi R > > > > > > > > > > (partr); siprec@ietf.org > > > > > > > > > > Subject: RE: [siprec] Content (RFC 4796) > attribute in > > > > > > SDP or XML > > > > > > > > > > > > > > > > > > > > I do prefer that metadata XML will be as > > > self-contained as > > > > > > > > > > possible and not rely on conveying some data via RS > > > > > > SDP. RS SDP > > > > > > > > > > should only be used to recording establishment and > > > > > > > negotiation and > > > > > > > > > > not as a mechanism for metadata reporting. > > > > > > > > > > > > > > > > > > > > In case Metadata XML has to be > > self-contained, > > > the > > > > > > > > > > complete SDP has to be converted into XML format or > > > > > > > else XML has > > > > > > > > > > to have sort of XML attribute which > > > carries SDP. > > > > > > > > > > Creating mapping for each SDP attribute > with metadata > > > > > > > XML element > > > > > > > > > > does not seems to be feasible > > > > > > > > > > > > > > > > > > > > [LeonP] But if CS SDP is different from RS SDP, > > > > > > anyway you will > > > > > > > > > > need to encapsulate the original RS SDP, so > why not in > > > XML? > > > > > > > > > > > > > > > > > > I guess that the confusion is here. In the > > > > > > > current format, > > > > > > > > > RS SDP is only carried towards SRS and CS SDP is not > > > forwarded. > > > > > > > > > This design > > > > > > > > > is closed as part of ticket #71 > > > > > > > > > > > > > > > > (http://www.ietf.org/mail- > > > > > archive/web/siprec/current/msg02106.html). > > > > > > > > > Please bring up with the usecase for CS SDP > if required > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Otherwise we will not be able to reuse same > format for > > > > > > > reporting > > > > > > > > > > metadata via web services As per > IETF-80 and > > > > > > > last interim > > > > > > > > > > meeting, there is no intent of reusing this metadata > > > > > > > XML in other > > > > > > > > > > protocol. In case reusing same format for webservice > > > > > > or XMPP is > > > > > > > > > > the intent, the current metadata XML > mechanism is not > > > > > > > the appropriate. > > > > > > > > > > This was discussed in > > > > > > > > > > > > > > > > > > > > http://www.ietf.org/mail-archive/web/siprec/current/msg02151.html, > > > > > > > > > > > > > > > > > > > > > > > > > > http://www.ietf.org/mail- > > > > > archive/web/siprec/current/msg02155.html(1s > > > > > > > > > t > > > > > > > > > > point in format slide). In case you have difference > > > > > > of opinion > > > > > > > > > > even after this multiple discussion, let us again > > > > > > > discuss at IETF-81. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [LeonP] I was not proposing replacing SIP > with another > > > > > > > transport > > > > > > > > > > layer, just wanted to keep other options open. > > > > > > > > > > > > > > > > > > Current metadata format is customized for SIP > > > > > > > transport. In > > > > > > > > > case we need to keep the options open, the format > > > has to be > > > > > > > > > revisited from the scratch. In our analysis, we notice > > > > > > that REST > > > > > > > > > architecture with Metadata XML is best fit for > > HTTP, XMPP > > > > > > > > > > > > > > > > > > > > > > > > > I am > > > > > > > > > > very big supporter for metadata over SIP reporting > > > > > > > > > > > > > > > > > > > Thanks, Me too.. > > > > > > > > > > > > > > > > > > > or as dedicated SIP session. > > > > > > > > > > In case Metadata is separate session > > > from RS, RS > > > > > > > > > > attribute like RS-id MUST be included within > > > XML. This was > > > > > > > > > > discussed at > > > > > > > > > > http://www.ietf.org/mail- > > > > > archive/web/siprec/current/msg02013.h > > > > > > > > > tml. Could you please explain reason for the dedicated > > > > > > > SIP > session > > > > > > > > > for metadata. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [LeonP] The main use case is Recording on > > > Demand, that is > > > > > > > > > > triggered by SRS. In such case it will be > very useful > > > > > > > to have just > > > > > > > > > > one SIP session and send all metadata over it > > (like CTI > > > > > > > > > > link) and then only trigger recording (via > > external SRC > > > > > > > > > > interface) only for specific call segments. > > > > > > > > > > > > > > > > > > > I understand the current > implementation wherein > > > > > > > few of the > > > > > > > > > metadata like CDR records is passed through non-sip > > > > > > > interface. It is > > > > > > > > > outside the scope of SIPREC. The global-id in format > > > > > > > shall be used > > > > > > > > > to correlate. Please let me know in case any current > > > > > > > SIPREC metadata > > > > > > > > > attribute MUST be passed through this CTS link. > > > > > > > > > > > > > > > > > > > > > As for examples, the basic information as > media type, > > > labels, > > > > > > > > > > volume etc. Any application level data can be > > relevant. > > > Even > > > > > > > > > > indication of encryption (for a case where RS is not > > > > > > encrypted) > > > > > > > > > > > > > > > > > > > > Leon > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: siprec-bounces@ietf.org > > > > > > > > > > [mailto:siprec-bounces@ietf.org] On Behalf > Of Charles > > > Eckel > > > > > > > > > (eckelcu) > > > > > > > > > > Sent: Wednesday, June 29, 2011 7:17 PM > > > > > > > > > > To: Elwell, John; Parthasarathi R (partr); > > > siprec@ietf.org > > > > > > > > > > Subject: Re: [siprec] Content (RFC 4796) > attribute in > > > > > > SDP or XML > > > > > > > > > > > > > > > > > > > > I think it is sufficient, especially since we > > can assign > > > new > > > > > > > > > > values if necessary. > > > > > > > > > > Are there any examples of what people think they > > > > > > might want to > > > > > > > > > > capture in the SDP and/or metadata field? > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > Charles > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: siprec-bounces@ietf.org > > > > > > > [mailto:siprec-bounces@ietf.org] > > > > > > > > > > > On > > > > > > > > > > Behalf Of Elwell, John > > > > > > > > > > > Sent: Tuesday, June 28, 2011 3:11 AM > > > > > > > > > > > To: Parthasarathi R (partr); siprec@ietf.org > > > > > > > > > > > Subject: Re: [siprec] Content (RFC 4796) > > attribute in > > > > > > > SDP or XML > > > > > > > > > > > > > > > > > > > > > > I would like other opinions on whether the > > > SDP a=3Dcontent > > > > > > > > > > attribute in > > > > > > > > > > the RS SDP has the correct > > > > > > > > > > > semantics for representing the content type of the > > > > > > > > > recorded CS media > > > > > > > > > > stream. > > > > > > > > > > > > > > > > > > > > > > John > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: Parthasarathi R (partr) > > > [mailto:partr@cisco.com] > > > > > > > > > > > > Sent: 28 June 2011 10:45 > > > > > > > > > > > > To: Elwell, John; siprec@ietf.org > > > > > > > > > > > > Cc: Ram Mohan R (rmohanr); Paul Kyzivat > (pkyzivat) > > > > > > > > > > > > Subject: RE: Content (RFC 4796) attribute > > in SDP or > > > XML > > > > > > > > > > > > > > > > > > > > > > > > John, > > > > > > > > > > > > > > > > > > > > > > > > In case if it is the argument of whether CS > > > MS content > > > > > > > > > > type or RS MS > > > > > > > > > > > > > > > > > > > > > > content type in the metadata, it is > > better for us to > > > > > > > > > > re-open ticket > > > > > > > > > > > > #71 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > (http://www.ietf.org/mail- > > > > > archive/web/siprec/current/msg02106.html). > > > > > > > > > > > > Please let me know your opinion here. > > > > > > > > > > > > > > > > > > > > > > > > The basic idea in metadata format is to > re-use as > > > > > > > much as SDP > > > > > > > > > > > > attribute (like direction, content) in > > > media level for > > > > > > > > > RS dialog > > > > > > > > > > > > (using SDP label attribute as a pointer) until > > > otherwise > > > > > > > > > > there is a > > > > > > > > > > > > restriction in using in such manner. As per > > > RFC 4796, > > > > > > > > > there is no > > > > > > > > > > > > such restriction and so, I prefer to reuse > > > as content > > > SDP > > > > > > > > > > attribute > > > > > > > > > > > > rather than introducing the new > > > > > > element for > > > > > > > > > > > > this purpose. > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > Partha > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: Elwell, John > > > > > > > [mailto:john.elwell@siemens-enterprise.com] > > > > > > > > > > > > Sent: Monday, June 27, 2011 1:18 PM > > > > > > > > > > > > To: Parthasarathi R (partr); siprec@ietf.org > > > > > > > > > > > > Cc: Ram Mohan R (rmohanr); Paul Kyzivat > (pkyzivat) > > > > > > > > > > > > Subject: RE: Content (RFC 4796) attribute > > in SDP or > > > XML > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > From: Parthasarathi R (partr) > > > [mailto:partr@cisco.com] > > > > > > > > > > > > > Sent: 27 June 2011 08:08 > > > > > > > > > > > > > To: siprec@ietf.org; Elwell, John > > > > > > > > > > > > > Cc: Ram Mohan R (rmohanr); Paul Kyzivat > > (pkyzivat) > > > > > > > > > > > > > Subject: Content (RFC 4796) attribute in > > > SDP or XML > > > > > > > > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > > > > > > > > > As per the last interim SIPREC meeting, > > there is a > > > > > > > > > consensus to > > > > > > > > > > > > > describe the content of an MS using RFC > > 4796 & its > > > > > > > > > > > > extension. As per > > > > > > > > > > > > > RFC 4796, the multiple instance of > > > content attribute > > > > > > > > > is possible > > > > > > > > > > to > > > > > > > > > > > > > exist in SDP which shall be used in > RS SDP. SRS > > > > > > > shall group > > > > > > > > > > > > the same > > > > > > > > > > > > > media content types by "content" > attribute in RS > > > > > > > SDP. We are > > > > > > > > > > > > > interested in knowing any specfic > > reason for this > > > > > > > > > > attribute to be > > > > > > > > > > > > > duplicated in Metadata XML. > > > > > > > > > > > > [JRE] I don't have a reason for **duplication**. > > > > > > > > > However, I think > > > > > > > > > > > > there is a valid question to be asked > whether the > > > content > > > > > > > > > > type of an > > > > > > > > > > > > > > > > > > > > > > MS should be represented: > > > > > > > > > > > > A) in XML; or > > > > > > > > > > > > B) in RS SDP as a=3Dcontent. > > > > > > > > > > > > > > > > > > > > > > > > The content type we are talking about is an > > > MS content > > > > > > > > > > type, i.e., > > > > > > > > > > > > relating to the CS. One could argue that the > > > > > > > > > > corresponding RS stream > > > > > > > > > > > > > > > > > > > > > > is NOT the same content type. For example: > > > > > > > > > > > > - CS MS content type is "slides". > > > > > > > > > > > > - RS media stream content type is "recording of > > > slides". > > > > > > > > > > > > > > > > > > > > > > > > On this basis, I think the correct option for > > > > > > > conveying the MS > > > > > > > > > > content > > > > > > > > > > > > type "slides" is A) (in the XML). > > > > > > > > > > > > > > > > > > > > > > > > Note that this would not involve > > > duplication. The SDP > > > > > > > > > > > > a=3Dcontent attribute is optional, so we > > need not use > > > > > > > it for the RS. > > > > > > > > > > > > > > > > > > > > > > > > Perhaps my distinction is too > > theoretical, but I do > > > > > > > > > feel a little > > > > > > > > > > more > > > > > > > > > > > > comfortable using the XML rather than > the RS SDP. > > > > > > > > > > > > > > > > > > > > > > > > John (as individual) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > > > > > > > > > Partha > > > > > > > > > > > > > > > > > > > > > > > > > > last Interim SIPREC meeting Note: > > > > > > > > > > > > > > > > > > > > > > > > > > Slide 7: On the question of how to > describe the > > > content > > > > > > > > > > of an MS, > > > > > > > > > > > > > there was no objection to basing this > > on the types > > > in > > > > > > > > > > the RFC 4796 > > > > > > > > > > > > > > > > > > > > > > > registry (new values could be > specified via the > > > > > > > appropriate > > > > > > > > > > > > means if > > > > > > > > > > > > > needed). Paul had a slight concern that > > you might > > > > > > > be mixing > > > > > > > > > > > > multiple > > > > > > > > > > > > > CS MSs into a single RS media stream > and whether > > > > > > > this might > > > > > > > > > > > > result in > > > > > > > > > > > > > cases not describable in this way, but > > in the end > > > > > > > > > accepted the > > > > > > > > > > > > > consensus. It needs to be discussed > on the list > > > > > > > > > whether this is > > > > > > > > > > > > > conveyed in XML or in the RS SDP a=3Dcontent > > > attribute. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > siprec mailing list > > > > > > > > > > > siprec@ietf.org > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > > > _______________________________________________ > > > > > > > > > > siprec mailing 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 Jul 7 06:36:21 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 CEE5A21F857C for ; Thu, 7 Jul 2011 06:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.41 X-Spam-Level: X-Spam-Status: No, score=-106.41 tagged_above=-999 required=5 tests=[AWL=0.189, 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 bdEWodXRK1sb for ; Thu, 7 Jul 2011 06:36:21 -0700 (PDT) Received: from mail216.messagelabs.com (mail216.messagelabs.com [85.158.143.99]) by ietfa.amsl.com (Postfix) with SMTP id 91B9721F8587 for ; Thu, 7 Jul 2011 06:36:18 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-5.tower-216.messagelabs.com!1310045775!10500046!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 1631 invoked from network); 7 Jul 2011 13:36:15 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-5.tower-216.messagelabs.com with SMTP; 7 Jul 2011 13:36:15 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id C919D1EB83D3 for ; Thu, 7 Jul 2011 15:36:15 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 7 Jul 2011 15:36:15 +0200 From: "Elwell, John" To: "siprec@ietf.org" Date: Thu, 7 Jul 2011 15:36:14 +0200 Thread-Topic: Comment on metadata-02 - Media Stream Thread-Index: Acw8qtezJdNopWF7RZqONH6e5tBRLg== 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] Comment on metadata-02 - Media Stream X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 13:36:21 -0000 In section 6.5, Media Stream seems to be defined as follows: "A Media Stream block MUST have properties of media as seen by SRC and sent to SRS." Ignoring the possibly inappropriate RFC 2119 language, I don't think this c= learly defines whether: a) this represents a medium of the CS (i.e., corresponding to a media descr= iption in the CS SDP); or b) this represents a medium of the RS (i.e., corresponding to a media descr= iption in the RS SDP). Both of these are "seen by SRC". There need not be a 1:1 relationship betwe= en the two, and hence we need to make it clear which it represents. Although personally I had expected a), a couple of threads in recent months= have seemed to indicate b) is the general consensus. Possibly a definition like: "A Media Stream block represents a single RTP session between an SRC and an= SRS. Note that, because of possible mixing at the SRC, a Media Stream bloc= k does not necessarily represent a single RTP session between CS participan= ts." However, if we accept this principle, I wonder what the Start Time and End = Time attributes mean. The start and end of an RS RTP session correspond to = the relevant offer-answer exchanges, so they don't really need to be in XML= . So I suspect I still haven't drilled down into the real meaning of MS suf= ficiently. John (as individual) = From john.elwell@siemens-enterprise.com Thu Jul 7 06:37:27 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2371421F8619 for ; Thu, 7 Jul 2011 06:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.419 X-Spam-Level: X-Spam-Status: No, score=-106.419 tagged_above=-999 required=5 tests=[AWL=0.180, 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 3IOwoHThUROX for ; Thu, 7 Jul 2011 06:37:26 -0700 (PDT) Received: from mail21.messagelabs.com (mail21.messagelabs.com [85.158.143.35]) by ietfa.amsl.com (Postfix) with SMTP id 47B0921F85A9 for ; Thu, 7 Jul 2011 06:37:26 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-15.tower-21.messagelabs.com!1310045836!42743087!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 10352 invoked from network); 7 Jul 2011 13:37:16 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-15.tower-21.messagelabs.com with SMTP; 7 Jul 2011 13:37:16 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id C69F923F03E2 for ; Thu, 7 Jul 2011 15:37:17 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 7 Jul 2011 15:37:17 +0200 From: "Elwell, John" To: "siprec@ietf.org" Date: Thu, 7 Jul 2011 15:37:16 +0200 Thread-Topic: Question on current speaker video Thread-Index: Acw8qvyln0YwIJofTL6nlIWCMtcIuQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] Question on 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: Thu, 07 Jul 2011 13:37:27 -0000 Consider a CS with a single video medium that is used by an MCU to show the= current speaker. All participants receive that medium. However, at any one= time only one participant is contributing to the medium. Now suppose there is an SRC that sends that medium (unmixed with any other = medium) to an SRS. The metadata would represent this as a single MS element= . There would also be n Participant elements (assuming sufficient informati= on is available to the SRC). I assume that we would simply say that all n P= articipants are contributing to that MS, and all n Participants are recipie= nts of that MS. Then there is no need to update the metadata every time the= speaker changes (which could be very frequently). Similarly for an audio bridge that filters out all but the loudest speaker = or speakers. That could be signalled in RTP using https://datatracker.ietf.= org/doc/draft-ietf-avtext-mixer-to-client-audio-level/, but would not be si= gnalled by rapid updates of metadata. Can folks confirm this is a correct understanding? It might require mention= in the metadata draft, or possibly in the architecture draft. John From Leon.Portman@nice.com Thu Jul 7 06:44: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 970C321F867E for ; Thu, 7 Jul 2011 06:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.373 X-Spam-Level: X-Spam-Status: No, score=-2.373 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id puErdgjdh8cM for ; Thu, 7 Jul 2011 06:44:52 -0700 (PDT) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id 8A1A721F867A for ; Thu, 7 Jul 2011 06:44:51 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.15]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Thu, 7 Jul 2011 16:44:44 +0300 From: Leon Portman To: "Parthasarathi R (partr)" , "siprec@ietf.org" Date: Thu, 7 Jul 2011 16:44:42 +0300 Thread-Topic: Caller preference information in Metadata Thread-Index: Acw8nlS7CXumifrDQ9SGZ9au5tuPnQADYI7g Message-ID: <07465C1D981ABC41A344374066AE1A2C38AFE9BB8A@TLVMBX01.nice.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_07465C1D981ABC41A344374066AE1A2C38AFE9BB8ATLVMBX01nicec_" MIME-Version: 1.0 Subject: Re: [siprec] Caller preference information in 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: Thu, 07 Jul 2011 13:44:52 -0000 --_000_07465C1D981ABC41A344374066AE1A2C38AFE9BB8ATLVMBX01nicec_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Partha Hi Today we are not receive and store this information. Is it widely accepted= ? Leon From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Parthasarathi R (partr) Sent: Thursday, July 07, 2011 3:07 PM To: siprec@ietf.org Subject: [siprec] Caller preference information in Metadata Hi all, Caller preference (RFC 3841) information about CS is possible to be passed = in extension data of participant. The caller preference like "automata" sha= ll be passed in SIPREC metadata itself in case folks are interested. Please= let me know whether "caller preference" attribute shall be added under par= ticipant block. Thanks Partha --_000_07465C1D981ABC41A344374066AE1A2C38AFE9BB8ATLVMBX01nicec_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Partha Hi=

 <= /p>

Today we are not receive and store  thi= s information. Is it widely accepted?

 

Leon=

 <= /p>

From: siprec-bounces@ietf.org [mailto:s= iprec-bounces@ietf.org] On Behalf Of Parthasarathi R (partr)
S= ent: Thursday, July 07, 2011 3:07 PM
To: siprec@ietf.org
<= b>Subject: [siprec] Caller preference information in Metadata

 

Hi all,

 =

Caller preference (RFC 3841) informat= ion about CS is possible to be passed in extension data of participant. The= caller preference like "automata" shall be passed in SIPREC meta= data itself in case folks are interested. Please let me know whether "= caller preference" attribute shall be added under participant block.

 

Thanks

Par= tha

= --_000_07465C1D981ABC41A344374066AE1A2C38AFE9BB8ATLVMBX01nicec_-- From partr@cisco.com Thu Jul 7 06:45: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 D082021F867D for ; Thu, 7 Jul 2011 06:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.968 X-Spam-Level: X-Spam-Status: No, score=-9.968 tagged_above=-999 required=5 tests=[AWL=0.031, 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 ezAP5xd32Fef for ; Thu, 7 Jul 2011 06:45:17 -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 2275521F867A for ; Thu, 7 Jul 2011 06:45:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=35685; q=dns/txt; s=iport; t=1310046316; x=1311255916; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=iUxQFEpzhd+Rr4Tkfju5EhsVBKKu6ILyGNz0hund9SE=; b=aTalG6fTsqOwNdwraSAlB8yDgLXqSC1wpIR4E5urKnZAgaSyEACFheiQ lY94MtsJqAKLsrzDrG+0Jiok/cBtmiN45/5edzrVhxsphN9zYkipUjQNg qlN25fTQM+D0cPI2NZ6DgCeFDGV3oeSWu5kvAxoMApbb+y7riV607QszM Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoBAEi3FU5Io8US/2dsb2JhbABTmGWPNneIe6RanXKGOASHR5AFi0M X-IronPort-AV: E=Sophos;i="4.65,493,1304294400"; d="scan'208";a="100139307" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-1.cisco.com with ESMTP; 07 Jul 2011 13:45:12 +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 p67DjCf7025603; Thu, 7 Jul 2011 13:45:12 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Jul 2011 19:15:12 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Jul 2011 19:15:12 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Content (RFC 4796) attribute in SDP or XML Thread-Index: Acw0mPHhxfeVJEDcQLSYWo3IAZGl7wABDbXgACpfOfAADTnVAAA/CH7wAL12yxAADByJIAAdm3FgAADcErAAQaGFkAAC7JoQAAMpvCAAAObikAAasOngAAJiC3AAGcWykAAW4scQAAPQnyAACOotkAABydoA References: <07465C1D981ABC41A344374066AE1A2C38AF6D40CC@TLVMBX01.nice.com><07465C1D981ABC41A344374066AE1A2C38AF6D4376@TLVMBX01.nice.com><07465C1D981ABC41A344374066AE1A2C38AFE9B1C0@TLVMBX01.nice.com> <35BCE99A477D6A4986FB2216D8CF2CFD06E358D2@XMB-BGL-417.cisco.com> From: "Parthasarathi R (partr)" To: "Elwell, John" , "Charles Eckel (eckelcu)" , "Ram Mohan R (rmohanr)" , "Leon Portman" , X-OriginalArrivalTime: 07 Jul 2011 13:45:12.0244 (UTC) FILETIME=[180CDF40:01CC3CAC] Subject: Re: [siprec] Content (RFC 4796) attribute in SDP or XML X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 13:45:19 -0000 John, Thanks for your agreement for Content (RFC 4796) attribute in SDP. Thanks Partha > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > Sent: Thursday, July 07, 2011 7:05 PM > To: Parthasarathi R (partr); Charles Eckel (eckelcu); Ram=20 > Mohan R (rmohanr); Leon Portman; siprec@ietf.org > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML >=20 >=20 >=20 > > -----Original Message----- > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > Sent: 07 July 2011 13:02 > > To: Elwell, John; Charles Eckel (eckelcu); Ram Mohan R=20 > (rmohanr); Leon=20 > > Portman; siprec@ietf.org > > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML > > > > John, > > > > I understand your mixed video scenario. In case of mixed audio or=20 > > video, it is not possible to retrieve the complete=20 > information in SRS=20 > > as it is pre-mixed at SRC. It is one of the motivation for=20 > having two=20 > > m-line with non-mixed stream to SRS. The similar issue is raised by=20 > > Charles earlier for mixed audio stream wherein current speaker=20 > > (participant) has to be noticed using metadata XML. Even in case of=20 > > mixed audio stream, the loss of some information is=20 > unavoidable. Hope=20 > > you agree here. In case the intent is to create the infrastructure=20 > > wherein the mixed stream should not loose the information, then we=20 > > need the separate discussion. > > > > I will write the separate mail thread for the architecture=20 > > clarification in SRC wherein CS is handling by one SIP UA=20 > instance and=20 > > RS is handled as separate SIP UA instance. > > > > SDP is reused for RS media description, in case it is not=20 > possible for=20 > > SDP to express about specific media description then it is=20 > better to=20 > > generically develop the extension like IANA registration=20 > for RFC 4796=20 > > which helps for other similar mixing applications as well. > [JRE] Yes, I am in agreement with using the IANA registry for=20 > RFC 4796, and extending it where necessary. My only question=20 > was whether these values are most appropriately sent in SDP or in XML. >=20 > > > > From the metadata perspective, Stream in XML is pointing=20 > to m-line of=20 > > SDP using label attributes. > [JRE] Yes, I had forgotten that. I recall an earlier=20 > misunderstanding to do with this. I don't think that is clear=20 > in the metadata draft, so I will comment separately on that.=20 > However, if this is the common understanding, I can see that=20 > using the a=3Dcontent attribute in the RS SDP would be a viable=20 > solution. >=20 > John (as individual) >=20 >=20 >=20 > > SDP points to raw media. XML is used to create association which is=20 > > not possible in SDP. Participant, session to Stream grouping is not=20 > > possible to achieve in SDP which forces us to look for XML=20 > > representation. But in case of content-type scenario, it=20 > is possible=20 > > to make it happen. > > > > Please read inline > > > > Thanks > > Partha > > > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > Sent: Thursday, July 07, 2011 12:36 PM > > > To: Charles Eckel (eckelcu); Ram Mohan R (rmohanr);=20 > Parthasarathi R=20 > > > (partr); Leon Portman; siprec@ietf.org > > > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML > > > > > > Charles, > > > > > > I see how it COULD be done in the way you describe. I=20 > just feel it=20 > > > is architecturally wrong to describe the CS MS as part of=20 > the RS MS=20 > > > description (i.e., the RS SDP). > > > > In case the intent is to pass CS MS description, I=20 > agree with=20 > > you. IIRC, charles proposed to use the explicit mixed content-type=20 > > which is more appropriate to be passed in RS SDP to provide the=20 > > description about that specific media. > > > > > > > > However, I can also give a more specific reason. Suppose CS > > > MS1 is slides and CS MS2 is speaker video. But the XML=20 > does not tell=20 > > > me that CS MS1 is slides and CS MS1 is speaker video. Both CS MS1=20 > > > and CS MS2 are combined into RS MS1 (slides + speaker). > > > > The question here is how it is possible for any UA to=20 > > represent > > (slides+speaker) in SDP? In case it is not well defined,=20 > let us work=20 > > for it > > > > The XML metadata tells me that at a given > > > time Participant P1 contributed to CS MS1 and P2=20 > contributed to CS=20 > > > MS2. How can I tell that P1 contributed to slides and > > > P2 contributed to speaker? > > > > In the mixed stream, we lose the data in SRC=20 > because actual=20 > > media is mixed. The system shall be designed to send the=20 > media stream=20 > > separately or we have to find the generic way to group the stream=20 > > together > > > > > > > > See also below: > > > > > > > -----Original Message----- > > > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > > Sent: 06 July 2011 21:05 > > > > To: Ram Mohan R (rmohanr); Elwell, John; Parthasarathi R > > > (partr); Leon > > > > Portman; siprec@ietf.org > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML > > > > > > > > RFC 4796 has registered the following values: > > > > > > > > slides RFC 4796 Presentation slides > > > > speaker RFC 4796 Image from the speaker > > > > sl RFC 4796 Sign language > > > > main RFC 4796 Main media stream > > > > alt RFC 4796 Alternative=20 > media stream > > > > > > > > Suppose we register the following new values: > > > > > > > > siprec1 RFC xxxx SIPREC value 1 > > > > siprec2 RFC xxxx SIPREC value 2 > > > > siprec3 RFC xxxx SIPREC value 3 > > > > > > > > If the CS has a media lines with the following content=20 > attributes > > > > > > > > CS MS1 - slides > > > > CS MS2 - main > > > > CS MS3 - siprec1 > > > > CS MS4 - siprec2 > > > > > > > > SRC sends two media streams to RS. RS MS1 is essentially > > CS MS1. RS > > > > MS2 is some composition of CS MS2, CS MS3 and CS MS4. > > > > This could be represented using the content attribute as: > > > > > > > > RS MS1 - slides > > > > RS MS2 - main, siprec1, siprec2 > > > > > > > > If this is all we think is required, using the content > > > attribute does > > > > seem sufficient. However, my understanding is people want > > > to be able > > > > to convey something other than the simple concatenation > > of content > > > > attribute values, and for that reason, prefer to use=20 > XML. In this=20 > > > > case, the desired set of values is not bound by=20 > anything we will=20 > > > > define in SIPREC. That is my understanding as to why XML is > > > preferred > > > > over the RFC > > > > 4796 content attribute. > > > [JRE] That was not my motivation, but perhaps others had > > that in mind. > > > > > > John (as individual) > > > > > > > > > > > Cheers, > > > > Charles > > > > > > > > > > > > > -----Original Message----- > > > > > From: Ram Mohan R (rmohanr) > > > > > Sent: Wednesday, July 06, 2011 12:33 AM > > > > > To: Elwell, John; Parthasarathi R (partr); Charles Eckel > > > (eckelcu); > > > > Leon Portman; siprec@ietf.org > > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in=20 > SDP or XML > > > > > > > > > > Just on this one > > > > > > > > > > > RS media stream is a mixed content type stream > > > > of "current > > > > > > speaker video" and "room video" and the resultant shall > > > > be named as > > > > > > "mixed current speaker video & room video" which shall be > > > > passed as > > > > > > new content type extension to SRS > > > > > [JRE] Right, so you agree this can't be passed in the RS > > > > SDP. I would > > > > challenge the need to define > > > > > (and register) a new RFC 4796 value "mixed current > > speaker video & > > > > room video". We have two MS > > > > > elements (representing the two CS video streams for > > > current speaker > > > > and room. Why can't we just place > > > > > the respective RFC 4796 content types in the respective > > > MS elements? > > > > And why does it need to be as > > > > > extension data - why can't it be standardized from day one? > > > > > > > > > > My thought here is since we have new content types > > "mixed current > > > > speaker video & room video" we need > > > > > to register/extend RFC 4796 for the same and send in RS > > > SDP. I would > > > > prefer this approach instead of > > > > > sending it through recording metadata XML. Of course=20 > we need to > > > > discuss this in AVT to get their > > > > > opinion. > > > > > > > > > > Regards, > > > > > Ram > > > > > > > > > > > -----Original Message----- > > > > > > From: siprec-bounces@ietf.org > > > [mailto:siprec-bounces@ietf.org] On > > > > > > Behalf Of Elwell, John > > > > > > Sent: Wednesday, July 06, 2011 12:05 PM > > > > > > To: Parthasarathi R (partr); Charles Eckel (eckelcu); > > > > Leon Portman; > > > > > > siprec@ietf.org > > > > > > Subject: Re: [siprec] Content (RFC 4796) attribute in > > SDP or XML > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > > > > Sent: 05 July 2011 19:06 > > > > > > > To: Charles Eckel (eckelcu); Leon Portman; Elwell, John;=20 > > > > > > > siprec@ietf.org > > > > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in > > > SDP or XML > > > > > > > > > > > > > > John, > > > > > > > > > > > > > > Please read inline. > > > > > > > > > > > > > > Thanks > > > > > > > Partha > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Charles Eckel (eckelcu) > > > > > > > > Sent: Tuesday, July 05, 2011 10:44 PM > > > > > > > > To: Leon Portman; Elwell, John; Parthasarathi R=20 > (partr);=20 > > > > > > > > siprec@ietf.org > > > > > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in > > > > SDP or XML > > > > > > > > > > > > > > > > Okay by me. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Charles > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > > > > > > > > Sent: Tuesday, July 05, 2011 8:42 AM > > > > > > > > > To: Elwell, John; Parthasarathi R (partr);=20 > Charles Eckel > > > > > > > (eckelcu); > > > > > > > > > siprec@ietf.org > > > > > > > > > Subject: RE: [siprec] Content (RFC 4796) > > > attribute in SDP or > > > > XML > > > > > > > > > > > > > > > > > > I completely agree with the below. > > > > > > > > > > > > > > > > > > Leon > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Elwell, John > > > > [mailto:john.elwell@siemens-enterprise.com] > > > > > > > > > Sent: Tuesday, July 05, 2011 5:44 PM > > > > > > > > > To: Parthasarathi R (partr); Leon Portman;=20 > Charles Eckel > > > > > > > (eckelcu); > > > > > > > > > siprec@ietf.org > > > > > > > > > Subject: RE: [siprec] Content (RFC 4796) > > > attribute in SDP or > > > > XML > > > > > > > > > > > > > > > > > > (as chair) > > > > > > > > > We should try to avoid opening up old issues.=20 > I think we > > > > > > > > had agreed that: > > > > > > > > > - RS SDP describes the RS, and therefore just > > > describes how > > > > > > > > recordable media is delivered to the SRS. > > > > > > > > > It does not describe how media is delivered between CS > > > > > > > > endpoints as part of the CS. > > > > > > > > > - Therefore anything to do with the CS (i.e., > > the session > > > > being > > > > > > > > > recorded) needs to be delivered to the SRS as metadata > > > > > > > > (i.e., in XML). > > > > > > > > > - We don't see a need to standardize delivery=20 > of things > > > > > > > > like CS codecs > > > > > > > > > in the metadata, but that could be done using the > > > extension > > > > > > > > mechanism. > > > > > > > > > > > > > > > > Hope everyone agree here that CS SDP > > > > information could be > > > > > > > passed as extension-data. attribute within > > > > > > > > > > > may help to achieve this requirement. > > > > > > [JRE] Or even as the standardized part of an MS element > > > > if we wish. > > > > > > > > > > > > > > > > > > > > > > Focusing now on the content attribute, I don't > > > > think there is > > > > any > > > > > > > > > disagreement that the SRS needs to know the=20 > content type > > > > (e.g., > > > > > > > > > presentation) of a media stream. The SRC can obtain > > > > this from > > > > the > > > > > > > > > a=3Dcontent attribute of the CS SDP. The > > discussion is about > > > > > > > > whether this content attribute should be conveyed > > > to the SRS: > > > > > > > > > A) as an a=3Dcontent attribute of the RS SDP, or > > > > > > > > > B) within the metadata XML. > > > > > > > > > > > > > > > > > > (as individual) > > > > > > > > > According to past decisions, there is perhaps > > an argument > > > > > > > > for B). If, > > > > > > > > > for example, we wanted to convey the fact that > > a CS media > > > > > > > > stream was > > > > > > > > > subject to 256-bit encryption, this=20 > information would go > > > > > > > in the XML > > > > > > > > > > > > > > Here I have the doubt. In case 256-bit > > > > encryption is not > > > > > > used > > > > > > > by RS SDP, Please let me know the reason for > > passing the key > > > > > > > information to SRS because RS SDP is not=20 > encrypted in that=20 > > > > > > > fashion. > > > > > > > > > > [JRE] I did not suggest passing the CS keying material to > > > > the SRS. I > > > > > > just suggested passing the information that the CS media > > > > stream used > > > > > > 256 bit encryption. Perhaps this was a bad example - > > it was just > > > > meant > > > > > > to illustrate the general principle that information > > > about the CS > > > > > > should be passed in metadata XML. > > > > > > > > > > > > > > > > > > > > > > (it can't go in the RS SDP, because the RS=20 > might not use > > > > > > > > 256-bit encryption. Similarly, one could argue that the=20 > > > > > > > > content type of a CS media stream should go in the > > > XML, not in > > > > > > > > the RS SDP. > > > > > > > I'm seeing content-type attribute as one of > > > > the extension > > > > of > > > > > > > SDP a=3D attribute. In general, it is possible to convert = CS > > > > > > mediastream > > > > > > > content type to RS media stream content type=20 > because SRC RS=20 > > > > > > > media stream is formed based on CS media stream > > except for the > > > > mixing scenarios > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I could even imagine cases where the content > > type of a CS > > > > > > > > media stream > > > > > > > > > does not equal the content type of an RS media stream, > > > > > > > > e.g., where the > > > > > > > > > SRC combines the current speaker video and the > > room video > > > > > > > into two > > > > > > > > > videos side-by-side in the same RS media stream. > > > > > > > > > > > > > > RS media stream is a mixed content type stream of > > > > "current > > > > > > > speaker video" and "room video" and the resultant > > > shall be named > > > > as > > > > > > > "mixed current speaker video & room video" which > > > shall be passed > > > > > > > as new content type extension to SRS > > > > > > [JRE] Right, so you agree this can't be passed in the > > RS SDP. I > > > > would > > > > > > challenge the need to define (and register) a new RFC > > 4796 value > > > > "mixed > > > > > > current speaker video & room video". We have two MS=20 > elements=20 > > > > > > (representing the two CS video streams for current > > > > speaker and room. > > > > > > Why can't we just place the respective RFC 4796 content > > > > types in the > > > > > > respective MS elements? And why does it need to be as > > > > extension data > > > > - > > > > > > why can't it be standardized from day one? > > > > > > > > > > > > John (as individual) > > > > > > > > > > > > > > > > > > > > In the > > > > > > > > metadata these would be two media streams, each > > > with its own > > > > > > > > content type, but both would refer to the same RS > > > > media stream. > > > > > > > > > > > > > > > > It will be problematic approach because the > > > > actual media > > > > and > > > > > > > metadata are not related explicitly. As per the current > > > > description, > > > > > > > there are two element with different > > unique-id uses > > > > > > > same label in SDP with different XML element > > ("content-type") > > > > > > > within them. > > > > The > > > > > > > issue is whether media has stream1 behavior or stream2 > > > > behavior or > > > > > > > mixed. We will able to extent XML element for=20 > having single=20 > > > > > > > interpretation but it is not fully clarified in the > > > > draft now. The > > > > > > > bottom-up matching like stream1 & stream2 has same > > > label element > > > > > > > and it has to be grouped together is not explicit in this=20 > > > > > > > scenario. We > > > > need > > > > > > > more investigation both information is required but not > > > > the actual > > > > > > > media. Please correct me in I'm missing something=20 > > > > > > > > > > > > > > > > > John > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Parthasarathi R (partr)=20 > [mailto:partr@cisco.com] > > > > > > > > > > Sent: 04 July 2011 08:08 > > > > > > > > > > To: Leon Portman; Charles Eckel (eckelcu); > > > Elwell, John; > > > > > > > > > > siprec@ietf.org > > > > > > > > > > Subject: RE: [siprec] Content (RFC 4796) > > > > attribute in SDP or > > > > > > XML > > > > > > > > > > > > > > > > > > > > Leon, > > > > > > > > > > > > > > > > > > > > Please read inline. > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > Partha > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > > > > > > > > > > Sent: Monday, July 04, 2011 12:11 PM > > > > > > > > > > > To: Parthasarathi R (partr); Charles Eckel > > (eckelcu); > > > > Elwell, > > > > > > > > > > > John; siprec@ietf.org > > > > > > > > > > > Subject: RE: [siprec] Content (RFC 4796) > > attribute in > > > > > > > SDP or XML > > > > > > > > > > > > > > > > > > > > > > Partha Hi > > > > > > > > > > > > > > > > > > > > > > Please see below. > > > > > > > > > > > > > > > > > > > > > > Leon > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Parthasarathi R (partr) > > [mailto:partr@cisco.com] > > > > > > > > > > > Sent: Sunday, July 03, 2011 7:50 PM > > > > > > > > > > > To: Leon Portman; Charles Eckel (eckelcu); > > > Elwell, John; > > > > > > > > > > > siprec@ietf.org > > > > > > > > > > > Subject: RE: [siprec] Content (RFC 4796) > > attribute in > > > > > > > SDP or XML > > > > > > > > > > > > > > > > > > > > > > Leon, > > > > > > > > > > > > > > > > > > > > > > Please read inline. > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > Partha > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > > > > > > > > > > Sent: Sunday, July 03, 2011 4:13 PM > > > > > > > > > > > To: Charles Eckel (eckelcu); Elwell, John; > > > > Parthasarathi R > > > > > > > > > > > (partr); siprec@ietf.org > > > > > > > > > > > Subject: RE: [siprec] Content (RFC 4796) > > attribute in > > > > > > > SDP or XML > > > > > > > > > > > > > > > > > > > > > > I do prefer that metadata XML will be as > > > > self-contained as > > > > > > > > > > > possible and not rely on conveying some=20 > data via RS > > > > > > > SDP. RS SDP > > > > > > > > > > > should only be used to recording establishment and > > > > > > > > negotiation and > > > > > > > > > > > not as a mechanism for metadata reporting. > > > > > > > > > > > > > > > > > > > > > > In case Metadata XML has to be > > > self-contained, > > > > the > > > > > > > > > > > complete SDP has to be converted into XML=20 > format or > > > > > > > > else XML has > > > > > > > > > > > to have sort of XML attribute which > > > > carries SDP. > > > > > > > > > > > Creating mapping for each SDP attribute > > with metadata > > > > > > > > XML element > > > > > > > > > > > does not seems to be feasible > > > > > > > > > > > > > > > > > > > > > > [LeonP] But if CS SDP is different from RS SDP, > > > > > > > anyway you will > > > > > > > > > > > need to encapsulate the original RS SDP, so > > why not in > > > > XML? > > > > > > > > > > > > > > > > > > > > I guess that the confusion is here. In the > > > > > > > > current format, > > > > > > > > > > RS SDP is only carried towards SRS and CS SDP is not > > > > forwarded. > > > > > > > > > > This design > > > > > > > > > > is closed as part of ticket #71 > > > > > > > > > > > > > > > > > > (http://www.ietf.org/mail- > > > > > > archive/web/siprec/current/msg02106.html). > > > > > > > > > > Please bring up with the usecase for CS SDP > > if required > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Otherwise we will not be able to reuse same > > format for > > > > > > > > reporting > > > > > > > > > > > metadata via web services As per > > IETF-80 and > > > > > > > > last interim > > > > > > > > > > > meeting, there is no intent of reusing=20 > this metadata > > > > > > > > XML in other > > > > > > > > > > > protocol. In case reusing same format for=20 > webservice > > > > > > > or XMPP is > > > > > > > > > > > the intent, the current metadata XML > > mechanism is not > > > > > > > > the appropriate. > > > > > > > > > > > This was discussed in > > > > > > > > > > > > > > > > > > > > > > >=20 > http://www.ietf.org/mail-archive/web/siprec/current/msg02151.html, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > http://www.ietf.org/mail- > > > > > > archive/web/siprec/current/msg02155.html(1s > > > > > > > > > > t > > > > > > > > > > > point in format slide). In case you have=20 > difference > > > > > > > of opinion > > > > > > > > > > > even after this multiple discussion, let us again > > > > > > > > discuss at IETF-81. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [LeonP] I was not proposing replacing SIP > > with another > > > > > > > > transport > > > > > > > > > > > layer, just wanted to keep other options open. > > > > > > > > > > > > > > > > > > > > Current metadata format is=20 > customized for SIP > > > > > > > > transport. In > > > > > > > > > > case we need to keep the options open, the format > > > > has to be > > > > > > > > > > revisited from the scratch. In our=20 > analysis, we notice > > > > > > > that REST > > > > > > > > > > architecture with Metadata XML is best fit for > > > HTTP, XMPP > > > > > > > > > > > > > > > > > > > > > > > > > > > > I am > > > > > > > > > > > very big supporter for metadata over SIP reporting > > > > > > > > > > > > > > > > > > > > > Thanks, Me too.. > > > > > > > > > > > > > > > > > > > > > or as dedicated SIP session. > > > > > > > > > > > In case Metadata is separate session > > > > from RS, RS > > > > > > > > > > > attribute like RS-id MUST be included within > > > > XML. This was > > > > > > > > > > > discussed at > > > > > > > > > > > http://www.ietf.org/mail- > > > > > > archive/web/siprec/current/msg02013.h > > > > > > > > > > tml. Could you please explain reason for=20 > the dedicated > > > > > > > > SIP > session > > > > > > > > > > for metadata. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [LeonP] The main use case is Recording on > > > > Demand, that is > > > > > > > > > > > triggered by SRS. In such case it will be > > very useful > > > > > > > > to have just > > > > > > > > > > > one SIP session and send all metadata over it > > > (like CTI > > > > > > > > > > > link) and then only trigger recording (via > > > external SRC > > > > > > > > > > > interface) only for specific call segments. > > > > > > > > > > > > > > > > > > > > > I understand the current > > implementation wherein > > > > > > > > few of the > > > > > > > > > > metadata like CDR records is passed through non-sip > > > > > > > > interface. It is > > > > > > > > > > outside the scope of SIPREC. The global-id in format > > > > > > > > shall be used > > > > > > > > > > to correlate. Please let me know in case any current > > > > > > > > SIPREC metadata > > > > > > > > > > attribute MUST be passed through this CTS link. > > > > > > > > > > > > > > > > > > > > > > > > As for examples, the basic information as > > media type, > > > > labels, > > > > > > > > > > > volume etc. Any application level data can be > > > relevant. > > > > Even > > > > > > > > > > > indication of encryption (for a case=20 > where RS is not > > > > > > > encrypted) > > > > > > > > > > > > > > > > > > > > > > Leon > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: siprec-bounces@ietf.org=20 > > > > > > > > > > > [mailto:siprec-bounces@ietf.org] On Behalf > > Of Charles > > > > Eckel > > > > > > > > > > (eckelcu) > > > > > > > > > > > Sent: Wednesday, June 29, 2011 7:17 PM > > > > > > > > > > > To: Elwell, John; Parthasarathi R (partr); > > > > siprec@ietf.org > > > > > > > > > > > Subject: Re: [siprec] Content (RFC 4796) > > attribute in > > > > > > > SDP or XML > > > > > > > > > > > > > > > > > > > > > > I think it is sufficient, especially since we > > > can assign > > > > new > > > > > > > > > > > values if necessary. > > > > > > > > > > > Are there any examples of what people think they > > > > > > > might want to > > > > > > > > > > > capture in the SDP and/or metadata field? > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > Charles > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: siprec-bounces@ietf.org > > > > > > > > [mailto:siprec-bounces@ietf.org] > > > > > > > > > > > > On > > > > > > > > > > > Behalf Of Elwell, John > > > > > > > > > > > > Sent: Tuesday, June 28, 2011 3:11 AM > > > > > > > > > > > > To: Parthasarathi R (partr); siprec@ietf.org > > > > > > > > > > > > Subject: Re: [siprec] Content (RFC 4796) > > > attribute in > > > > > > > > SDP or XML > > > > > > > > > > > > > > > > > > > > > > > > I would like other opinions on whether the > > > > SDP a=3Dcontent > > > > > > > > > > > attribute in > > > > > > > > > > > the RS SDP has the correct > > > > > > > > > > > > semantics for representing the content=20 > type of the > > > > > > > > > > recorded CS media > > > > > > > > > > > stream. > > > > > > > > > > > > > > > > > > > > > > > > John > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > From: Parthasarathi R (partr) > > > > [mailto:partr@cisco.com] > > > > > > > > > > > > > Sent: 28 June 2011 10:45 > > > > > > > > > > > > > To: Elwell, John; siprec@ietf.org > > > > > > > > > > > > > Cc: Ram Mohan R (rmohanr); Paul Kyzivat > > (pkyzivat) > > > > > > > > > > > > > Subject: RE: Content (RFC 4796) attribute > > > in SDP or > > > > XML > > > > > > > > > > > > > > > > > > > > > > > > > > John, > > > > > > > > > > > > > > > > > > > > > > > > > > In case if it is the argument of whether CS > > > > MS content > > > > > > > > > > > type or RS MS > > > > > > > > > > > > > > > > > > > > > > > > content type in the metadata, it is > > > better for us to > > > > > > > > > > > re-open ticket > > > > > > > > > > > > > #71 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > (http://www.ietf.org/mail- > > > > > > archive/web/siprec/current/msg02106.html). > > > > > > > > > > > > > Please let me know your opinion here. > > > > > > > > > > > > > > > > > > > > > > > > > > The basic idea in metadata format is to > > re-use as > > > > > > > > much as SDP > > > > > > > > > > > > > attribute (like direction, content) in > > > > media level for > > > > > > > > > > RS dialog > > > > > > > > > > > > > (using SDP label attribute as a pointer) until > > > > otherwise > > > > > > > > > > > there is a > > > > > > > > > > > > > restriction in using in such manner. As per > > > > RFC 4796, > > > > > > > > > > there is no > > > > > > > > > > > > > such restriction and so, I prefer to reuse > > > > as content > > > > SDP > > > > > > > > > > > attribute > > > > > > > > > > > > > rather than introducing the new > > > > > > > element for > > > > > > > > > > > > > this purpose. > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > Partha > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > From: Elwell, John > > > > > > > > [mailto:john.elwell@siemens-enterprise.com] > > > > > > > > > > > > > Sent: Monday, June 27, 2011 1:18 PM > > > > > > > > > > > > > To: Parthasarathi R (partr); siprec@ietf.org > > > > > > > > > > > > > Cc: Ram Mohan R (rmohanr); Paul Kyzivat > > (pkyzivat) > > > > > > > > > > > > > Subject: RE: Content (RFC 4796) attribute > > > in SDP or > > > > XML > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > From: Parthasarathi R (partr) > > > > [mailto:partr@cisco.com] > > > > > > > > > > > > > > Sent: 27 June 2011 08:08 > > > > > > > > > > > > > > To: siprec@ietf.org; Elwell, John > > > > > > > > > > > > > > Cc: Ram Mohan R (rmohanr); Paul Kyzivat > > > (pkyzivat) > > > > > > > > > > > > > > Subject: Content (RFC 4796) attribute in > > > > SDP or XML > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > > > > > > > > > > > As per the last interim SIPREC meeting, > > > there is a > > > > > > > > > > consensus to > > > > > > > > > > > > > > describe the content of an MS using RFC > > > 4796 & its > > > > > > > > > > > > > extension. As per > > > > > > > > > > > > > > RFC 4796, the multiple instance of > > > > content attribute > > > > > > > > > > is possible > > > > > > > > > > > to > > > > > > > > > > > > > > exist in SDP which shall be used in > > RS SDP. SRS > > > > > > > > shall group > > > > > > > > > > > > > the same > > > > > > > > > > > > > > media content types by "content" > > attribute in RS > > > > > > > > SDP. We are > > > > > > > > > > > > > > interested in knowing any specfic > > > reason for this > > > > > > > > > > > attribute to be > > > > > > > > > > > > > > duplicated in Metadata XML. > > > > > > > > > > > > > [JRE] I don't have a reason for=20 > **duplication**. > > > > > > > > > > However, I think > > > > > > > > > > > > > there is a valid question to be asked > > whether the > > > > content > > > > > > > > > > > type of an > > > > > > > > > > > > > > > > > > > > > > > > MS should be represented: > > > > > > > > > > > > > A) in XML; or > > > > > > > > > > > > > B) in RS SDP as a=3Dcontent. > > > > > > > > > > > > > > > > > > > > > > > > > > The content type we are talking about is an > > > > MS content > > > > > > > > > > > type, i.e., > > > > > > > > > > > > > relating to the CS. One could argue that the > > > > > > > > > > > corresponding RS stream > > > > > > > > > > > > > > > > > > > > > > > > is NOT the same content type. For example: > > > > > > > > > > > > > - CS MS content type is "slides". > > > > > > > > > > > > > - RS media stream content type is=20 > "recording of > > > > slides". > > > > > > > > > > > > > > > > > > > > > > > > > > On this basis, I think the correct option for > > > > > > > > conveying the MS > > > > > > > > > > > content > > > > > > > > > > > > > type "slides" is A) (in the XML). > > > > > > > > > > > > > > > > > > > > > > > > > > Note that this would not involve > > > > duplication. The SDP > > > > > > > > > > > > > a=3Dcontent attribute is optional, so we > > > need not use > > > > > > > > it for the RS. > > > > > > > > > > > > > > > > > > > > > > > > > > Perhaps my distinction is too > > > theoretical, but I do > > > > > > > > > > feel a little > > > > > > > > > > > more > > > > > > > > > > > > > comfortable using the XML rather than > > the RS SDP. > > > > > > > > > > > > > > > > > > > > > > > > > > John (as individual) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > > > > > > > > > > > Partha > > > > > > > > > > > > > > > > > > > > > > > > > > > > last Interim SIPREC meeting Note: > > > > > > > > > > > > > > > > > > > > > > > > > > > > Slide 7: On the question of how to > > describe the > > > > content > > > > > > > > > > > of an MS, > > > > > > > > > > > > > > there was no objection to basing this > > > on the types > > > > in > > > > > > > > > > > the RFC 4796 > > > > > > > > > > > > > > > > > > > > > > > > > registry (new values could be > > specified via the > > > > > > > > appropriate > > > > > > > > > > > > > means if > > > > > > > > > > > > > > needed). Paul had a slight concern that > > > you might > > > > > > > > be mixing > > > > > > > > > > > > > multiple > > > > > > > > > > > > > > CS MSs into a single RS media stream > > and whether > > > > > > > > this might > > > > > > > > > > > > > result in > > > > > > > > > > > > > > cases not describable in this way, but > > > in the end > > > > > > > > > > accepted the > > > > > > > > > > > > > > consensus. It needs to be discussed > > on the list > > > > > > > > > > whether this is > > > > > > > > > > > > > > conveyed in XML or in the RS SDP a=3Dcontent > > > > attribute. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > 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 > > > > > > > > > >=20 From Leon.Portman@nice.com Thu Jul 7 06:49: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 D33AF21F86D5 for ; Thu, 7 Jul 2011 06:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 0jPe53JOg59w for ; Thu, 7 Jul 2011 06:49:54 -0700 (PDT) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id 7FCFB21F85E5 for ; Thu, 7 Jul 2011 06:49:49 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.15]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Thu, 7 Jul 2011 16:49:48 +0300 From: Leon Portman To: "Elwell, John" , "siprec@ietf.org" Date: Thu, 7 Jul 2011 16:49:47 +0300 Thread-Topic: Comment on metadata-02 - Media Stream Thread-Index: Acw8qtezJdNopWF7RZqONH6e5tBRLgAAYkSA Message-ID: <07465C1D981ABC41A344374066AE1A2C38AFE9BB98@TLVMBX01.nice.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Comment on metadata-02 - Media Stream X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 13:49:56 -0000 Actually I was expecting (a) as well. And it should point to the relevant m= edia lines in RS SDP. If two or more Media Streams point to the same RS SDP= m-line label, then we have mixing use case So something like this: CS MS (1:1)- > XML MS -> (N:1) -> RS MS Leon -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Elwell, John Sent: Thursday, July 07, 2011 4:36 PM To: siprec@ietf.org Subject: [siprec] Comment on metadata-02 - Media Stream In section 6.5, Media Stream seems to be defined as follows: "A Media Stream block MUST have properties of media as seen by SRC and sent to SRS." Ignoring the possibly inappropriate RFC 2119 language, I don't think this c= learly defines whether: a) this represents a medium of the CS (i.e., corresponding to a media descr= iption in the CS SDP); or b) this represents a medium of the RS (i.e., corresponding to a media descr= iption in the RS SDP). Both of these are "seen by SRC". There need not be a 1:1 relationship betwe= en the two, and hence we need to make it clear which it represents. Although personally I had expected a), a couple of threads in recent months= have seemed to indicate b) is the general consensus. Possibly a definition like: "A Media Stream block represents a single RTP session between an SRC and an= SRS. Note that, because of possible mixing at the SRC, a Media Stream bloc= k does not necessarily represent a single RTP session between CS participan= ts." However, if we accept this principle, I wonder what the Start Time and End = Time attributes mean. The start and end of an RS RTP session correspond to = the relevant offer-answer exchanges, so they don't really need to be in XML= . So I suspect I still haven't drilled down into the real meaning of MS suf= ficiently. John (as individual) =20 _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From Leon.Portman@nice.com Thu Jul 7 06:52:27 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2B0621F8734 for ; Thu, 7 Jul 2011 06:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, 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 3xuJvPikoSyr for ; Thu, 7 Jul 2011 06:52:26 -0700 (PDT) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id AE8A721F870F for ; Thu, 7 Jul 2011 06:52:25 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.15]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Thu, 7 Jul 2011 16:52:24 +0300 From: Leon Portman To: "Elwell, John" , "siprec@ietf.org" Date: Thu, 7 Jul 2011 16:52:23 +0300 Thread-Topic: Question on current speaker video Thread-Index: Acw8qvyln0YwIJofTL6nlIWCMtcIuQAAe89w Message-ID: <07465C1D981ABC41A344374066AE1A2C38AFE9BB9C@TLVMBX01.nice.com> References: 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] Question on 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: Thu, 07 Jul 2011 13:52:28 -0000 There is also similar use case for trading floor speaker channels, where mu= ltiple traders (hundreds or thousands) listen to the same channel and some = time push to talk to this channel. In such case, for example it is a separa= te event (push to talk) that can be sent over RTP stream as well Leon -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Elwell, John Sent: Thursday, July 07, 2011 4:37 PM To: siprec@ietf.org Subject: [siprec] Question on current speaker video Consider a CS with a single video medium that is used by an MCU to show the= current speaker. All participants receive that medium. However, at any one= time only one participant is contributing to the medium. Now suppose there is an SRC that sends that medium (unmixed with any other = medium) to an SRS. The metadata would represent this as a single MS element= . There would also be n Participant elements (assuming sufficient informati= on is available to the SRC). I assume that we would simply say that all n P= articipants are contributing to that MS, and all n Participants are recipie= nts of that MS. Then there is no need to update the metadata every time the= speaker changes (which could be very frequently). Similarly for an audio bridge that filters out all but the loudest speaker = or speakers. That could be signalled in RTP using https://datatracker.ietf.= org/doc/draft-ietf-avtext-mixer-to-client-audio-level/, but would not be si= gnalled by rapid updates of metadata. Can folks confirm this is a correct understanding? It might require mention= in the metadata draft, or possibly in the architecture draft. John _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From john.elwell@siemens-enterprise.com Thu Jul 7 06: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 F342721F86DE for ; Thu, 7 Jul 2011 06:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.128 X-Spam-Level: X-Spam-Status: No, score=-106.128 tagged_above=-999 required=5 tests=[AWL=-0.129, 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 3hoxRJ5LwTIq for ; Thu, 7 Jul 2011 06:53:17 -0700 (PDT) Received: from mail174.messagelabs.com (mail174.messagelabs.com [85.158.138.51]) by ietfa.amsl.com (Postfix) with SMTP id 5C20421F870F for ; Thu, 7 Jul 2011 06:53:16 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-3.tower-174.messagelabs.com!1310046794!17967798!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 3003 invoked from network); 7 Jul 2011 13:53:14 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-3.tower-174.messagelabs.com with SMTP; 7 Jul 2011 13:53:14 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id EABC61EB83ED; Thu, 7 Jul 2011 15:53:13 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 7 Jul 2011 15:53:13 +0200 From: "Elwell, John" To: "Parthasarathi R (partr)" , "Charles Eckel (eckelcu)" , "Ram Mohan R (rmohanr)" , Leon Portman , "siprec@ietf.org" Date: Thu, 7 Jul 2011 15:53:12 +0200 Thread-Topic: [siprec] Content (RFC 4796) attribute in SDP or XML Thread-Index: Acw0mPHhxfeVJEDcQLSYWo3IAZGl7wABDbXgACpfOfAADTnVAAA/CH7wAL12yxAADByJIAAdm3FgAADcErAAQaGFkAAC7JoQAAMpvCAAAObikAAasOngAAJiC3AAGcWykAAW4scQAAPQnyAACOotkAABydoAAABuu6A= Message-ID: References: <07465C1D981ABC41A344374066AE1A2C38AF6D40CC@TLVMBX01.nice.com><07465C1D981ABC41A344374066AE1A2C38AF6D4376@TLVMBX01.nice.com><07465C1D981ABC41A344374066AE1A2C38AFE9B1C0@TLVMBX01.nice.com> <35BCE99A477D6A4986FB2216D8CF2CFD06E358D2@XMB-BGL-417.cisco.com> Keywords: SIPREC 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] Content (RFC 4796) attribute in SDP or XML X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 13:53:20 -0000 Well, my agreement was really conditional on fixing the definition of MS - = see other thread. John > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > Sent: 07 July 2011 14:45 > To: Elwell, John; Charles Eckel (eckelcu); Ram Mohan R > (rmohanr); Leon Portman; siprec@ietf.org > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML > > John, > > Thanks for your agreement for Content (RFC 4796) attribute in SDP. > > Thanks > Partha > > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Thursday, July 07, 2011 7:05 PM > > To: Parthasarathi R (partr); Charles Eckel (eckelcu); Ram > > Mohan R (rmohanr); Leon Portman; siprec@ietf.org > > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML > > > > > > > > > -----Original Message----- > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > Sent: 07 July 2011 13:02 > > > To: Elwell, John; Charles Eckel (eckelcu); Ram Mohan R > > (rmohanr); Leon > > > Portman; siprec@ietf.org > > > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML > > > > > > John, > > > > > > I understand your mixed video scenario. In case of mixed audio or > > > video, it is not possible to retrieve the complete > > information in SRS > > > as it is pre-mixed at SRC. It is one of the motivation for > > having two > > > m-line with non-mixed stream to SRS. The similar issue is > raised by > > > Charles earlier for mixed audio stream wherein current speaker > > > (participant) has to be noticed using metadata XML. Even > in case of > > > mixed audio stream, the loss of some information is > > unavoidable. Hope > > > you agree here. In case the intent is to create the > infrastructure > > > wherein the mixed stream should not loose the > information, then we > > > need the separate discussion. > > > > > > I will write the separate mail thread for the architecture > > > clarification in SRC wherein CS is handling by one SIP UA > > instance and > > > RS is handled as separate SIP UA instance. > > > > > > SDP is reused for RS media description, in case it is not > > possible for > > > SDP to express about specific media description then it is > > better to > > > generically develop the extension like IANA registration > > for RFC 4796 > > > which helps for other similar mixing applications as well. > > [JRE] Yes, I am in agreement with using the IANA registry for > > RFC 4796, and extending it where necessary. My only question > > was whether these values are most appropriately sent in SDP > or in XML. > > > > > > > > From the metadata perspective, Stream in XML is pointing > > to m-line of > > > SDP using label attributes. > > [JRE] Yes, I had forgotten that. I recall an earlier > > misunderstanding to do with this. I don't think that is clear > > in the metadata draft, so I will comment separately on that. > > However, if this is the common understanding, I can see that > > using the a=3Dcontent attribute in the RS SDP would be a viable > > solution. > > > > John (as individual) > > > > > > > > > SDP points to raw media. XML is used to create > association which is > > > not possible in SDP. Participant, session to Stream > grouping is not > > > possible to achieve in SDP which forces us to look for XML > > > representation. But in case of content-type scenario, it > > is possible > > > to make it happen. > > > > > > Please read inline > > > > > > Thanks > > > Partha > > > > > > > -----Original Message----- > > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > Sent: Thursday, July 07, 2011 12:36 PM > > > > To: Charles Eckel (eckelcu); Ram Mohan R (rmohanr); > > Parthasarathi R > > > > (partr); Leon Portman; siprec@ietf.org > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML > > > > > > > > Charles, > > > > > > > > I see how it COULD be done in the way you describe. I > > just feel it > > > > is architecturally wrong to describe the CS MS as part of > > the RS MS > > > > description (i.e., the RS SDP). > > > > > > In case the intent is to pass CS MS description, I > > agree with > > > you. IIRC, charles proposed to use the explicit mixed > content-type > > > which is more appropriate to be passed in RS SDP to provide the > > > description about that specific media. > > > > > > > > > > > However, I can also give a more specific reason. Suppose CS > > > > MS1 is slides and CS MS2 is speaker video. But the XML > > does not tell > > > > me that CS MS1 is slides and CS MS1 is speaker video. > Both CS MS1 > > > > and CS MS2 are combined into RS MS1 (slides + speaker). > > > > > > The question here is how it is possible for any UA to > > > represent > > > (slides+speaker) in SDP? In case it is not well defined, > > let us work > > > for it > > > > > > The XML metadata tells me that at a given > > > > time Participant P1 contributed to CS MS1 and P2 > > contributed to CS > > > > MS2. How can I tell that P1 contributed to slides and > > > > P2 contributed to speaker? > > > > > > In the mixed stream, we lose the data in SRC > > because actual > > > media is mixed. The system shall be designed to send the > > media stream > > > separately or we have to find the generic way to group the stream > > > together > > > > > > > > > > > See also below: > > > > > > > > > -----Original Message----- > > > > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > > > Sent: 06 July 2011 21:05 > > > > > To: Ram Mohan R (rmohanr); Elwell, John; Parthasarathi R > > > > (partr); Leon > > > > > Portman; siprec@ietf.org > > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in > SDP or XML > > > > > > > > > > RFC 4796 has registered the following values: > > > > > > > > > > slides RFC 4796 Presentation slides > > > > > speaker RFC 4796 Image from > the speaker > > > > > sl RFC 4796 Sign language > > > > > main RFC 4796 Main media stream > > > > > alt RFC 4796 Alternative > > media stream > > > > > > > > > > Suppose we register the following new values: > > > > > > > > > > siprec1 RFC xxxx SIPREC value 1 > > > > > siprec2 RFC xxxx SIPREC value 2 > > > > > siprec3 RFC xxxx SIPREC value 3 > > > > > > > > > > If the CS has a media lines with the following content > > attributes > > > > > > > > > > CS MS1 - slides > > > > > CS MS2 - main > > > > > CS MS3 - siprec1 > > > > > CS MS4 - siprec2 > > > > > > > > > > SRC sends two media streams to RS. RS MS1 is essentially > > > CS MS1. RS > > > > > MS2 is some composition of CS MS2, CS MS3 and CS MS4. > > > > > This could be represented using the content attribute as: > > > > > > > > > > RS MS1 - slides > > > > > RS MS2 - main, siprec1, siprec2 > > > > > > > > > > If this is all we think is required, using the content > > > > attribute does > > > > > seem sufficient. However, my understanding is people want > > > > to be able > > > > > to convey something other than the simple concatenation > > > of content > > > > > attribute values, and for that reason, prefer to use > > XML. In this > > > > > case, the desired set of values is not bound by > > anything we will > > > > > define in SIPREC. That is my understanding as to why XML is > > > > preferred > > > > > over the RFC > > > > > 4796 content attribute. > > > > [JRE] That was not my motivation, but perhaps others had > > > that in mind. > > > > > > > > John (as individual) > > > > > > > > > > > > > > Cheers, > > > > > Charles > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Ram Mohan R (rmohanr) > > > > > > Sent: Wednesday, July 06, 2011 12:33 AM > > > > > > To: Elwell, John; Parthasarathi R (partr); Charles Eckel > > > > (eckelcu); > > > > > Leon Portman; siprec@ietf.org > > > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in > > SDP or XML > > > > > > > > > > > > Just on this one > > > > > > > > > > > > > RS media stream is a mixed content type stream > > > > > of "current > > > > > > > speaker video" and "room video" and the resultant shall > > > > > be named as > > > > > > > "mixed current speaker video & room video" which shall be > > > > > passed as > > > > > > > new content type extension to SRS > > > > > > [JRE] Right, so you agree this can't be passed in the RS > > > > > SDP. I would > > > > > challenge the need to define > > > > > > (and register) a new RFC 4796 value "mixed current > > > speaker video & > > > > > room video". We have two MS > > > > > > elements (representing the two CS video streams for > > > > current speaker > > > > > and room. Why can't we just place > > > > > > the respective RFC 4796 content types in the respective > > > > MS elements? > > > > > And why does it need to be as > > > > > > extension data - why can't it be standardized from day one? > > > > > > > > > > > > My thought here is since we have new content types > > > "mixed current > > > > > speaker video & room video" we need > > > > > > to register/extend RFC 4796 for the same and send in RS > > > > SDP. I would > > > > > prefer this approach instead of > > > > > > sending it through recording metadata XML. Of course > > we need to > > > > > discuss this in AVT to get their > > > > > > opinion. > > > > > > > > > > > > Regards, > > > > > > Ram > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: siprec-bounces@ietf.org > > > > [mailto:siprec-bounces@ietf.org] On > > > > > > > Behalf Of Elwell, John > > > > > > > Sent: Wednesday, July 06, 2011 12:05 PM > > > > > > > To: Parthasarathi R (partr); Charles Eckel (eckelcu); > > > > > Leon Portman; > > > > > > > siprec@ietf.org > > > > > > > Subject: Re: [siprec] Content (RFC 4796) attribute in > > > SDP or XML > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > > > > > Sent: 05 July 2011 19:06 > > > > > > > > To: Charles Eckel (eckelcu); Leon Portman; > Elwell, John; > > > > > > > > siprec@ietf.org > > > > > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in > > > > SDP or XML > > > > > > > > > > > > > > > > John, > > > > > > > > > > > > > > > > Please read inline. > > > > > > > > > > > > > > > > Thanks > > > > > > > > Partha > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Charles Eckel (eckelcu) > > > > > > > > > Sent: Tuesday, July 05, 2011 10:44 PM > > > > > > > > > To: Leon Portman; Elwell, John; Parthasarathi R > > (partr); > > > > > > > > > siprec@ietf.org > > > > > > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in > > > > > SDP or XML > > > > > > > > > > > > > > > > > > Okay by me. > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > Charles > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > > > > > > > > > Sent: Tuesday, July 05, 2011 8:42 AM > > > > > > > > > > To: Elwell, John; Parthasarathi R (partr); > > Charles Eckel > > > > > > > > (eckelcu); > > > > > > > > > > siprec@ietf.org > > > > > > > > > > Subject: RE: [siprec] Content (RFC 4796) > > > > attribute in SDP or > > > > > XML > > > > > > > > > > > > > > > > > > > > I completely agree with the below. > > > > > > > > > > > > > > > > > > > > Leon > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Elwell, John > > > > > [mailto:john.elwell@siemens-enterprise.com] > > > > > > > > > > Sent: Tuesday, July 05, 2011 5:44 PM > > > > > > > > > > To: Parthasarathi R (partr); Leon Portman; > > Charles Eckel > > > > > > > > (eckelcu); > > > > > > > > > > siprec@ietf.org > > > > > > > > > > Subject: RE: [siprec] Content (RFC 4796) > > > > attribute in SDP or > > > > > XML > > > > > > > > > > > > > > > > > > > > (as chair) > > > > > > > > > > We should try to avoid opening up old issues. > > I think we > > > > > > > > > had agreed that: > > > > > > > > > > - RS SDP describes the RS, and therefore just > > > > describes how > > > > > > > > > recordable media is delivered to the SRS. > > > > > > > > > > It does not describe how media is delivered > between CS > > > > > > > > > endpoints as part of the CS. > > > > > > > > > > - Therefore anything to do with the CS (i.e., > > > the session > > > > > being > > > > > > > > > > recorded) needs to be delivered to the SRS > as metadata > > > > > > > > > (i.e., in XML). > > > > > > > > > > - We don't see a need to standardize delivery > > of things > > > > > > > > > like CS codecs > > > > > > > > > > in the metadata, but that could be done using the > > > > extension > > > > > > > > > mechanism. > > > > > > > > > > > > > > > > > > Hope everyone agree here that CS SDP > > > > > information could be > > > > > > > > passed as extension-data. attribute within > > > > > > > > > > > > > may help to achieve this requirement. > > > > > > > [JRE] Or even as the standardized part of an MS element > > > > > if we wish. > > > > > > > > > > > > > > > > > > > > > > > > > Focusing now on the content attribute, I don't > > > > > think there is > > > > > any > > > > > > > > > > disagreement that the SRS needs to know the > > content type > > > > > (e.g., > > > > > > > > > > presentation) of a media stream. The SRC can obtain > > > > > this from > > > > > the > > > > > > > > > > a=3Dcontent attribute of the CS SDP. The > > > discussion is about > > > > > > > > > whether this content attribute should be conveyed > > > > to the SRS: > > > > > > > > > > A) as an a=3Dcontent attribute of the RS SDP, or > > > > > > > > > > B) within the metadata XML. > > > > > > > > > > > > > > > > > > > > (as individual) > > > > > > > > > > According to past decisions, there is perhaps > > > an argument > > > > > > > > > for B). If, > > > > > > > > > > for example, we wanted to convey the fact that > > > a CS media > > > > > > > > > stream was > > > > > > > > > > subject to 256-bit encryption, this > > information would go > > > > > > > > in the XML > > > > > > > > > > > > > > > > Here I have the doubt. In case 256-bit > > > > > encryption is not > > > > > > > used > > > > > > > > by RS SDP, Please let me know the reason for > > > passing the key > > > > > > > > information to SRS because RS SDP is not > > encrypted in that > > > > > > > > fashion. > > > > > > > > > > > > [JRE] I did not suggest passing the CS keying material to > > > > > the SRS. I > > > > > > > just suggested passing the information that the CS media > > > > > stream used > > > > > > > 256 bit encryption. Perhaps this was a bad example - > > > it was just > > > > > meant > > > > > > > to illustrate the general principle that information > > > > about the CS > > > > > > > should be passed in metadata XML. > > > > > > > > > > > > > > > > > > > > > > > > > (it can't go in the RS SDP, because the RS > > might not use > > > > > > > > > 256-bit encryption. Similarly, one could > argue that the > > > > > > > > > content type of a CS media stream should go in the > > > > XML, not in > > > > > > > > > the RS SDP. > > > > > > > > I'm seeing content-type attribute as one of > > > > > the extension > > > > > of > > > > > > > > SDP a=3D attribute. In general, it is possible to > convert CS > > > > > > > mediastream > > > > > > > > content type to RS media stream content type > > because SRC RS > > > > > > > > media stream is formed based on CS media stream > > > except for the > > > > > mixing scenarios > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I could even imagine cases where the content > > > type of a CS > > > > > > > > > media stream > > > > > > > > > > does not equal the content type of an RS > media stream, > > > > > > > > > e.g., where the > > > > > > > > > > SRC combines the current speaker video and the > > > room video > > > > > > > > into two > > > > > > > > > > videos side-by-side in the same RS media stream. > > > > > > > > > > > > > > > > RS media stream is a mixed content > type stream of > > > > > "current > > > > > > > > speaker video" and "room video" and the resultant > > > > shall be named > > > > > as > > > > > > > > "mixed current speaker video & room video" which > > > > shall be passed > > > > > > > > as new content type extension to SRS > > > > > > > [JRE] Right, so you agree this can't be passed in the > > > RS SDP. I > > > > > would > > > > > > > challenge the need to define (and register) a new RFC > > > 4796 value > > > > > "mixed > > > > > > > current speaker video & room video". We have two MS > > elements > > > > > > > (representing the two CS video streams for current > > > > > speaker and room. > > > > > > > Why can't we just place the respective RFC 4796 content > > > > > types in the > > > > > > > respective MS elements? And why does it need to be as > > > > > extension data > > > > > - > > > > > > > why can't it be standardized from day one? > > > > > > > > > > > > > > John (as individual) > > > > > > > > > > > > > > > > > > > > > > > In the > > > > > > > > > metadata these would be two media streams, each > > > > with its own > > > > > > > > > content type, but both would refer to the same RS > > > > > media stream. > > > > > > > > > > > > > > > > > > It will be problematic approach because the > > > > > actual media > > > > > and > > > > > > > > metadata are not related explicitly. As per the current > > > > > description, > > > > > > > > there are two element with different > > > unique-id uses > > > > > > > > same label in SDP with different XML element > > > ("content-type") > > > > > > > > within them. > > > > > The > > > > > > > > issue is whether media has stream1 behavior or stream2 > > > > > behavior or > > > > > > > > mixed. We will able to extent XML element for > > having single > > > > > > > > interpretation but it is not fully clarified in the > > > > > draft now. The > > > > > > > > bottom-up matching like stream1 & stream2 has same > > > > label element > > > > > > > > and it has to be grouped together is not > explicit in this > > > > > > > > scenario. We > > > > > need > > > > > > > > more investigation both information is required but not > > > > > the actual > > > > > > > > media. Please correct me in I'm missing something > > > > > > > > > > > > > > > > > > > > John > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Parthasarathi R (partr) > > [mailto:partr@cisco.com] > > > > > > > > > > > Sent: 04 July 2011 08:08 > > > > > > > > > > > To: Leon Portman; Charles Eckel (eckelcu); > > > > Elwell, John; > > > > > > > > > > > siprec@ietf.org > > > > > > > > > > > Subject: RE: [siprec] Content (RFC 4796) > > > > > attribute in SDP or > > > > > > > XML > > > > > > > > > > > > > > > > > > > > > > Leon, > > > > > > > > > > > > > > > > > > > > > > Please read inline. > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > Partha > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: Leon Portman > [mailto:Leon.Portman@nice.com] > > > > > > > > > > > > Sent: Monday, July 04, 2011 12:11 PM > > > > > > > > > > > > To: Parthasarathi R (partr); Charles Eckel > > > (eckelcu); > > > > > Elwell, > > > > > > > > > > > > John; siprec@ietf.org > > > > > > > > > > > > Subject: RE: [siprec] Content (RFC 4796) > > > attribute in > > > > > > > > SDP or XML > > > > > > > > > > > > > > > > > > > > > > > > Partha Hi > > > > > > > > > > > > > > > > > > > > > > > > Please see below. > > > > > > > > > > > > > > > > > > > > > > > > Leon > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: Parthasarathi R (partr) > > > [mailto:partr@cisco.com] > > > > > > > > > > > > Sent: Sunday, July 03, 2011 7:50 PM > > > > > > > > > > > > To: Leon Portman; Charles Eckel (eckelcu); > > > > Elwell, John; > > > > > > > > > > > > siprec@ietf.org > > > > > > > > > > > > Subject: RE: [siprec] Content (RFC 4796) > > > attribute in > > > > > > > > SDP or XML > > > > > > > > > > > > > > > > > > > > > > > > Leon, > > > > > > > > > > > > > > > > > > > > > > > > Please read inline. > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > Partha > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: Leon Portman > [mailto:Leon.Portman@nice.com] > > > > > > > > > > > > Sent: Sunday, July 03, 2011 4:13 PM > > > > > > > > > > > > To: Charles Eckel (eckelcu); Elwell, John; > > > > > Parthasarathi R > > > > > > > > > > > > (partr); siprec@ietf.org > > > > > > > > > > > > Subject: RE: [siprec] Content (RFC 4796) > > > attribute in > > > > > > > > SDP or XML > > > > > > > > > > > > > > > > > > > > > > > > I do prefer that metadata XML will be as > > > > > self-contained as > > > > > > > > > > > > possible and not rely on conveying some > > data via RS > > > > > > > > SDP. RS SDP > > > > > > > > > > > > should only be used to recording > establishment and > > > > > > > > > negotiation and > > > > > > > > > > > > not as a mechanism for metadata reporting. > > > > > > > > > > > > > > > > > > > > > > > > In case Metadata XML has to be > > > > self-contained, > > > > > the > > > > > > > > > > > > complete SDP has to be converted into XML > > format or > > > > > > > > > else XML has > > > > > > > > > > > > to have sort of XML attribute which > > > > > carries SDP. > > > > > > > > > > > > Creating mapping for each SDP attribute > > > with metadata > > > > > > > > > XML element > > > > > > > > > > > > does not seems to be feasible > > > > > > > > > > > > > > > > > > > > > > > > [LeonP] But if CS SDP is different from RS SDP, > > > > > > > > anyway you will > > > > > > > > > > > > need to encapsulate the original RS SDP, so > > > why not in > > > > > XML? > > > > > > > > > > > > > > > > > > > > > > I guess that the confusion is > here. In the > > > > > > > > > current format, > > > > > > > > > > > RS SDP is only carried towards SRS and CS > SDP is not > > > > > forwarded. > > > > > > > > > > > This design > > > > > > > > > > > is closed as part of ticket #71 > > > > > > > > > > > > > > > > > > > > (http://www.ietf.org/mail- > > > > > > > archive/web/siprec/current/msg02106.html). > > > > > > > > > > > Please bring up with the usecase for CS SDP > > > if required > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Otherwise we will not be able to reuse same > > > format for > > > > > > > > > reporting > > > > > > > > > > > > metadata via web services As per > > > IETF-80 and > > > > > > > > > last interim > > > > > > > > > > > > meeting, there is no intent of reusing > > this metadata > > > > > > > > > XML in other > > > > > > > > > > > > protocol. In case reusing same format for > > webservice > > > > > > > > or XMPP is > > > > > > > > > > > > the intent, the current metadata XML > > > mechanism is not > > > > > > > > > the appropriate. > > > > > > > > > > > > This was discussed in > > > > > > > > > > > > > > > > > > > > > > > > > > > > http://www.ietf.org/mail-archive/web/siprec/current/msg02151.html, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > http://www.ietf.org/mail- > > > > > > > archive/web/siprec/current/msg02155.html(1s > > > > > > > > > > > t > > > > > > > > > > > > point in format slide). In case you have > > difference > > > > > > > > of opinion > > > > > > > > > > > > even after this multiple discussion, > let us again > > > > > > > > > discuss at IETF-81. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [LeonP] I was not proposing replacing SIP > > > with another > > > > > > > > > transport > > > > > > > > > > > > layer, just wanted to keep other options open. > > > > > > > > > > > > > > > > > > > > > > Current metadata format is > > customized for SIP > > > > > > > > > transport. In > > > > > > > > > > > case we need to keep the options open, the format > > > > > has to be > > > > > > > > > > > revisited from the scratch. In our > > analysis, we notice > > > > > > > > that REST > > > > > > > > > > > architecture with Metadata XML is best fit for > > > > HTTP, XMPP > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I am > > > > > > > > > > > > very big supporter for metadata over > SIP reporting > > > > > > > > > > > > > > > > > > > > > > > Thanks, Me too.. > > > > > > > > > > > > > > > > > > > > > > > or as dedicated SIP session. > > > > > > > > > > > > In case Metadata is separate session > > > > > from RS, RS > > > > > > > > > > > > attribute like RS-id MUST be included within > > > > > XML. This was > > > > > > > > > > > > discussed at > > > > > > > > > > > > http://www.ietf.org/mail- > > > > > > > archive/web/siprec/current/msg02013.h > > > > > > > > > > > tml. Could you please explain reason for > > the dedicated > > > > > > > > > SIP > session > > > > > > > > > > > for metadata. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [LeonP] The main use case is Recording on > > > > > Demand, that is > > > > > > > > > > > > triggered by SRS. In such case it will be > > > very useful > > > > > > > > > to have just > > > > > > > > > > > > one SIP session and send all metadata over it > > > > (like CTI > > > > > > > > > > > > link) and then only trigger recording (via > > > > external SRC > > > > > > > > > > > > interface) only for specific call segments. > > > > > > > > > > > > > > > > > > > > > > > I understand the current > > > implementation wherein > > > > > > > > > few of the > > > > > > > > > > > metadata like CDR records is passed > through non-sip > > > > > > > > > interface. It is > > > > > > > > > > > outside the scope of SIPREC. The > global-id in format > > > > > > > > > shall be used > > > > > > > > > > > to correlate. Please let me know in case > any current > > > > > > > > > SIPREC metadata > > > > > > > > > > > attribute MUST be passed through this CTS link. > > > > > > > > > > > > > > > > > > > > > > > > > > > As for examples, the basic information as > > > media type, > > > > > labels, > > > > > > > > > > > > volume etc. Any application level data can be > > > > relevant. > > > > > Even > > > > > > > > > > > > indication of encryption (for a case > > where RS is not > > > > > > > > encrypted) > > > > > > > > > > > > > > > > > > > > > > > > Leon > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: siprec-bounces@ietf.org > > > > > > > > > > > > [mailto:siprec-bounces@ietf.org] On Behalf > > > Of Charles > > > > > Eckel > > > > > > > > > > > (eckelcu) > > > > > > > > > > > > Sent: Wednesday, June 29, 2011 7:17 PM > > > > > > > > > > > > To: Elwell, John; Parthasarathi R (partr); > > > > > siprec@ietf.org > > > > > > > > > > > > Subject: Re: [siprec] Content (RFC 4796) > > > attribute in > > > > > > > > SDP or XML > > > > > > > > > > > > > > > > > > > > > > > > I think it is sufficient, especially since we > > > > can assign > > > > > new > > > > > > > > > > > > values if necessary. > > > > > > > > > > > > Are there any examples of what people think they > > > > > > > > might want to > > > > > > > > > > > > capture in the SDP and/or metadata field? > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > Charles > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > From: siprec-bounces@ietf.org > > > > > > > > > [mailto:siprec-bounces@ietf.org] > > > > > > > > > > > > > On > > > > > > > > > > > > Behalf Of Elwell, John > > > > > > > > > > > > > Sent: Tuesday, June 28, 2011 3:11 AM > > > > > > > > > > > > > To: Parthasarathi R (partr); siprec@ietf.org > > > > > > > > > > > > > Subject: Re: [siprec] Content (RFC 4796) > > > > attribute in > > > > > > > > > SDP or XML > > > > > > > > > > > > > > > > > > > > > > > > > > I would like other opinions on whether the > > > > > SDP a=3Dcontent > > > > > > > > > > > > attribute in > > > > > > > > > > > > the RS SDP has the correct > > > > > > > > > > > > > semantics for representing the content > > type of the > > > > > > > > > > > recorded CS media > > > > > > > > > > > > stream. > > > > > > > > > > > > > > > > > > > > > > > > > > John > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > From: Parthasarathi R (partr) > > > > > [mailto:partr@cisco.com] > > > > > > > > > > > > > > Sent: 28 June 2011 10:45 > > > > > > > > > > > > > > To: Elwell, John; siprec@ietf.org > > > > > > > > > > > > > > Cc: Ram Mohan R (rmohanr); Paul Kyzivat > > > (pkyzivat) > > > > > > > > > > > > > > Subject: RE: Content (RFC 4796) attribute > > > > in SDP or > > > > > XML > > > > > > > > > > > > > > > > > > > > > > > > > > > > John, > > > > > > > > > > > > > > > > > > > > > > > > > > > > In case if it is the argument of whether CS > > > > > MS content > > > > > > > > > > > > type or RS MS > > > > > > > > > > > > > > > > > > > > > > > > > > content type in the metadata, it is > > > > better for us to > > > > > > > > > > > > re-open ticket > > > > > > > > > > > > > > #71 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > (http://www.ietf.org/mail- > > > > > > > archive/web/siprec/current/msg02106.html). > > > > > > > > > > > > > > Please let me know your opinion here. > > > > > > > > > > > > > > > > > > > > > > > > > > > > The basic idea in metadata format is to > > > re-use as > > > > > > > > > much as SDP > > > > > > > > > > > > > > attribute (like direction, content) in > > > > > media level for > > > > > > > > > > > RS dialog > > > > > > > > > > > > > > (using SDP label attribute as a > pointer) until > > > > > otherwise > > > > > > > > > > > > there is a > > > > > > > > > > > > > > restriction in using in such manner. As per > > > > > RFC 4796, > > > > > > > > > > > there is no > > > > > > > > > > > > > > such restriction and so, I prefer to reuse > > > > > as content > > > > > SDP > > > > > > > > > > > > attribute > > > > > > > > > > > > > > rather than introducing the new > > > > > > > > > element for > > > > > > > > > > > > > > this purpose. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > Partha > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > From: Elwell, John > > > > > > > > > [mailto:john.elwell@siemens-enterprise.com] > > > > > > > > > > > > > > Sent: Monday, June 27, 2011 1:18 PM > > > > > > > > > > > > > > To: Parthasarathi R (partr); siprec@ietf.org > > > > > > > > > > > > > > Cc: Ram Mohan R (rmohanr); Paul Kyzivat > > > (pkyzivat) > > > > > > > > > > > > > > Subject: RE: Content (RFC 4796) attribute > > > > in SDP or > > > > > XML > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > > From: Parthasarathi R (partr) > > > > > [mailto:partr@cisco.com] > > > > > > > > > > > > > > > Sent: 27 June 2011 08:08 > > > > > > > > > > > > > > > To: siprec@ietf.org; Elwell, John > > > > > > > > > > > > > > > Cc: Ram Mohan R (rmohanr); Paul Kyzivat > > > > (pkyzivat) > > > > > > > > > > > > > > > Subject: Content (RFC 4796) attribute in > > > > > SDP or XML > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > As per the last interim SIPREC meeting, > > > > there is a > > > > > > > > > > > consensus to > > > > > > > > > > > > > > > describe the content of an MS using RFC > > > > 4796 & its > > > > > > > > > > > > > > extension. As per > > > > > > > > > > > > > > > RFC 4796, the multiple instance of > > > > > content attribute > > > > > > > > > > > is possible > > > > > > > > > > > > to > > > > > > > > > > > > > > > exist in SDP which shall be used in > > > RS SDP. SRS > > > > > > > > > shall group > > > > > > > > > > > > > > the same > > > > > > > > > > > > > > > media content types by "content" > > > attribute in RS > > > > > > > > > SDP. We are > > > > > > > > > > > > > > > interested in knowing any specfic > > > > reason for this > > > > > > > > > > > > attribute to be > > > > > > > > > > > > > > > duplicated in Metadata XML. > > > > > > > > > > > > > > [JRE] I don't have a reason for > > **duplication**. > > > > > > > > > > > However, I think > > > > > > > > > > > > > > there is a valid question to be asked > > > whether the > > > > > content > > > > > > > > > > > > type of an > > > > > > > > > > > > > > > > > > > > > > > > > > MS should be represented: > > > > > > > > > > > > > > A) in XML; or > > > > > > > > > > > > > > B) in RS SDP as a=3Dcontent. > > > > > > > > > > > > > > > > > > > > > > > > > > > > The content type we are talking about is an > > > > > MS content > > > > > > > > > > > > type, i.e., > > > > > > > > > > > > > > relating to the CS. One could argue that the > > > > > > > > > > > > corresponding RS stream > > > > > > > > > > > > > > > > > > > > > > > > > > is NOT the same content type. For example: > > > > > > > > > > > > > > - CS MS content type is "slides". > > > > > > > > > > > > > > - RS media stream content type is > > "recording of > > > > > slides". > > > > > > > > > > > > > > > > > > > > > > > > > > > > On this basis, I think the correct > option for > > > > > > > > > conveying the MS > > > > > > > > > > > > content > > > > > > > > > > > > > > type "slides" is A) (in the XML). > > > > > > > > > > > > > > > > > > > > > > > > > > > > Note that this would not involve > > > > > duplication. The SDP > > > > > > > > > > > > > > a=3Dcontent attribute is optional, so we > > > > need not use > > > > > > > > > it for the RS. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Perhaps my distinction is too > > > > theoretical, but I do > > > > > > > > > > > feel a little > > > > > > > > > > > > more > > > > > > > > > > > > > > comfortable using the XML rather than > > > the RS SDP. > > > > > > > > > > > > > > > > > > > > > > > > > > > > John (as individual) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Partha > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > last Interim SIPREC meeting Note: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Slide 7: On the question of how to > > > describe the > > > > > content > > > > > > > > > > > > of an MS, > > > > > > > > > > > > > > > there was no objection to basing this > > > > on the types > > > > > in > > > > > > > > > > > > the RFC 4796 > > > > > > > > > > > > > > > > > > > > > > > > > > > registry (new values could be > > > specified via the > > > > > > > > > appropriate > > > > > > > > > > > > > > means if > > > > > > > > > > > > > > > needed). Paul had a slight concern that > > > > you might > > > > > > > > > be mixing > > > > > > > > > > > > > > multiple > > > > > > > > > > > > > > > CS MSs into a single RS media stream > > > and whether > > > > > > > > > this might > > > > > > > > > > > > > > result in > > > > > > > > > > > > > > > cases not describable in this way, but > > > > in the end > > > > > > > > > > > accepted the > > > > > > > > > > > > > > > consensus. It needs to be discussed > > > on the list > > > > > > > > > > > whether this is > > > > > > > > > > > > > > > conveyed in XML or in the RS SDP a=3Dcontent > > > > > attribute. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > siprec mailing list siprec@ietf.org > > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > siprec mailing 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 Jul 7 06:57: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 DB3A71F0C3F for ; Thu, 7 Jul 2011 06:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.971 X-Spam-Level: X-Spam-Status: No, score=-9.971 tagged_above=-999 required=5 tests=[AWL=0.028, 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 QXwq+UGfJEdU for ; Thu, 7 Jul 2011 06:57:43 -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 E906221F8617 for ; Thu, 7 Jul 2011 06:57:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=40621; q=dns/txt; s=iport; t=1310047062; x=1311256662; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=Fa+A7bullQs8okC5F8tX3VNhIYIrxdjNAYEYr7xbui0=; b=V596e631rNo0eKyg7HZBwKYDpO+w4QGUstzkBu3m+XRx5Y1FKVQ60pti jyqhGxH+PMyCSJtiwznSXqd8cqPyEAwgdVkQg5z97SrdMuFDIYtpwQIe5 41frU94WXoCjhzvIIkq3tgmnffyBeaUJnChlp+tGSnax0lcHfyX4uzGsd Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoBANy6FU5Io8UQ/2dsb2JhbABTmGWPNneIe6REnXWGOASHR5AFi0M X-IronPort-AV: E=Sophos;i="4.65,493,1304294400"; d="scan'208";a="100141268" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-1.cisco.com with ESMTP; 07 Jul 2011 13:57:19 +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 p67DvIBX028708; Thu, 7 Jul 2011 13:57:18 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Jul 2011 19:27: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: Thu, 7 Jul 2011 19:27:20 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Content (RFC 4796) attribute in SDP or XML Thread-Index: Acw0mPHhxfeVJEDcQLSYWo3IAZGl7wABDbXgACpfOfAADTnVAAA/CH7wAL12yxAADByJIAAdm3FgAADcErAAQaGFkAAC7JoQAAMpvCAAAObikAAasOngAAJiC3AAGcWykAAW4scQAAPQnyAACOotkAABydoAAABuu6AAAA+MQA== References: <07465C1D981ABC41A344374066AE1A2C38AF6D40CC@TLVMBX01.nice.com><07465C1D981ABC41A344374066AE1A2C38AF6D4376@TLVMBX01.nice.com><07465C1D981ABC41A344374066AE1A2C38AFE9B1C0@TLVMBX01.nice.com> <35BCE99A477D6A4986FB2216D8CF2CFD06E358D2@XMB-BGL-417.cisco.com> From: "Parthasarathi R (partr)" To: "Elwell, John" , "Charles Eckel (eckelcu)" , "Ram Mohan R (rmohanr)" , "Leon Portman" , X-OriginalArrivalTime: 07 Jul 2011 13:57:19.0084 (UTC) FILETIME=[C947DAC0:01CC3CAD] Subject: Re: [siprec] Content (RFC 4796) attribute in SDP or XML X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 13:57:46 -0000 John, I completely agree with you and we will fix MS issue reported in the another mail thread. Apart from this, I'm interested in knowing whether you wish to track the IANA extension of RFC 4796 related to mixed content attribute as part of metadata draft or as a separate generic item. In case you wish to discuss as part of metadata draft, we need to discuss further for having the common understanding. Thanks Partha=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > Sent: Thursday, July 07, 2011 7:23 PM > To: Parthasarathi R (partr); Charles Eckel (eckelcu); Ram=20 > Mohan R (rmohanr); Leon Portman; siprec@ietf.org > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML >=20 > Well, my agreement was really conditional on fixing the=20 > definition of MS - see other thread. >=20 > John >=20 >=20 > > -----Original Message----- > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > Sent: 07 July 2011 14:45 > > To: Elwell, John; Charles Eckel (eckelcu); Ram Mohan R=20 > (rmohanr); Leon=20 > > Portman; siprec@ietf.org > > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML > > > > John, > > > > Thanks for your agreement for Content (RFC 4796) attribute in SDP. > > > > Thanks > > Partha > > > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > Sent: Thursday, July 07, 2011 7:05 PM > > > To: Parthasarathi R (partr); Charles Eckel (eckelcu); Ram Mohan R=20 > > > (rmohanr); Leon Portman; siprec@ietf.org > > > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML > > > > > > > > > > > > > -----Original Message----- > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > Sent: 07 July 2011 13:02 > > > > To: Elwell, John; Charles Eckel (eckelcu); Ram Mohan R > > > (rmohanr); Leon > > > > Portman; siprec@ietf.org > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML > > > > > > > > John, > > > > > > > > I understand your mixed video scenario. In case of=20 > mixed audio or=20 > > > > video, it is not possible to retrieve the complete > > > information in SRS > > > > as it is pre-mixed at SRC. It is one of the motivation for > > > having two > > > > m-line with non-mixed stream to SRS. The similar issue is > > raised by > > > > Charles earlier for mixed audio stream wherein current speaker > > > > (participant) has to be noticed using metadata XML. Even > > in case of > > > > mixed audio stream, the loss of some information is > > > unavoidable. Hope > > > > you agree here. In case the intent is to create the > > infrastructure > > > > wherein the mixed stream should not loose the > > information, then we > > > > need the separate discussion. > > > > > > > > I will write the separate mail thread for the architecture=20 > > > > clarification in SRC wherein CS is handling by one SIP UA > > > instance and > > > > RS is handled as separate SIP UA instance. > > > > > > > > SDP is reused for RS media description, in case it is not > > > possible for > > > > SDP to express about specific media description then it is > > > better to > > > > generically develop the extension like IANA registration > > > for RFC 4796 > > > > which helps for other similar mixing applications as well. > > > [JRE] Yes, I am in agreement with using the IANA registry for RFC=20 > > > 4796, and extending it where necessary. My only question=20 > was whether=20 > > > these values are most appropriately sent in SDP > > or in XML. > > > > > > > > > > > From the metadata perspective, Stream in XML is pointing > > > to m-line of > > > > SDP using label attributes. > > > [JRE] Yes, I had forgotten that. I recall an earlier=20 > > > misunderstanding to do with this. I don't think that is=20 > clear in the=20 > > > metadata draft, so I will comment separately on that. > > > However, if this is the common understanding, I can see=20 > that using=20 > > > the a=3Dcontent attribute in the RS SDP would be a viable = solution. > > > > > > John (as individual) > > > > > > > > > > > > > SDP points to raw media. XML is used to create > > association which is > > > > not possible in SDP. Participant, session to Stream > > grouping is not > > > > possible to achieve in SDP which forces us to look for XML=20 > > > > representation. But in case of content-type scenario, it > > > is possible > > > > to make it happen. > > > > > > > > Please read inline > > > > > > > > Thanks > > > > Partha > > > > > > > > > -----Original Message----- > > > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > > Sent: Thursday, July 07, 2011 12:36 PM > > > > > To: Charles Eckel (eckelcu); Ram Mohan R (rmohanr); > > > Parthasarathi R > > > > > (partr); Leon Portman; siprec@ietf.org > > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in=20 > SDP or XML > > > > > > > > > > Charles, > > > > > > > > > > I see how it COULD be done in the way you describe. I > > > just feel it > > > > > is architecturally wrong to describe the CS MS as part of > > > the RS MS > > > > > description (i.e., the RS SDP). > > > > > > > > In case the intent is to pass CS MS description, I > > > agree with > > > > you. IIRC, charles proposed to use the explicit mixed > > content-type > > > > which is more appropriate to be passed in RS SDP to provide the=20 > > > > description about that specific media. > > > > > > > > > > > > > > However, I can also give a more specific reason. Suppose CS > > > > > MS1 is slides and CS MS2 is speaker video. But the XML > > > does not tell > > > > > me that CS MS1 is slides and CS MS1 is speaker video. > > Both CS MS1 > > > > > and CS MS2 are combined into RS MS1 (slides + speaker). > > > > > > > > The question here is how it is possible for any UA to=20 > > > > represent > > > > (slides+speaker) in SDP? In case it is not well defined, > > > let us work > > > > for it > > > > > > > > The XML metadata tells me that at a given > > > > > time Participant P1 contributed to CS MS1 and P2 > > > contributed to CS > > > > > MS2. How can I tell that P1 contributed to slides and > > > > > P2 contributed to speaker? > > > > > > > > In the mixed stream, we lose the data in SRC > > > because actual > > > > media is mixed. The system shall be designed to send the > > > media stream > > > > separately or we have to find the generic way to group=20 > the stream=20 > > > > together > > > > > > > > > > > > > > See also below: > > > > > > > > > > > -----Original Message----- > > > > > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > > > > Sent: 06 July 2011 21:05 > > > > > > To: Ram Mohan R (rmohanr); Elwell, John; Parthasarathi R > > > > > (partr); Leon > > > > > > Portman; siprec@ietf.org > > > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in > > SDP or XML > > > > > > > > > > > > RFC 4796 has registered the following values: > > > > > > > > > > > > slides RFC 4796 =20 > Presentation slides > > > > > > speaker RFC 4796 Image from > > the speaker > > > > > > sl RFC 4796 Sign language > > > > > > main RFC 4796 Main media stream > > > > > > alt RFC 4796 Alternative > > > media stream > > > > > > > > > > > > Suppose we register the following new values: > > > > > > > > > > > > siprec1 RFC xxxx SIPREC value 1 > > > > > > siprec2 RFC xxxx SIPREC value 2 > > > > > > siprec3 RFC xxxx SIPREC value 3 > > > > > > > > > > > > If the CS has a media lines with the following content > > > attributes > > > > > > > > > > > > CS MS1 - slides > > > > > > CS MS2 - main > > > > > > CS MS3 - siprec1 > > > > > > CS MS4 - siprec2 > > > > > > > > > > > > SRC sends two media streams to RS. RS MS1 is essentially > > > > CS MS1. RS > > > > > > MS2 is some composition of CS MS2, CS MS3 and CS MS4. > > > > > > This could be represented using the content attribute as: > > > > > > > > > > > > RS MS1 - slides > > > > > > RS MS2 - main, siprec1, siprec2 > > > > > > > > > > > > If this is all we think is required, using the content > > > > > attribute does > > > > > > seem sufficient. However, my understanding is people want > > > > > to be able > > > > > > to convey something other than the simple concatenation > > > > of content > > > > > > attribute values, and for that reason, prefer to use > > > XML. In this > > > > > > case, the desired set of values is not bound by > > > anything we will > > > > > > define in SIPREC. That is my understanding as to why XML is > > > > > preferred > > > > > > over the RFC > > > > > > 4796 content attribute. > > > > > [JRE] That was not my motivation, but perhaps others had > > > > that in mind. > > > > > > > > > > John (as individual) > > > > > > > > > > > > > > > > > Cheers, > > > > > > Charles > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Ram Mohan R (rmohanr) > > > > > > > Sent: Wednesday, July 06, 2011 12:33 AM > > > > > > > To: Elwell, John; Parthasarathi R (partr); Charles Eckel > > > > > (eckelcu); > > > > > > Leon Portman; siprec@ietf.org > > > > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in > > > SDP or XML > > > > > > > > > > > > > > Just on this one > > > > > > > > > > > > > > > RS media stream is a mixed content type stream > > > > > > of "current > > > > > > > > speaker video" and "room video" and the resultant shall > > > > > > be named as > > > > > > > > "mixed current speaker video & room video"=20 > which shall be > > > > > > passed as > > > > > > > > new content type extension to SRS > > > > > > > [JRE] Right, so you agree this can't be passed in the RS > > > > > > SDP. I would > > > > > > challenge the need to define > > > > > > > (and register) a new RFC 4796 value "mixed current > > > > speaker video & > > > > > > room video". We have two MS > > > > > > > elements (representing the two CS video streams for > > > > > current speaker > > > > > > and room. Why can't we just place > > > > > > > the respective RFC 4796 content types in the respective > > > > > MS elements? > > > > > > And why does it need to be as > > > > > > > extension data - why can't it be standardized=20 > from day one? > > > > > > > > > > > > > > My thought here is since we have new content types > > > > "mixed current > > > > > > speaker video & room video" we need > > > > > > > to register/extend RFC 4796 for the same and send in RS > > > > > SDP. I would > > > > > > prefer this approach instead of > > > > > > > sending it through recording metadata XML. Of course > > > we need to > > > > > > discuss this in AVT to get their > > > > > > > opinion. > > > > > > > > > > > > > > Regards, > > > > > > > Ram > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: siprec-bounces@ietf.org > > > > > [mailto:siprec-bounces@ietf.org] On > > > > > > > > Behalf Of Elwell, John > > > > > > > > Sent: Wednesday, July 06, 2011 12:05 PM > > > > > > > > To: Parthasarathi R (partr); Charles Eckel (eckelcu); > > > > > > Leon Portman; > > > > > > > > siprec@ietf.org > > > > > > > > Subject: Re: [siprec] Content (RFC 4796) attribute in > > > > SDP or XML > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > > > > > > Sent: 05 July 2011 19:06 > > > > > > > > > To: Charles Eckel (eckelcu); Leon Portman; > > Elwell, John; > > > > > > > > > siprec@ietf.org > > > > > > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in > > > > > SDP or XML > > > > > > > > > > > > > > > > > > John, > > > > > > > > > > > > > > > > > > Please read inline. > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > Partha > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Charles Eckel (eckelcu) > > > > > > > > > > Sent: Tuesday, July 05, 2011 10:44 PM > > > > > > > > > > To: Leon Portman; Elwell, John; Parthasarathi R > > > (partr); > > > > > > > > > > siprec@ietf.org > > > > > > > > > > Subject: RE: [siprec] Content (RFC 4796)=20 > attribute in > > > > > > SDP or XML > > > > > > > > > > > > > > > > > > > > Okay by me. > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > Charles > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > > > > > > > > > > Sent: Tuesday, July 05, 2011 8:42 AM > > > > > > > > > > > To: Elwell, John; Parthasarathi R (partr); > > > Charles Eckel > > > > > > > > > (eckelcu); > > > > > > > > > > > siprec@ietf.org > > > > > > > > > > > Subject: RE: [siprec] Content (RFC 4796) > > > > > attribute in SDP or > > > > > > XML > > > > > > > > > > > > > > > > > > > > > > I completely agree with the below. > > > > > > > > > > > > > > > > > > > > > > Leon > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Elwell, John > > > > > > [mailto:john.elwell@siemens-enterprise.com] > > > > > > > > > > > Sent: Tuesday, July 05, 2011 5:44 PM > > > > > > > > > > > To: Parthasarathi R (partr); Leon Portman; > > > Charles Eckel > > > > > > > > > (eckelcu); > > > > > > > > > > > siprec@ietf.org > > > > > > > > > > > Subject: RE: [siprec] Content (RFC 4796) > > > > > attribute in SDP or > > > > > > XML > > > > > > > > > > > > > > > > > > > > > > (as chair) > > > > > > > > > > > We should try to avoid opening up old issues. > > > I think we > > > > > > > > > > had agreed that: > > > > > > > > > > > - RS SDP describes the RS, and therefore just > > > > > describes how > > > > > > > > > > recordable media is delivered to the SRS. > > > > > > > > > > > It does not describe how media is delivered > > between CS > > > > > > > > > > endpoints as part of the CS. > > > > > > > > > > > - Therefore anything to do with the CS (i.e., > > > > the session > > > > > > being > > > > > > > > > > > recorded) needs to be delivered to the SRS > > as metadata > > > > > > > > > > (i.e., in XML). > > > > > > > > > > > - We don't see a need to standardize delivery > > > of things > > > > > > > > > > like CS codecs > > > > > > > > > > > in the metadata, but that could be done using the > > > > > extension > > > > > > > > > > mechanism. > > > > > > > > > > > > > > > > > > > > Hope everyone agree here that CS SDP > > > > > > information could be > > > > > > > > > passed as extension-data. attribute within > > > > > > > > > > > > > > > may help to achieve this requirement. > > > > > > > > [JRE] Or even as the standardized part of an MS element > > > > > > if we wish. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Focusing now on the content attribute, I don't > > > > > > think there is > > > > > > any > > > > > > > > > > > disagreement that the SRS needs to know the > > > content type > > > > > > (e.g., > > > > > > > > > > > presentation) of a media stream. The SRC=20 > can obtain > > > > > > this from > > > > > > the > > > > > > > > > > > a=3Dcontent attribute of the CS SDP. The > > > > discussion is about > > > > > > > > > > whether this content attribute should be conveyed > > > > > to the SRS: > > > > > > > > > > > A) as an a=3Dcontent attribute of the RS SDP, or > > > > > > > > > > > B) within the metadata XML. > > > > > > > > > > > > > > > > > > > > > > (as individual) > > > > > > > > > > > According to past decisions, there is perhaps > > > > an argument > > > > > > > > > > for B). If, > > > > > > > > > > > for example, we wanted to convey the fact that > > > > a CS media > > > > > > > > > > stream was > > > > > > > > > > > subject to 256-bit encryption, this > > > information would go > > > > > > > > > in the XML > > > > > > > > > > > > > > > > > > Here I have the doubt. In case 256-bit > > > > > > encryption is not > > > > > > > > used > > > > > > > > > by RS SDP, Please let me know the reason for > > > > passing the key > > > > > > > > > information to SRS because RS SDP is not > > > encrypted in that > > > > > > > > > fashion. > > > > > > > > > > > > > > [JRE] I did not suggest passing the CS keying=20 > material to > > > > > > the SRS. I > > > > > > > > just suggested passing the information that the CS media > > > > > > stream used > > > > > > > > 256 bit encryption. Perhaps this was a bad example - > > > > it was just > > > > > > meant > > > > > > > > to illustrate the general principle that information > > > > > about the CS > > > > > > > > should be passed in metadata XML. > > > > > > > > > > > > > > > > > > > > > > > > > > > > (it can't go in the RS SDP, because the RS > > > might not use > > > > > > > > > > 256-bit encryption. Similarly, one could > > argue that the > > > > > > > > > > content type of a CS media stream should go in the > > > > > XML, not in > > > > > > > > > > the RS SDP. > > > > > > > > > I'm seeing content-type attribute as one of > > > > > > the extension > > > > > > of > > > > > > > > > SDP a=3D attribute. In general, it is possible to > > convert CS > > > > > > > > mediastream > > > > > > > > > content type to RS media stream content type > > > because SRC RS > > > > > > > > > media stream is formed based on CS media stream > > > > except for the > > > > > > mixing scenarios > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I could even imagine cases where the content > > > > type of a CS > > > > > > > > > > media stream > > > > > > > > > > > does not equal the content type of an RS > > media stream, > > > > > > > > > > e.g., where the > > > > > > > > > > > SRC combines the current speaker video and the > > > > room video > > > > > > > > > into two > > > > > > > > > > > videos side-by-side in the same RS media stream. > > > > > > > > > > > > > > > > > > RS media stream is a mixed content > > type stream of > > > > > > "current > > > > > > > > > speaker video" and "room video" and the resultant > > > > > shall be named > > > > > > as > > > > > > > > > "mixed current speaker video & room video" which > > > > > shall be passed > > > > > > > > > as new content type extension to SRS > > > > > > > > [JRE] Right, so you agree this can't be passed in the > > > > RS SDP. I > > > > > > would > > > > > > > > challenge the need to define (and register) a new RFC > > > > 4796 value > > > > > > "mixed > > > > > > > > current speaker video & room video". We have two MS > > > elements > > > > > > > > (representing the two CS video streams for current > > > > > > speaker and room. > > > > > > > > Why can't we just place the respective RFC 4796 content > > > > > > types in the > > > > > > > > respective MS elements? And why does it need to be as > > > > > > extension data > > > > > > - > > > > > > > > why can't it be standardized from day one? > > > > > > > > > > > > > > > > John (as individual) > > > > > > > > > > > > > > > > > > > > > > > > > > In the > > > > > > > > > > metadata these would be two media streams, each > > > > > with its own > > > > > > > > > > content type, but both would refer to the same RS > > > > > > media stream. > > > > > > > > > > > > > > > > > > > > It will be problematic approach because the > > > > > > actual media > > > > > > and > > > > > > > > > metadata are not related explicitly. As per=20 > the current > > > > > > description, > > > > > > > > > there are two element with different > > > > unique-id uses > > > > > > > > > same label in SDP with different XML element > > > > ("content-type") > > > > > > > > > within them. > > > > > > The > > > > > > > > > issue is whether media has stream1 behavior or stream2 > > > > > > behavior or > > > > > > > > > mixed. We will able to extent XML element for > > > having single > > > > > > > > > interpretation but it is not fully clarified in the > > > > > > draft now. The > > > > > > > > > bottom-up matching like stream1 & stream2 has same > > > > > label element > > > > > > > > > and it has to be grouped together is not > > explicit in this > > > > > > > > > scenario. We > > > > > > need > > > > > > > > > more investigation both information is=20 > required but not > > > > > > the actual > > > > > > > > > media. Please correct me in I'm missing something > > > > > > > > > > > > > > > > > > > > > > > John > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: Parthasarathi R (partr) > > > [mailto:partr@cisco.com] > > > > > > > > > > > > Sent: 04 July 2011 08:08 > > > > > > > > > > > > To: Leon Portman; Charles Eckel (eckelcu); > > > > > Elwell, John; > > > > > > > > > > > > siprec@ietf.org > > > > > > > > > > > > Subject: RE: [siprec] Content (RFC 4796) > > > > > > attribute in SDP or > > > > > > > > XML > > > > > > > > > > > > > > > > > > > > > > > > Leon, > > > > > > > > > > > > > > > > > > > > > > > > Please read inline. > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > Partha > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > From: Leon Portman > > [mailto:Leon.Portman@nice.com] > > > > > > > > > > > > > Sent: Monday, July 04, 2011 12:11 PM > > > > > > > > > > > > > To: Parthasarathi R (partr); Charles Eckel > > > > (eckelcu); > > > > > > Elwell, > > > > > > > > > > > > > John; siprec@ietf.org > > > > > > > > > > > > > Subject: RE: [siprec] Content (RFC 4796) > > > > attribute in > > > > > > > > > SDP or XML > > > > > > > > > > > > > > > > > > > > > > > > > > Partha Hi > > > > > > > > > > > > > > > > > > > > > > > > > > Please see below. > > > > > > > > > > > > > > > > > > > > > > > > > > Leon > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > From: Parthasarathi R (partr) > > > > [mailto:partr@cisco.com] > > > > > > > > > > > > > Sent: Sunday, July 03, 2011 7:50 PM > > > > > > > > > > > > > To: Leon Portman; Charles Eckel (eckelcu); > > > > > Elwell, John; > > > > > > > > > > > > > siprec@ietf.org > > > > > > > > > > > > > Subject: RE: [siprec] Content (RFC 4796) > > > > attribute in > > > > > > > > > SDP or XML > > > > > > > > > > > > > > > > > > > > > > > > > > Leon, > > > > > > > > > > > > > > > > > > > > > > > > > > Please read inline. > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > Partha > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > From: Leon Portman > > [mailto:Leon.Portman@nice.com] > > > > > > > > > > > > > Sent: Sunday, July 03, 2011 4:13 PM > > > > > > > > > > > > > To: Charles Eckel (eckelcu); Elwell, John; > > > > > > Parthasarathi R > > > > > > > > > > > > > (partr); siprec@ietf.org > > > > > > > > > > > > > Subject: RE: [siprec] Content (RFC 4796) > > > > attribute in > > > > > > > > > SDP or XML > > > > > > > > > > > > > > > > > > > > > > > > > > I do prefer that metadata XML will be as > > > > > > self-contained as > > > > > > > > > > > > > possible and not rely on conveying some > > > data via RS > > > > > > > > > SDP. RS SDP > > > > > > > > > > > > > should only be used to recording > > establishment and > > > > > > > > > > negotiation and > > > > > > > > > > > > > not as a mechanism for metadata reporting. > > > > > > > > > > > > > > > > > > > > > > > > > > In case Metadata XML has to be > > > > > self-contained, > > > > > > the > > > > > > > > > > > > > complete SDP has to be converted into XML > > > format or > > > > > > > > > > else XML has > > > > > > > > > > > > > to have sort of XML attribute which > > > > > > carries SDP. > > > > > > > > > > > > > Creating mapping for each SDP attribute > > > > with metadata > > > > > > > > > > XML element > > > > > > > > > > > > > does not seems to be feasible > > > > > > > > > > > > > > > > > > > > > > > > > > [LeonP] But if CS SDP is different=20 > from RS SDP, > > > > > > > > > anyway you will > > > > > > > > > > > > > need to encapsulate the original RS SDP, so > > > > why not in > > > > > > XML? > > > > > > > > > > > > > > > > > > > > > > > > I guess that the confusion is > > here. In the > > > > > > > > > > current format, > > > > > > > > > > > > RS SDP is only carried towards SRS and CS > > SDP is not > > > > > > forwarded. > > > > > > > > > > > > This design > > > > > > > > > > > > is closed as part of ticket #71 > > > > > > > > > > > > > > > > > > > > > > (http://www.ietf.org/mail- > > > > > > > > archive/web/siprec/current/msg02106.html). > > > > > > > > > > > > Please bring up with the usecase for CS SDP > > > > if required > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Otherwise we will not be able to reuse same > > > > format for > > > > > > > > > > reporting > > > > > > > > > > > > > metadata via web services As per > > > > IETF-80 and > > > > > > > > > > last interim > > > > > > > > > > > > > meeting, there is no intent of reusing > > > this metadata > > > > > > > > > > XML in other > > > > > > > > > > > > > protocol. In case reusing same format for > > > webservice > > > > > > > > > or XMPP is > > > > > > > > > > > > > the intent, the current metadata XML > > > > mechanism is not > > > > > > > > > > the appropriate. > > > > > > > > > > > > > This was discussed in > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > http://www.ietf.org/mail-archive/web/siprec/current/msg02151.html, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > http://www.ietf.org/mail- > > > > > > > > archive/web/siprec/current/msg02155.html(1s > > > > > > > > > > > > t > > > > > > > > > > > > > point in format slide). In case you have > > > difference > > > > > > > > > of opinion > > > > > > > > > > > > > even after this multiple discussion, > > let us again > > > > > > > > > > discuss at IETF-81. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [LeonP] I was not proposing replacing SIP > > > > with another > > > > > > > > > > transport > > > > > > > > > > > > > layer, just wanted to keep other options open. > > > > > > > > > > > > > > > > > > > > > > > > Current metadata format is > > > customized for SIP > > > > > > > > > > transport. In > > > > > > > > > > > > case we need to keep the options open,=20 > the format > > > > > > has to be > > > > > > > > > > > > revisited from the scratch. In our > > > analysis, we notice > > > > > > > > > that REST > > > > > > > > > > > > architecture with Metadata XML is best fit for > > > > > HTTP, XMPP > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I am > > > > > > > > > > > > > very big supporter for metadata over > > SIP reporting > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, Me too.. > > > > > > > > > > > > > > > > > > > > > > > > > or as dedicated SIP session. > > > > > > > > > > > > > In case Metadata is separate session > > > > > > from RS, RS > > > > > > > > > > > > > attribute like RS-id MUST be included within > > > > > > XML. This was > > > > > > > > > > > > > discussed at > > > > > > > > > > > > > http://www.ietf.org/mail- > > > > > > > > archive/web/siprec/current/msg02013.h > > > > > > > > > > > > tml. Could you please explain reason for > > > the dedicated > > > > > > > > > > SIP > session > > > > > > > > > > > > for metadata. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [LeonP] The main use case is Recording on > > > > > > Demand, that is > > > > > > > > > > > > > triggered by SRS. In such case it will be > > > > very useful > > > > > > > > > > to have just > > > > > > > > > > > > > one SIP session and send all metadata over it > > > > > (like CTI > > > > > > > > > > > > > link) and then only trigger recording (via > > > > > external SRC > > > > > > > > > > > > > interface) only for specific call segments. > > > > > > > > > > > > > > > > > > > > > > > > > I understand the current > > > > implementation wherein > > > > > > > > > > few of the > > > > > > > > > > > > metadata like CDR records is passed > > through non-sip > > > > > > > > > > interface. It is > > > > > > > > > > > > outside the scope of SIPREC. The > > global-id in format > > > > > > > > > > shall be used > > > > > > > > > > > > to correlate. Please let me know in case > > any current > > > > > > > > > > SIPREC metadata > > > > > > > > > > > > attribute MUST be passed through this CTS link. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > As for examples, the basic information as > > > > media type, > > > > > > labels, > > > > > > > > > > > > > volume etc. Any application level data can be > > > > > relevant. > > > > > > Even > > > > > > > > > > > > > indication of encryption (for a case > > > where RS is not > > > > > > > > > encrypted) > > > > > > > > > > > > > > > > > > > > > > > > > > Leon > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > From: siprec-bounces@ietf.org=20 > > > > > > > > > > > > > [mailto:siprec-bounces@ietf.org] On Behalf > > > > Of Charles > > > > > > Eckel > > > > > > > > > > > > (eckelcu) > > > > > > > > > > > > > Sent: Wednesday, June 29, 2011 7:17 PM > > > > > > > > > > > > > To: Elwell, John; Parthasarathi R (partr); > > > > > > siprec@ietf.org > > > > > > > > > > > > > Subject: Re: [siprec] Content (RFC 4796) > > > > attribute in > > > > > > > > > SDP or XML > > > > > > > > > > > > > > > > > > > > > > > > > > I think it is sufficient, especially since we > > > > > can assign > > > > > > new > > > > > > > > > > > > > values if necessary. > > > > > > > > > > > > > Are there any examples of what people=20 > think they > > > > > > > > > might want to > > > > > > > > > > > > > capture in the SDP and/or metadata field? > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > Charles > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > From: siprec-bounces@ietf.org > > > > > > > > > > [mailto:siprec-bounces@ietf.org] > > > > > > > > > > > > > > On > > > > > > > > > > > > > Behalf Of Elwell, John > > > > > > > > > > > > > > Sent: Tuesday, June 28, 2011 3:11 AM > > > > > > > > > > > > > > To: Parthasarathi R (partr); siprec@ietf.org > > > > > > > > > > > > > > Subject: Re: [siprec] Content (RFC 4796) > > > > > attribute in > > > > > > > > > > SDP or XML > > > > > > > > > > > > > > > > > > > > > > > > > > > > I would like other opinions on whether the > > > > > > SDP a=3Dcontent > > > > > > > > > > > > > attribute in > > > > > > > > > > > > > the RS SDP has the correct > > > > > > > > > > > > > > semantics for representing the content > > > type of the > > > > > > > > > > > > recorded CS media > > > > > > > > > > > > > stream. > > > > > > > > > > > > > > > > > > > > > > > > > > > > John > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > > From: Parthasarathi R (partr) > > > > > > [mailto:partr@cisco.com] > > > > > > > > > > > > > > > Sent: 28 June 2011 10:45 > > > > > > > > > > > > > > > To: Elwell, John; siprec@ietf.org > > > > > > > > > > > > > > > Cc: Ram Mohan R (rmohanr); Paul Kyzivat > > > > (pkyzivat) > > > > > > > > > > > > > > > Subject: RE: Content (RFC 4796) attribute > > > > > in SDP or > > > > > > XML > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > John, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > In case if it is the argument of=20 > whether CS > > > > > > MS content > > > > > > > > > > > > > type or RS MS > > > > > > > > > > > > > > > > > > > > > > > > > > > > content type in the metadata, it is > > > > > better for us to > > > > > > > > > > > > > re-open ticket > > > > > > > > > > > > > > > #71 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > (http://www.ietf.org/mail- > > > > > > > > archive/web/siprec/current/msg02106.html). > > > > > > > > > > > > > > > Please let me know your opinion here. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The basic idea in metadata format is to > > > > re-use as > > > > > > > > > > much as SDP > > > > > > > > > > > > > > > attribute (like direction, content) in > > > > > > media level for > > > > > > > > > > > > RS dialog > > > > > > > > > > > > > > > (using SDP label attribute as a > > pointer) until > > > > > > otherwise > > > > > > > > > > > > > there is a > > > > > > > > > > > > > > > restriction in using in such=20 > manner. As per > > > > > > RFC 4796, > > > > > > > > > > > > there is no > > > > > > > > > > > > > > > such restriction and so, I prefer to reuse > > > > > > as content > > > > > > SDP > > > > > > > > > > > > > attribute > > > > > > > > > > > > > > > rather than introducing the new > > > > > > > > > > > element for > > > > > > > > > > > > > > > this purpose. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > Partha > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > > From: Elwell, John > > > > > > > > > > [mailto:john.elwell@siemens-enterprise.com] > > > > > > > > > > > > > > > Sent: Monday, June 27, 2011 1:18 PM > > > > > > > > > > > > > > > To: Parthasarathi R (partr);=20 > siprec@ietf.org > > > > > > > > > > > > > > > Cc: Ram Mohan R (rmohanr); Paul Kyzivat > > > > (pkyzivat) > > > > > > > > > > > > > > > Subject: RE: Content (RFC 4796) attribute > > > > > in SDP or > > > > > > XML > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > > > From: Parthasarathi R (partr) > > > > > > [mailto:partr@cisco.com] > > > > > > > > > > > > > > > > Sent: 27 June 2011 08:08 > > > > > > > > > > > > > > > > To: siprec@ietf.org; Elwell, John > > > > > > > > > > > > > > > > Cc: Ram Mohan R (rmohanr); Paul Kyzivat > > > > > (pkyzivat) > > > > > > > > > > > > > > > > Subject: Content (RFC 4796) attribute in > > > > > > SDP or XML > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > As per the last interim SIPREC meeting, > > > > > there is a > > > > > > > > > > > > consensus to > > > > > > > > > > > > > > > > describe the content of an MS using RFC > > > > > 4796 & its > > > > > > > > > > > > > > > extension. As per > > > > > > > > > > > > > > > > RFC 4796, the multiple instance of > > > > > > content attribute > > > > > > > > > > > > is possible > > > > > > > > > > > > > to > > > > > > > > > > > > > > > > exist in SDP which shall be used in > > > > RS SDP. SRS > > > > > > > > > > shall group > > > > > > > > > > > > > > > the same > > > > > > > > > > > > > > > > media content types by "content" > > > > attribute in RS > > > > > > > > > > SDP. We are > > > > > > > > > > > > > > > > interested in knowing any specfic > > > > > reason for this > > > > > > > > > > > > > attribute to be > > > > > > > > > > > > > > > > duplicated in Metadata XML. > > > > > > > > > > > > > > > [JRE] I don't have a reason for > > > **duplication**. > > > > > > > > > > > > However, I think > > > > > > > > > > > > > > > there is a valid question to be asked > > > > whether the > > > > > > content > > > > > > > > > > > > > type of an > > > > > > > > > > > > > > > > > > > > > > > > > > > > MS should be represented: > > > > > > > > > > > > > > > A) in XML; or > > > > > > > > > > > > > > > B) in RS SDP as a=3Dcontent. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The content type we are talking=20 > about is an > > > > > > MS content > > > > > > > > > > > > > type, i.e., > > > > > > > > > > > > > > > relating to the CS. One could=20 > argue that the > > > > > > > > > > > > > corresponding RS stream > > > > > > > > > > > > > > > > > > > > > > > > > > > > is NOT the same content type. For example: > > > > > > > > > > > > > > > - CS MS content type is "slides". > > > > > > > > > > > > > > > - RS media stream content type is > > > "recording of > > > > > > slides". > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On this basis, I think the correct > > option for > > > > > > > > > > conveying the MS > > > > > > > > > > > > > content > > > > > > > > > > > > > > > type "slides" is A) (in the XML). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Note that this would not involve > > > > > > duplication. The SDP > > > > > > > > > > > > > > > a=3Dcontent attribute is optional, so we > > > > > need not use > > > > > > > > > > it for the RS. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Perhaps my distinction is too > > > > > theoretical, but I do > > > > > > > > > > > > feel a little > > > > > > > > > > > > > more > > > > > > > > > > > > > > > comfortable using the XML rather than > > > > the RS SDP. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > John (as individual) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Partha > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > last Interim SIPREC meeting Note: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Slide 7: On the question of how to > > > > describe the > > > > > > content > > > > > > > > > > > > > of an MS, > > > > > > > > > > > > > > > > there was no objection to basing this > > > > > on the types > > > > > > in > > > > > > > > > > > > > the RFC 4796 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > registry (new values could be > > > > specified via the > > > > > > > > > > appropriate > > > > > > > > > > > > > > > means if > > > > > > > > > > > > > > > > needed). Paul had a slight concern that > > > > > you might > > > > > > > > > > be mixing > > > > > > > > > > > > > > > multiple > > > > > > > > > > > > > > > > CS MSs into a single RS media stream > > > > and whether > > > > > > > > > > this might > > > > > > > > > > > > > > > result in > > > > > > > > > > > > > > > > cases not describable in this way, but > > > > > in the end > > > > > > > > > > > > accepted the > > > > > > > > > > > > > > > > consensus. It needs to be discussed > > > > on the list > > > > > > > > > > > > whether this is > > > > > > > > > > > > > > > > conveyed in XML or in the RS=20 > SDP a=3Dcontent > > > > > > attribute. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > siprec mailing list siprec@ietf.org=20 > > > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > > > > > >=20 > _______________________________________________ > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > >=20 From partr@cisco.com Thu Jul 7 07:04: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 444941F0C57 for ; Thu, 7 Jul 2011 07:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.273 X-Spam-Level: X-Spam-Status: No, score=-10.273 tagged_above=-999 required=5 tests=[AWL=0.325, 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 CVxKOxOgbCDX for ; Thu, 7 Jul 2011 07:04:52 -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 A46271F0C52 for ; Thu, 7 Jul 2011 07:04:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=9417; q=dns/txt; s=iport; t=1310047491; x=1311257091; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=dDsu2qzfvOrBAbZKUCthn8aQ+tiyQX+i7eamKsHywqA=; b=i7FlbkIQhB3Ad8vjgOYnqvA4w3CYumUXs5BBzMyEgin1uOMQT2PtiNd+ tiFauGhBvOhQY9nQ5KSXrecf4cIE5CPHVMSn4VYKd+OkehN0de+iQYxas j2Wuk2S8ojdQqOQ3HDXBoAC6b523l4ylGYGfOLGqkm5l1l+Hbs+vEUV9v w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsBACW8FU5Io8US/2dsb2JhbABTglGWFI82d61HnXaGOASHR5AFi0M X-IronPort-AV: E=Sophos;i="4.65,493,1304294400"; d="scan'208,217";a="100142949" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-1.cisco.com with ESMTP; 07 Jul 2011 14:04:49 +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 p67E4n9s028625; Thu, 7 Jul 2011 14:04:49 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Jul 2011 19:34:49 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC3CAE.D59AA8CF" Date: Thu, 7 Jul 2011 19:34:49 +0530 Message-ID: In-Reply-To: <07465C1D981ABC41A344374066AE1A2C38AFE9BB8A@TLVMBX01.nice.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Caller preference information in Metadata Thread-Index: Acw8nlS7CXumifrDQ9SGZ9au5tuPnQADYI7gAABYULA= References: <07465C1D981ABC41A344374066AE1A2C38AFE9BB8A@TLVMBX01.nice.com> From: "Parthasarathi R (partr)" To: "Leon Portman" , X-OriginalArrivalTime: 07 Jul 2011 14:04:49.0601 (UTC) FILETIME=[D5CF4B10:01CC3CAE] Subject: Re: [siprec] Caller preference information in 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: Thu, 07 Jul 2011 14:04:53 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC3CAE.D59AA8CF Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Leon, =20 I agree with you that it is not stored currently. I asked this question because there was an earlier discussion wherein participant has to be identified as normal user or media server. Paul, Ram and myself discussed internally and thought that it would be better to have generic caller preference rather than specific single "automata" parameter. I forget to continue the mail thread in SIPREC alias, so initiated after a long time.=20 =20 This attribute shall be added as an optional which helps for better interop in case future application uses this attribute. =20 In case everyone feels that this attribute will never be used, I'm fine with it. =20 Thanks Partha ________________________________ From: Leon Portman [mailto:Leon.Portman@nice.com]=20 Sent: Thursday, July 07, 2011 7:15 PM To: Parthasarathi R (partr); siprec@ietf.org Subject: RE: Caller preference information in Metadata =09 =09 Partha Hi =20 Today we are not receive and store this information. Is it widely accepted?=20 =20 Leon =20 From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi R (partr) Sent: Thursday, July 07, 2011 3:07 PM To: siprec@ietf.org Subject: [siprec] Caller preference information in Metadata =20 Hi all, =20 Caller preference (RFC 3841) information about CS is possible to be passed in extension data of participant. The caller preference like "automata" shall be passed in SIPREC metadata itself in case folks are interested. Please let me know whether "caller preference" attribute shall be added under participant block. =20 Thanks Partha ------_=_NextPart_001_01CC3CAE.D59AA8CF Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Leon,
 
I agree with you that it is not stored currently. = I asked this=20 question because there was an earlier discussion wherein participant has = to be=20 identified as normal user or media server. Paul, Ram and = myself=20 discussed internally and thought that it would be better to have generic = caller=20 preference rather than specific single "automata" parameter. I = forget to=20 continue the mail thread in SIPREC alias, so initiated after a long = time.=20
 
This attribute shall be added as an optional which = helps for=20 better interop in case future application uses this=20 attribute.
 
In case everyone feels that this attribute will = never be used,=20 I'm fine with it.
 
Thanks
Partha

From: Leon Portman=20 [mailto:Leon.Portman@nice.com]
Sent: Thursday, July 07, = 2011 7:15=20 PM
To: Parthasarathi R (partr); = siprec@ietf.org
Subject:=20 RE: Caller preference information in Metadata

Partha=20 Hi

 

Today=20 we are not receive and store  this information. Is it widely = accepted?=20

 

Leon

 

From:=20 siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf = Of=20 Parthasarathi R (partr)
Sent: Thursday, July 07, 2011 = 3:07=20 PM
To: siprec@ietf.org
Subject: [siprec] Caller = preference=20 information in Metadata

 

Hi=20 all,

 

Caller = preference=20 (RFC 3841) information about CS is possible to be passed in extension = data of=20 participant. The caller preference like "automata" shall be passed in = SIPREC=20 metadata itself in case folks are interested. Please let me know = whether=20 "caller preference" attribute shall be added under participant=20 block.

 

Thanks

Partha

= ------_=_NextPart_001_01CC3CAE.D59AA8CF-- From Leon.Portman@nice.com Thu Jul 7 07:06: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 1FFEF21F862D for ; Thu, 7 Jul 2011 07:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0nJPJKqJ0SuT for ; Thu, 7 Jul 2011 07:06:32 -0700 (PDT) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id D395821F85FB for ; Thu, 7 Jul 2011 07:06:31 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.15]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Thu, 7 Jul 2011 17:06:30 +0300 From: Leon Portman To: "Parthasarathi R (partr)" , "siprec@ietf.org" Date: Thu, 7 Jul 2011 17:06:30 +0300 Thread-Topic: Caller preference information in Metadata Thread-Index: Acw8nlS7CXumifrDQ9SGZ9au5tuPnQADYI7gAABYULAAAHB/MA== Message-ID: <07465C1D981ABC41A344374066AE1A2C38AFE9BBAB@TLVMBX01.nice.com> References: <07465C1D981ABC41A344374066AE1A2C38AFE9BB8A@TLVMBX01.nice.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_07465C1D981ABC41A344374066AE1A2C38AFE9BBABTLVMBX01nicec_" MIME-Version: 1.0 Subject: Re: [siprec] Caller preference information in 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: Thu, 07 Jul 2011 14:06:33 -0000 --_000_07465C1D981ABC41A344374066AE1A2C38AFE9BBABTLVMBX01nicec_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It is important distinction (talking to IVR vs person). We should have a wa= y to relay this info to SRS Leon From: Parthasarathi R (partr) [mailto:partr@cisco.com] Sent: Thursday, July 07, 2011 5:05 PM To: Leon Portman; siprec@ietf.org Subject: RE: Caller preference information in Metadata Leon, I agree with you that it is not stored currently. I asked this question bec= ause there was an earlier discussion wherein participant has to be identifi= ed as normal user or media server. Paul, Ram and myself discussed internall= y and thought that it would be better to have generic caller preference rat= her than specific single "automata" parameter. I forget to continue the mai= l thread in SIPREC alias, so initiated after a long time. This attribute shall be added as an optional which helps for better interop= in case future application uses this attribute. In case everyone feels that this attribute will never be used, I'm fine wit= h it. Thanks Partha ________________________________ From: Leon Portman [mailto:Leon.Portman@nice.com] Sent: Thursday, July 07, 2011 7:15 PM To: Parthasarathi R (partr); siprec@ietf.org Subject: RE: Caller preference information in Metadata Partha Hi Today we are not receive and store this information. Is it widely accepted= ? Leon From: siprec-bounces@ietf.org [mailto:sipre= c-bounces@ietf.org] On Behalf Of P= arthasarathi R (partr) Sent: Thursday, July 07, 2011 3:07 PM To: siprec@ietf.org Subject: [siprec] Caller preference information in Metadata Hi all, Caller preference (RFC 3841) information about CS is possible to be passed = in extension data of participant. The caller preference like "automata" sha= ll be passed in SIPREC metadata itself in case folks are interested. Please= let me know whether "caller preference" attribute shall be added under par= ticipant block. Thanks Partha --_000_07465C1D981ABC41A344374066AE1A2C38AFE9BBABTLVMBX01nicec_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It is imp= ortant distinction (talking to IVR vs person). We should have a way to rela= y this info to SRS

&n= bsp;

Leon

=

 

From: Parthasarathi R (partr) [mailto:partr@cisco.com]
Sent: Thursday, July 07, 2011 5:05 PM
To: Leon Portman; sipr= ec@ietf.org
Subject: RE: Caller preference information in Metadat= a

 

Leon,

&n= bsp;

I agree with you that it is not s= tored currently. I asked this question because there was an earlier discuss= ion wherein participant has to be identified as normal user or media s= erver. Paul, Ram and myself discussed internally and thought that it w= ould be better to have generic caller preference rather than specific singl= e "automata" parameter. I forget to continue the mail thread= in SIPREC alias, so initiated after a long time.

 

This attribut= e shall be added as an optional which helps for better interop in case futu= re application uses this attribute.

 

In case everyone feels that = this attribute will never be used, I'm fine with it.

<= p class=3DMsoNormal> 

Thanks

Partha

 

From:= Leo= n Portman [mailto:Leon.Po= rtman@nice.com]
Sent: Thursday, July 07, 2011 7:15 PM
= To: Parthasarathi R (partr); siprec@= ietf.org
Subject: RE: Caller preference information in Metada= ta

Partha Hi

 

Today we are not receive and store  this information.= Is it widely accepted?

<= o:p> 

Leon

 

From: siprec= -bounces@ietf.org [= mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi R (pa= rtr)
Sent: Thursday, July 07, 2011 3:07 PM
To: siprec@ietf.org
Subject: [siprec]= Caller preference information in Metadata

 

Hi all,<= o:p>

 

Caller preference (RFC 3841) information about CS is possibl= e to be passed in extension data of participant. The caller preference like= "automata" shall be passed in SIPREC metadata itself in case fol= ks are interested. Please let me know whether "caller preference"= attribute shall be added under participant block.

 

Th= anks

Partha

= --_000_07465C1D981ABC41A344374066AE1A2C38AFE9BBABTLVMBX01nicec_-- From pkyzivat@alum.mit.edu Thu Jul 7 08:20: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 E67E621F873A for ; Thu, 7 Jul 2011 08:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.297 X-Spam-Level: X-Spam-Status: No, score=-2.297 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bx6rABhD20dM for ; Thu, 7 Jul 2011 08:20:14 -0700 (PDT) Received: from qmta08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by ietfa.amsl.com (Postfix) with ESMTP id 6148E21F8733 for ; Thu, 7 Jul 2011 08:20:14 -0700 (PDT) Received: from omta07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by qmta08.emeryville.ca.mail.comcast.net with comcast id 53He1h0021GXsucA83LBWb; Thu, 07 Jul 2011 15:20:11 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta07.emeryville.ca.mail.comcast.net with comcast id 53L91h00y0tdiYw8U3LAkb; Thu, 07 Jul 2011 15:20:11 +0000 Message-ID: <4E15CEAB.3030901@alum.mit.edu> Date: Thu, 07 Jul 2011 11:20:11 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: siprec@ietf.org References: <07465C1D981ABC41A344374066AE1A2C38AFE9BB8A@TLVMBX01.nice.com> <07465C1D981ABC41A344374066AE1A2C38AFE9BBAB@TLVMBX01.nice.com> In-Reply-To: <07465C1D981ABC41A344374066AE1A2C38AFE9BBAB@TLVMBX01.nice.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] Caller preference information in 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: Thu, 07 Jul 2011 15:20:15 -0000 Presumably we are really talking about "callee" capabilities, not preferences. Namely, the feature tags present as header parameters on the contact URI from each signaling participant. That is info that belongs to the association of the participant to a CS. We might just want to include the entire Contact header, or all of its header parameters. Thanks, Paul On 7/7/11 10:06 AM, Leon Portman wrote: > It is important distinction (talking to IVR vs person). We should have a > way to relay this info to SRS > > Leon > > *From:*Parthasarathi R (partr) [mailto:partr@cisco.com] > *Sent:* Thursday, July 07, 2011 5:05 PM > *To:* Leon Portman; siprec@ietf.org > *Subject:* RE: Caller preference information in Metadata > > Leon, > > I agree with you that it is not stored currently. I asked this question > because there was an earlier discussion wherein participant has to be > identified as normal user or media server. Paul, Ram and myself > discussed internally and thought that it would be better to have generic > caller preference rather than specific single "automata" parameter. I > forget to continue the mail thread in SIPREC alias, so initiated after a > long time. > > This attribute shall be added as an optional which helps for better > interop in case future application uses this attribute. > > In case everyone feels that this attribute will never be used, I'm fine > with it. > > Thanks > > Partha > > ------------------------------------------------------------------------ > > *From:*Leon Portman [mailto:Leon.Portman@nice.com] > > *Sent:* Thursday, July 07, 2011 7:15 PM > *To:* Parthasarathi R (partr); siprec@ietf.org > *Subject:* RE: Caller preference information in Metadata > > Partha Hi > > Today we are not receive and store this information. Is it widely > accepted? > > Leon > > *From:*siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] > *On Behalf Of > *Parthasarathi R (partr) > *Sent:* Thursday, July 07, 2011 3:07 PM > *To:* siprec@ietf.org > *Subject:* [siprec] Caller preference information in Metadata > > Hi all, > > Caller preference (RFC 3841) information about CS is possible to be > passed in extension data of participant. The caller preference like > "automata" shall be passed in SIPREC metadata itself in case folks > are interested. Please let me know whether "caller preference" > attribute shall be added under participant block. > > Thanks > > Partha > > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From john.elwell@siemens-enterprise.com Thu Jul 7 09:22: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 2BA3B1F0C34 for ; Thu, 7 Jul 2011 09:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.122 X-Spam-Level: X-Spam-Status: No, score=-106.122 tagged_above=-999 required=5 tests=[AWL=-0.123, 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 koQlKrXMLrHF for ; Thu, 7 Jul 2011 09:22:50 -0700 (PDT) Received: from mail174.messagelabs.com (mail174.messagelabs.com [85.158.138.51]) by ietfa.amsl.com (Postfix) with SMTP id 9CAEE21F874A for ; Thu, 7 Jul 2011 09:22:42 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1310055761!17681601!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 6528 invoked from network); 7 Jul 2011 16:22:41 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-15.tower-174.messagelabs.com with SMTP; 7 Jul 2011 16:22:41 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 2A4E41EB83D3; Thu, 7 Jul 2011 18:22:41 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 7 Jul 2011 18:22:40 +0200 From: "Elwell, John" To: "Parthasarathi R (partr)" , "Charles Eckel (eckelcu)" , "Ram Mohan R (rmohanr)" , Leon Portman , "siprec@ietf.org" Date: Thu, 7 Jul 2011 18:22:40 +0200 Thread-Topic: [siprec] Content (RFC 4796) attribute in SDP or XML Thread-Index: Acw0mPHhxfeVJEDcQLSYWo3IAZGl7wABDbXgACpfOfAADTnVAAA/CH7wAL12yxAADByJIAAdm3FgAADcErAAQaGFkAAC7JoQAAMpvCAAAObikAAasOngAAJiC3AAGcWykAAW4scQAAPQnyAACOotkAABydoAAABuu6AAAA+MQAAFGM1g Message-ID: References: <07465C1D981ABC41A344374066AE1A2C38AF6D40CC@TLVMBX01.nice.com><07465C1D981ABC41A344374066AE1A2C38AF6D4376@TLVMBX01.nice.com><07465C1D981ABC41A344374066AE1A2C38AFE9B1C0@TLVMBX01.nice.com> <35BCE99A477D6A4986FB2216D8CF2CFD06E358D2@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] Content (RFC 4796) attribute in SDP or XML X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 16:22:53 -0000 Partha, It is not clear to me that we need to extend the RFC 4796 registry at this = point. For example, it has been argued that we could handle a mixed speaker= + slides RS stream just by including both values in the a=3Dcontent attrib= ute. If and when we find other types that we want adding to the RFC 4796 re= gistry, I think that should be covered in separate draft(s). John > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > Sent: 07 July 2011 14:57 > To: Elwell, John; Charles Eckel (eckelcu); Ram Mohan R > (rmohanr); Leon Portman; siprec@ietf.org > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML > > John, > > I completely agree with you and we will fix MS issue reported in the > another mail thread. > > Apart from this, I'm interested in knowing whether you wish > to track the > IANA extension of RFC 4796 related to mixed content attribute > as part of > metadata draft or as a separate generic item. In case you wish to > discuss as part of metadata draft, we need to discuss further > for having > the common understanding. > > Thanks > Partha > > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Thursday, July 07, 2011 7:23 PM > > To: Parthasarathi R (partr); Charles Eckel (eckelcu); Ram > > Mohan R (rmohanr); Leon Portman; siprec@ietf.org > > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML > > > > Well, my agreement was really conditional on fixing the > > definition of MS - see other thread. > > > > John > > > > > > > -----Original Message----- > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > Sent: 07 July 2011 14:45 > > > To: Elwell, John; Charles Eckel (eckelcu); Ram Mohan R > > (rmohanr); Leon > > > Portman; siprec@ietf.org > > > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML > > > > > > John, > > > > > > Thanks for your agreement for Content (RFC 4796) attribute in SDP. > > > > > > Thanks > > > Partha > > > > > > > -----Original Message----- > > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > Sent: Thursday, July 07, 2011 7:05 PM > > > > To: Parthasarathi R (partr); Charles Eckel (eckelcu); > Ram Mohan R > > > > (rmohanr); Leon Portman; siprec@ietf.org > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > > Sent: 07 July 2011 13:02 > > > > > To: Elwell, John; Charles Eckel (eckelcu); Ram Mohan R > > > > (rmohanr); Leon > > > > > Portman; siprec@ietf.org > > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in > SDP or XML > > > > > > > > > > John, > > > > > > > > > > I understand your mixed video scenario. In case of > > mixed audio or > > > > > video, it is not possible to retrieve the complete > > > > information in SRS > > > > > as it is pre-mixed at SRC. It is one of the motivation for > > > > having two > > > > > m-line with non-mixed stream to SRS. The similar issue is > > > raised by > > > > > Charles earlier for mixed audio stream wherein current speaker > > > > > (participant) has to be noticed using metadata XML. Even > > > in case of > > > > > mixed audio stream, the loss of some information is > > > > unavoidable. Hope > > > > > you agree here. In case the intent is to create the > > > infrastructure > > > > > wherein the mixed stream should not loose the > > > information, then we > > > > > need the separate discussion. > > > > > > > > > > I will write the separate mail thread for the architecture > > > > > clarification in SRC wherein CS is handling by one SIP UA > > > > instance and > > > > > RS is handled as separate SIP UA instance. > > > > > > > > > > SDP is reused for RS media description, in case it is not > > > > possible for > > > > > SDP to express about specific media description then it is > > > > better to > > > > > generically develop the extension like IANA registration > > > > for RFC 4796 > > > > > which helps for other similar mixing applications as well. > > > > [JRE] Yes, I am in agreement with using the IANA > registry for RFC > > > > 4796, and extending it where necessary. My only question > > was whether > > > > these values are most appropriately sent in SDP > > > or in XML. > > > > > > > > > > > > > > From the metadata perspective, Stream in XML is pointing > > > > to m-line of > > > > > SDP using label attributes. > > > > [JRE] Yes, I had forgotten that. I recall an earlier > > > > misunderstanding to do with this. I don't think that is > > clear in the > > > > metadata draft, so I will comment separately on that. > > > > However, if this is the common understanding, I can see > > that using > > > > the a=3Dcontent attribute in the RS SDP would be a viable > solution. > > > > > > > > John (as individual) > > > > > > > > > > > > > > > > > SDP points to raw media. XML is used to create > > > association which is > > > > > not possible in SDP. Participant, session to Stream > > > grouping is not > > > > > possible to achieve in SDP which forces us to look for XML > > > > > representation. But in case of content-type scenario, it > > > > is possible > > > > > to make it happen. > > > > > > > > > > Please read inline > > > > > > > > > > Thanks > > > > > Partha > > > > > > > > > > > -----Original Message----- > > > > > > From: Elwell, John > [mailto:john.elwell@siemens-enterprise.com] > > > > > > Sent: Thursday, July 07, 2011 12:36 PM > > > > > > To: Charles Eckel (eckelcu); Ram Mohan R (rmohanr); > > > > Parthasarathi R > > > > > > (partr); Leon Portman; siprec@ietf.org > > > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in > > SDP or XML > > > > > > > > > > > > Charles, > > > > > > > > > > > > I see how it COULD be done in the way you describe. I > > > > just feel it > > > > > > is architecturally wrong to describe the CS MS as part of > > > > the RS MS > > > > > > description (i.e., the RS SDP). > > > > > > > > > > In case the intent is to pass CS MS description, I > > > > agree with > > > > > you. IIRC, charles proposed to use the explicit mixed > > > content-type > > > > > which is more appropriate to be passed in RS SDP to > provide the > > > > > description about that specific media. > > > > > > > > > > > > > > > > > However, I can also give a more specific reason. Suppose CS > > > > > > MS1 is slides and CS MS2 is speaker video. But the XML > > > > does not tell > > > > > > me that CS MS1 is slides and CS MS1 is speaker video. > > > Both CS MS1 > > > > > > and CS MS2 are combined into RS MS1 (slides + speaker). > > > > > > > > > > The question here is how it is possible for > any UA to > > > > > represent > > > > > (slides+speaker) in SDP? In case it is not well defined, > > > > let us work > > > > > for it > > > > > > > > > > The XML metadata tells me that at a given > > > > > > time Participant P1 contributed to CS MS1 and P2 > > > > contributed to CS > > > > > > MS2. How can I tell that P1 contributed to slides and > > > > > > P2 contributed to speaker? > > > > > > > > > > In the mixed stream, we lose the data in SRC > > > > because actual > > > > > media is mixed. The system shall be designed to send the > > > > media stream > > > > > separately or we have to find the generic way to group > > the stream > > > > > together > > > > > > > > > > > > > > > > > See also below: > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > > > > > Sent: 06 July 2011 21:05 > > > > > > > To: Ram Mohan R (rmohanr); Elwell, John; Parthasarathi R > > > > > > (partr); Leon > > > > > > > Portman; siprec@ietf.org > > > > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in > > > SDP or XML > > > > > > > > > > > > > > RFC 4796 has registered the following values: > > > > > > > > > > > > > > slides RFC 4796 > > Presentation slides > > > > > > > speaker RFC 4796 Image from > > > the speaker > > > > > > > sl RFC 4796 Sign language > > > > > > > main RFC 4796 Main > media stream > > > > > > > alt RFC 4796 Alternative > > > > media stream > > > > > > > > > > > > > > Suppose we register the following new values: > > > > > > > > > > > > > > siprec1 RFC xxxx SIPREC value 1 > > > > > > > siprec2 RFC xxxx SIPREC value 2 > > > > > > > siprec3 RFC xxxx SIPREC value 3 > > > > > > > > > > > > > > If the CS has a media lines with the following content > > > > attributes > > > > > > > > > > > > > > CS MS1 - slides > > > > > > > CS MS2 - main > > > > > > > CS MS3 - siprec1 > > > > > > > CS MS4 - siprec2 > > > > > > > > > > > > > > SRC sends two media streams to RS. RS MS1 is essentially > > > > > CS MS1. RS > > > > > > > MS2 is some composition of CS MS2, CS MS3 and CS MS4. > > > > > > > This could be represented using the content attribute as: > > > > > > > > > > > > > > RS MS1 - slides > > > > > > > RS MS2 - main, siprec1, siprec2 > > > > > > > > > > > > > > If this is all we think is required, using the content > > > > > > attribute does > > > > > > > seem sufficient. However, my understanding is people want > > > > > > to be able > > > > > > > to convey something other than the simple concatenation > > > > > of content > > > > > > > attribute values, and for that reason, prefer to use > > > > XML. In this > > > > > > > case, the desired set of values is not bound by > > > > anything we will > > > > > > > define in SIPREC. That is my understanding as to > why XML is > > > > > > preferred > > > > > > > over the RFC > > > > > > > 4796 content attribute. > > > > > > [JRE] That was not my motivation, but perhaps others had > > > > > that in mind. > > > > > > > > > > > > John (as individual) > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > Charles > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Ram Mohan R (rmohanr) > > > > > > > > Sent: Wednesday, July 06, 2011 12:33 AM > > > > > > > > To: Elwell, John; Parthasarathi R (partr); Charles Eckel > > > > > > (eckelcu); > > > > > > > Leon Portman; siprec@ietf.org > > > > > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in > > > > SDP or XML > > > > > > > > > > > > > > > > Just on this one > > > > > > > > > > > > > > > > > RS media stream is a mixed content > type stream > > > > > > > of "current > > > > > > > > > speaker video" and "room video" and the > resultant shall > > > > > > > be named as > > > > > > > > > "mixed current speaker video & room video" > > which shall be > > > > > > > passed as > > > > > > > > > new content type extension to SRS > > > > > > > > [JRE] Right, so you agree this can't be passed in the RS > > > > > > > SDP. I would > > > > > > > challenge the need to define > > > > > > > > (and register) a new RFC 4796 value "mixed current > > > > > speaker video & > > > > > > > room video". We have two MS > > > > > > > > elements (representing the two CS video streams for > > > > > > current speaker > > > > > > > and room. Why can't we just place > > > > > > > > the respective RFC 4796 content types in the respective > > > > > > MS elements? > > > > > > > And why does it need to be as > > > > > > > > extension data - why can't it be standardized > > from day one? > > > > > > > > > > > > > > > > My thought here is since we have new content types > > > > > "mixed current > > > > > > > speaker video & room video" we need > > > > > > > > to register/extend RFC 4796 for the same and send in RS > > > > > > SDP. I would > > > > > > > prefer this approach instead of > > > > > > > > sending it through recording metadata XML. Of course > > > > we need to > > > > > > > discuss this in AVT to get their > > > > > > > > opinion. > > > > > > > > > > > > > > > > Regards, > > > > > > > > Ram > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: siprec-bounces@ietf.org > > > > > > [mailto:siprec-bounces@ietf.org] On > > > > > > > > > Behalf Of Elwell, John > > > > > > > > > Sent: Wednesday, July 06, 2011 12:05 PM > > > > > > > > > To: Parthasarathi R (partr); Charles Eckel (eckelcu); > > > > > > > Leon Portman; > > > > > > > > > siprec@ietf.org > > > > > > > > > Subject: Re: [siprec] Content (RFC 4796) attribute in > > > > > SDP or XML > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Parthasarathi R (partr) > [mailto:partr@cisco.com] > > > > > > > > > > Sent: 05 July 2011 19:06 > > > > > > > > > > To: Charles Eckel (eckelcu); Leon Portman; > > > Elwell, John; > > > > > > > > > > siprec@ietf.org > > > > > > > > > > Subject: RE: [siprec] Content (RFC 4796) > attribute in > > > > > > SDP or XML > > > > > > > > > > > > > > > > > > > > John, > > > > > > > > > > > > > > > > > > > > Please read inline. > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > Partha > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Charles Eckel (eckelcu) > > > > > > > > > > > Sent: Tuesday, July 05, 2011 10:44 PM > > > > > > > > > > > To: Leon Portman; Elwell, John; Parthasarathi R > > > > (partr); > > > > > > > > > > > siprec@ietf.org > > > > > > > > > > > Subject: RE: [siprec] Content (RFC 4796) > > attribute in > > > > > > > SDP or XML > > > > > > > > > > > > > > > > > > > > > > Okay by me. > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > Charles > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: Leon Portman > [mailto:Leon.Portman@nice.com] > > > > > > > > > > > > Sent: Tuesday, July 05, 2011 8:42 AM > > > > > > > > > > > > To: Elwell, John; Parthasarathi R (partr); > > > > Charles Eckel > > > > > > > > > > (eckelcu); > > > > > > > > > > > > siprec@ietf.org > > > > > > > > > > > > Subject: RE: [siprec] Content (RFC 4796) > > > > > > attribute in SDP or > > > > > > > XML > > > > > > > > > > > > > > > > > > > > > > > > I completely agree with the below. > > > > > > > > > > > > > > > > > > > > > > > > Leon > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: Elwell, John > > > > > > > [mailto:john.elwell@siemens-enterprise.com] > > > > > > > > > > > > Sent: Tuesday, July 05, 2011 5:44 PM > > > > > > > > > > > > To: Parthasarathi R (partr); Leon Portman; > > > > Charles Eckel > > > > > > > > > > (eckelcu); > > > > > > > > > > > > siprec@ietf.org > > > > > > > > > > > > Subject: RE: [siprec] Content (RFC 4796) > > > > > > attribute in SDP or > > > > > > > XML > > > > > > > > > > > > > > > > > > > > > > > > (as chair) > > > > > > > > > > > > We should try to avoid opening up old issues. > > > > I think we > > > > > > > > > > > had agreed that: > > > > > > > > > > > > - RS SDP describes the RS, and therefore just > > > > > > describes how > > > > > > > > > > > recordable media is delivered to the SRS. > > > > > > > > > > > > It does not describe how media is delivered > > > between CS > > > > > > > > > > > endpoints as part of the CS. > > > > > > > > > > > > - Therefore anything to do with the CS (i.e., > > > > > the session > > > > > > > being > > > > > > > > > > > > recorded) needs to be delivered to the SRS > > > as metadata > > > > > > > > > > > (i.e., in XML). > > > > > > > > > > > > - We don't see a need to standardize delivery > > > > of things > > > > > > > > > > > like CS codecs > > > > > > > > > > > > in the metadata, but that could be done > using the > > > > > > extension > > > > > > > > > > > mechanism. > > > > > > > > > > > > > > > > > > > > > > Hope everyone agree here that CS SDP > > > > > > > information could be > > > > > > > > > > passed as extension-data. attribute within > > > > > > > > > > > > > > > > > may help to achieve this requirement. > > > > > > > > > [JRE] Or even as the standardized part of an > MS element > > > > > > > if we wish. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Focusing now on the content attribute, I don't > > > > > > > think there is > > > > > > > any > > > > > > > > > > > > disagreement that the SRS needs to know the > > > > content type > > > > > > > (e.g., > > > > > > > > > > > > presentation) of a media stream. The SRC > > can obtain > > > > > > > this from > > > > > > > the > > > > > > > > > > > > a=3Dcontent attribute of the CS SDP. The > > > > > discussion is about > > > > > > > > > > > whether this content attribute should be conveyed > > > > > > to the SRS: > > > > > > > > > > > > A) as an a=3Dcontent attribute of the RS SDP, or > > > > > > > > > > > > B) within the metadata XML. > > > > > > > > > > > > > > > > > > > > > > > > (as individual) > > > > > > > > > > > > According to past decisions, there is perhaps > > > > > an argument > > > > > > > > > > > for B). If, > > > > > > > > > > > > for example, we wanted to convey the fact that > > > > > a CS media > > > > > > > > > > > stream was > > > > > > > > > > > > subject to 256-bit encryption, this > > > > information would go > > > > > > > > > > in the XML > > > > > > > > > > > > > > > > > > > > Here I have the doubt. In case 256-bit > > > > > > > encryption is not > > > > > > > > > used > > > > > > > > > > by RS SDP, Please let me know the reason for > > > > > passing the key > > > > > > > > > > information to SRS because RS SDP is not > > > > encrypted in that > > > > > > > > > > fashion. > > > > > > > > > > > > > > > > [JRE] I did not suggest passing the CS keying > > material to > > > > > > > the SRS. I > > > > > > > > > just suggested passing the information that > the CS media > > > > > > > stream used > > > > > > > > > 256 bit encryption. Perhaps this was a bad example - > > > > > it was just > > > > > > > meant > > > > > > > > > to illustrate the general principle that information > > > > > > about the CS > > > > > > > > > should be passed in metadata XML. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > (it can't go in the RS SDP, because the RS > > > > might not use > > > > > > > > > > > 256-bit encryption. Similarly, one could > > > argue that the > > > > > > > > > > > content type of a CS media stream should go in the > > > > > > XML, not in > > > > > > > > > > > the RS SDP. > > > > > > > > > > I'm seeing content-type attribute as one of > > > > > > > the extension > > > > > > > of > > > > > > > > > > SDP a=3D attribute. In general, it is possible to > > > convert CS > > > > > > > > > mediastream > > > > > > > > > > content type to RS media stream content type > > > > because SRC RS > > > > > > > > > > media stream is formed based on CS media stream > > > > > except for the > > > > > > > mixing scenarios > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I could even imagine cases where the content > > > > > type of a CS > > > > > > > > > > > media stream > > > > > > > > > > > > does not equal the content type of an RS > > > media stream, > > > > > > > > > > > e.g., where the > > > > > > > > > > > > SRC combines the current speaker video and the > > > > > room video > > > > > > > > > > into two > > > > > > > > > > > > videos side-by-side in the same RS media stream. > > > > > > > > > > > > > > > > > > > > RS media stream is a mixed content > > > type stream of > > > > > > > "current > > > > > > > > > > speaker video" and "room video" and the resultant > > > > > > shall be named > > > > > > > as > > > > > > > > > > "mixed current speaker video & room video" which > > > > > > shall be passed > > > > > > > > > > as new content type extension to SRS > > > > > > > > > [JRE] Right, so you agree this can't be passed in the > > > > > RS SDP. I > > > > > > > would > > > > > > > > > challenge the need to define (and register) a new RFC > > > > > 4796 value > > > > > > > "mixed > > > > > > > > > current speaker video & room video". We have two MS > > > > elements > > > > > > > > > (representing the two CS video streams for current > > > > > > > speaker and room. > > > > > > > > > Why can't we just place the respective RFC > 4796 content > > > > > > > types in the > > > > > > > > > respective MS elements? And why does it need to be as > > > > > > > extension data > > > > > > > - > > > > > > > > > why can't it be standardized from day one? > > > > > > > > > > > > > > > > > > John (as individual) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > In the > > > > > > > > > > > metadata these would be two media streams, each > > > > > > with its own > > > > > > > > > > > content type, but both would refer to the same RS > > > > > > > media stream. > > > > > > > > > > > > > > > > > > > > > > It will be problematic approach because the > > > > > > > actual media > > > > > > > and > > > > > > > > > > metadata are not related explicitly. As per > > the current > > > > > > > description, > > > > > > > > > > there are two element with different > > > > > unique-id uses > > > > > > > > > > same label in SDP with different XML element > > > > > ("content-type") > > > > > > > > > > within them. > > > > > > > The > > > > > > > > > > issue is whether media has stream1 behavior > or stream2 > > > > > > > behavior or > > > > > > > > > > mixed. We will able to extent XML element for > > > > having single > > > > > > > > > > interpretation but it is not fully clarified in the > > > > > > > draft now. The > > > > > > > > > > bottom-up matching like stream1 & stream2 has same > > > > > > label element > > > > > > > > > > and it has to be grouped together is not > > > explicit in this > > > > > > > > > > scenario. We > > > > > > > need > > > > > > > > > > more investigation both information is > > required but not > > > > > > > the actual > > > > > > > > > > media. Please correct me in I'm missing something > > > > > > > > > > > > > > > > > > > > > > > > > > John > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > From: Parthasarathi R (partr) > > > > [mailto:partr@cisco.com] > > > > > > > > > > > > > Sent: 04 July 2011 08:08 > > > > > > > > > > > > > To: Leon Portman; Charles Eckel (eckelcu); > > > > > > Elwell, John; > > > > > > > > > > > > > siprec@ietf.org > > > > > > > > > > > > > Subject: RE: [siprec] Content (RFC 4796) > > > > > > > attribute in SDP or > > > > > > > > > XML > > > > > > > > > > > > > > > > > > > > > > > > > > Leon, > > > > > > > > > > > > > > > > > > > > > > > > > > Please read inline. > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > Partha > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > From: Leon Portman > > > [mailto:Leon.Portman@nice.com] > > > > > > > > > > > > > > Sent: Monday, July 04, 2011 12:11 PM > > > > > > > > > > > > > > To: Parthasarathi R (partr); Charles Eckel > > > > > (eckelcu); > > > > > > > Elwell, > > > > > > > > > > > > > > John; siprec@ietf.org > > > > > > > > > > > > > > Subject: RE: [siprec] Content (RFC 4796) > > > > > attribute in > > > > > > > > > > SDP or XML > > > > > > > > > > > > > > > > > > > > > > > > > > > > Partha Hi > > > > > > > > > > > > > > > > > > > > > > > > > > > > Please see below. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Leon > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > From: Parthasarathi R (partr) > > > > > [mailto:partr@cisco.com] > > > > > > > > > > > > > > Sent: Sunday, July 03, 2011 7:50 PM > > > > > > > > > > > > > > To: Leon Portman; Charles Eckel (eckelcu); > > > > > > Elwell, John; > > > > > > > > > > > > > > siprec@ietf.org > > > > > > > > > > > > > > Subject: RE: [siprec] Content (RFC 4796) > > > > > attribute in > > > > > > > > > > SDP or XML > > > > > > > > > > > > > > > > > > > > > > > > > > > > Leon, > > > > > > > > > > > > > > > > > > > > > > > > > > > > Please read inline. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > Partha > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > From: Leon Portman > > > [mailto:Leon.Portman@nice.com] > > > > > > > > > > > > > > Sent: Sunday, July 03, 2011 4:13 PM > > > > > > > > > > > > > > To: Charles Eckel (eckelcu); Elwell, John; > > > > > > > Parthasarathi R > > > > > > > > > > > > > > (partr); siprec@ietf.org > > > > > > > > > > > > > > Subject: RE: [siprec] Content (RFC 4796) > > > > > attribute in > > > > > > > > > > SDP or XML > > > > > > > > > > > > > > > > > > > > > > > > > > > > I do prefer that metadata XML will be as > > > > > > > self-contained as > > > > > > > > > > > > > > possible and not rely on conveying some > > > > data via RS > > > > > > > > > > SDP. RS SDP > > > > > > > > > > > > > > should only be used to recording > > > establishment and > > > > > > > > > > > negotiation and > > > > > > > > > > > > > > not as a mechanism for metadata reporting. > > > > > > > > > > > > > > > > > > > > > > > > > > > > In case Metadata XML has to be > > > > > > self-contained, > > > > > > > the > > > > > > > > > > > > > > complete SDP has to be converted into XML > > > > format or > > > > > > > > > > > else XML has > > > > > > > > > > > > > > to have sort of XML > attribute which > > > > > > > carries SDP. > > > > > > > > > > > > > > Creating mapping for each SDP attribute > > > > > with metadata > > > > > > > > > > > XML element > > > > > > > > > > > > > > does not seems to be feasible > > > > > > > > > > > > > > > > > > > > > > > > > > > > [LeonP] But if CS SDP is different > > from RS SDP, > > > > > > > > > > anyway you will > > > > > > > > > > > > > > need to encapsulate the original RS SDP, so > > > > > why not in > > > > > > > XML? > > > > > > > > > > > > > > > > > > > > > > > > > > I guess that the confusion is > > > here. In the > > > > > > > > > > > current format, > > > > > > > > > > > > > RS SDP is only carried towards SRS and CS > > > SDP is not > > > > > > > forwarded. > > > > > > > > > > > > > This design > > > > > > > > > > > > > is closed as part of ticket #71 > > > > > > > > > > > > > > > > > > > > > > > > (http://www.ietf.org/mail- > > > > > > > > > archive/web/siprec/current/msg02106.html). > > > > > > > > > > > > > Please bring up with the usecase for CS SDP > > > > > if required > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Otherwise we will not be able to reuse same > > > > > format for > > > > > > > > > > > reporting > > > > > > > > > > > > > > metadata via web services As per > > > > > IETF-80 and > > > > > > > > > > > last interim > > > > > > > > > > > > > > meeting, there is no intent of reusing > > > > this metadata > > > > > > > > > > > XML in other > > > > > > > > > > > > > > protocol. In case reusing same format for > > > > webservice > > > > > > > > > > or XMPP is > > > > > > > > > > > > > > the intent, the current metadata XML > > > > > mechanism is not > > > > > > > > > > > the appropriate. > > > > > > > > > > > > > > This was discussed in > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > http://www.ietf.org/mail-archive/web/siprec/current/msg02151.html, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > http://www.ietf.org/mail- > > > > > > > > > archive/web/siprec/current/msg02155.html(1s > > > > > > > > > > > > > t > > > > > > > > > > > > > > point in format slide). In case you have > > > > difference > > > > > > > > > > of opinion > > > > > > > > > > > > > > even after this multiple discussion, > > > let us again > > > > > > > > > > > discuss at IETF-81. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [LeonP] I was not proposing replacing SIP > > > > > with another > > > > > > > > > > > transport > > > > > > > > > > > > > > layer, just wanted to keep other > options open. > > > > > > > > > > > > > > > > > > > > > > > > > > Current metadata format is > > > > customized for SIP > > > > > > > > > > > transport. In > > > > > > > > > > > > > case we need to keep the options open, > > the format > > > > > > > has to be > > > > > > > > > > > > > revisited from the scratch. In our > > > > analysis, we notice > > > > > > > > > > that REST > > > > > > > > > > > > > architecture with Metadata XML is best fit for > > > > > > HTTP, XMPP > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I am > > > > > > > > > > > > > > very big supporter for metadata over > > > SIP reporting > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, Me too.. > > > > > > > > > > > > > > > > > > > > > > > > > > > or as dedicated SIP session. > > > > > > > > > > > > > > In case Metadata is > separate session > > > > > > > from RS, RS > > > > > > > > > > > > > > attribute like RS-id MUST be included within > > > > > > > XML. This was > > > > > > > > > > > > > > discussed at > > > > > > > > > > > > > > http://www.ietf.org/mail- > > > > > > > > > archive/web/siprec/current/msg02013.h > > > > > > > > > > > > > tml. Could you please explain reason for > > > > the dedicated > > > > > > > > > > > SIP > session > > > > > > > > > > > > > for metadata. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [LeonP] The main use case is Recording on > > > > > > > Demand, that is > > > > > > > > > > > > > > triggered by SRS. In such case it will be > > > > > very useful > > > > > > > > > > > to have just > > > > > > > > > > > > > > one SIP session and send all > metadata over it > > > > > > (like CTI > > > > > > > > > > > > > > link) and then only trigger recording (via > > > > > > external SRC > > > > > > > > > > > > > > interface) only for specific call segments. > > > > > > > > > > > > > > > > > > > > > > > > > > > I understand the current > > > > > implementation wherein > > > > > > > > > > > few of the > > > > > > > > > > > > > metadata like CDR records is passed > > > through non-sip > > > > > > > > > > > interface. It is > > > > > > > > > > > > > outside the scope of SIPREC. The > > > global-id in format > > > > > > > > > > > shall be used > > > > > > > > > > > > > to correlate. Please let me know in case > > > any current > > > > > > > > > > > SIPREC metadata > > > > > > > > > > > > > attribute MUST be passed through this > CTS link. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > As for examples, the basic information as > > > > > media type, > > > > > > > labels, > > > > > > > > > > > > > > volume etc. Any application level > data can be > > > > > > relevant. > > > > > > > Even > > > > > > > > > > > > > > indication of encryption (for a case > > > > where RS is not > > > > > > > > > > encrypted) > > > > > > > > > > > > > > > > > > > > > > > > > > > > Leon > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > From: siprec-bounces@ietf.org > > > > > > > > > > > > > > [mailto:siprec-bounces@ietf.org] On Behalf > > > > > Of Charles > > > > > > > Eckel > > > > > > > > > > > > > (eckelcu) > > > > > > > > > > > > > > Sent: Wednesday, June 29, 2011 7:17 PM > > > > > > > > > > > > > > To: Elwell, John; Parthasarathi R (partr); > > > > > > > siprec@ietf.org > > > > > > > > > > > > > > Subject: Re: [siprec] Content (RFC 4796) > > > > > attribute in > > > > > > > > > > SDP or XML > > > > > > > > > > > > > > > > > > > > > > > > > > > > I think it is sufficient, > especially since we > > > > > > can assign > > > > > > > new > > > > > > > > > > > > > > values if necessary. > > > > > > > > > > > > > > Are there any examples of what people > > think they > > > > > > > > > > might want to > > > > > > > > > > > > > > capture in the SDP and/or metadata field? > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > Charles > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > > From: siprec-bounces@ietf.org > > > > > > > > > > > [mailto:siprec-bounces@ietf.org] > > > > > > > > > > > > > > > On > > > > > > > > > > > > > > Behalf Of Elwell, John > > > > > > > > > > > > > > > Sent: Tuesday, June 28, 2011 3:11 AM > > > > > > > > > > > > > > > To: Parthasarathi R (partr); > siprec@ietf.org > > > > > > > > > > > > > > > Subject: Re: [siprec] Content (RFC 4796) > > > > > > attribute in > > > > > > > > > > > SDP or XML > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I would like other opinions on whether the > > > > > > > SDP a=3Dcontent > > > > > > > > > > > > > > attribute in > > > > > > > > > > > > > > the RS SDP has the correct > > > > > > > > > > > > > > > semantics for representing the content > > > > type of the > > > > > > > > > > > > > recorded CS media > > > > > > > > > > > > > > stream. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > John > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > > > From: Parthasarathi R (partr) > > > > > > > [mailto:partr@cisco.com] > > > > > > > > > > > > > > > > Sent: 28 June 2011 10:45 > > > > > > > > > > > > > > > > To: Elwell, John; siprec@ietf.org > > > > > > > > > > > > > > > > Cc: Ram Mohan R (rmohanr); Paul Kyzivat > > > > > (pkyzivat) > > > > > > > > > > > > > > > > Subject: RE: Content (RFC 4796) > attribute > > > > > > in SDP or > > > > > > > XML > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > John, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > In case if it is the argument of > > whether CS > > > > > > > MS content > > > > > > > > > > > > > > type or RS MS > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > content type in the metadata, it is > > > > > > better for us to > > > > > > > > > > > > > > re-open ticket > > > > > > > > > > > > > > > > #71 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > (http://www.ietf.org/mail- > > > > > > > > > archive/web/siprec/current/msg02106.html). > > > > > > > > > > > > > > > > Please let me know your opinion here. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The basic idea in metadata format is to > > > > > re-use as > > > > > > > > > > > much as SDP > > > > > > > > > > > > > > > > attribute (like direction, content) in > > > > > > > media level for > > > > > > > > > > > > > RS dialog > > > > > > > > > > > > > > > > (using SDP label attribute as a > > > pointer) until > > > > > > > otherwise > > > > > > > > > > > > > > there is a > > > > > > > > > > > > > > > > restriction in using in such > > manner. As per > > > > > > > RFC 4796, > > > > > > > > > > > > > there is no > > > > > > > > > > > > > > > > such restriction and so, I > prefer to reuse > > > > > > > as content > > > > > > > SDP > > > > > > > > > > > > > > attribute > > > > > > > > > > > > > > > > rather than introducing the new > > > > > > > > > > > > > element for > > > > > > > > > > > > > > > > this purpose. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > Partha > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > > > From: Elwell, John > > > > > > > > > > > [mailto:john.elwell@siemens-enterprise.com] > > > > > > > > > > > > > > > > Sent: Monday, June 27, 2011 1:18 PM > > > > > > > > > > > > > > > > To: Parthasarathi R (partr); > > siprec@ietf.org > > > > > > > > > > > > > > > > Cc: Ram Mohan R (rmohanr); Paul Kyzivat > > > > > (pkyzivat) > > > > > > > > > > > > > > > > Subject: RE: Content (RFC 4796) > attribute > > > > > > in SDP or > > > > > > > XML > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > > > > From: Parthasarathi R (partr) > > > > > > > [mailto:partr@cisco.com] > > > > > > > > > > > > > > > > > Sent: 27 June 2011 08:08 > > > > > > > > > > > > > > > > > To: siprec@ietf.org; Elwell, John > > > > > > > > > > > > > > > > > Cc: Ram Mohan R (rmohanr); > Paul Kyzivat > > > > > > (pkyzivat) > > > > > > > > > > > > > > > > > Subject: Content (RFC 4796) > attribute in > > > > > > > SDP or XML > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > As per the last interim > SIPREC meeting, > > > > > > there is a > > > > > > > > > > > > > consensus to > > > > > > > > > > > > > > > > > describe the content of an MS > using RFC > > > > > > 4796 & its > > > > > > > > > > > > > > > > extension. As per > > > > > > > > > > > > > > > > > RFC 4796, the multiple instance of > > > > > > > content attribute > > > > > > > > > > > > > is possible > > > > > > > > > > > > > > to > > > > > > > > > > > > > > > > > exist in SDP which shall be used in > > > > > RS SDP. SRS > > > > > > > > > > > shall group > > > > > > > > > > > > > > > > the same > > > > > > > > > > > > > > > > > media content types by "content" > > > > > attribute in RS > > > > > > > > > > > SDP. We are > > > > > > > > > > > > > > > > > interested in knowing any specfic > > > > > > reason for this > > > > > > > > > > > > > > attribute to be > > > > > > > > > > > > > > > > > duplicated in Metadata XML. > > > > > > > > > > > > > > > > [JRE] I don't have a reason for > > > > **duplication**. > > > > > > > > > > > > > However, I think > > > > > > > > > > > > > > > > there is a valid question to be asked > > > > > whether the > > > > > > > content > > > > > > > > > > > > > > type of an > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > MS should be represented: > > > > > > > > > > > > > > > > A) in XML; or > > > > > > > > > > > > > > > > B) in RS SDP as a=3Dcontent. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The content type we are talking > > about is an > > > > > > > MS content > > > > > > > > > > > > > > type, i.e., > > > > > > > > > > > > > > > > relating to the CS. One could > > argue that the > > > > > > > > > > > > > > corresponding RS stream > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > is NOT the same content type. > For example: > > > > > > > > > > > > > > > > - CS MS content type is "slides". > > > > > > > > > > > > > > > > - RS media stream content type is > > > > "recording of > > > > > > > slides". > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On this basis, I think the correct > > > option for > > > > > > > > > > > conveying the MS > > > > > > > > > > > > > > content > > > > > > > > > > > > > > > > type "slides" is A) (in the XML). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Note that this would not involve > > > > > > > duplication. The SDP > > > > > > > > > > > > > > > > a=3Dcontent attribute is optional, so we > > > > > > need not use > > > > > > > > > > > it for the RS. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Perhaps my distinction is too > > > > > > theoretical, but I do > > > > > > > > > > > > > feel a little > > > > > > > > > > > > > > more > > > > > > > > > > > > > > > > comfortable using the XML rather than > > > > > the RS SDP. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > John (as individual) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Partha > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > last Interim SIPREC meeting Note: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Slide 7: On the question of how to > > > > > describe the > > > > > > > content > > > > > > > > > > > > > > of an MS, > > > > > > > > > > > > > > > > > there was no objection to basing this > > > > > > on the types > > > > > > > in > > > > > > > > > > > > > > the RFC 4796 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > registry (new values could be > > > > > specified via the > > > > > > > > > > > appropriate > > > > > > > > > > > > > > > > means if > > > > > > > > > > > > > > > > > needed). Paul had a slight > concern that > > > > > > you might > > > > > > > > > > > be mixing > > > > > > > > > > > > > > > > multiple > > > > > > > > > > > > > > > > > CS MSs into a single RS media stream > > > > > and whether > > > > > > > > > > > this might > > > > > > > > > > > > > > > > result in > > > > > > > > > > > > > > > > > cases not describable in this way, but > > > > > > in the end > > > > > > > > > > > > > accepted the > > > > > > > > > > > > > > > > > consensus. It needs to be discussed > > > > > on the list > > > > > > > > > > > > > whether this is > > > > > > > > > > > > > > > > > conveyed in XML or in the RS > > SDP a=3Dcontent > > > > > > > attribute. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > > siprec mailing list siprec@ietf.org > > > > > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > siprec mailing 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 Jul 7 10:07: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 157E311E80C3 for ; Thu, 7 Jul 2011 10:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.359 X-Spam-Level: X-Spam-Status: No, score=-6.359 tagged_above=-999 required=5 tests=[AWL=-3.760, 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 OgnF4YO6ubKS for ; Thu, 7 Jul 2011 10:07:47 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 37AF211E80C2 for ; Thu, 7 Jul 2011 10:07:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=2650; q=dns/txt; s=iport; t=1310058467; x=1311268067; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=yrMInNOu3Ba3WRfcdYTXu2IbpF+hsQh8P1auBP8tGMY=; b=UXEkE5D+m5XCfjngDWd62rR4tK7ZUp4ko4FfVPrq9pdSqCm2HbZK1UGG i17CueVBMRkAlMX9AUQNGtKJIgeha7wIHFbQNM8ogEW7sAEaK33X7rdQm p2d5ynI3cmIijf8mubQfGh4t8gIvjlsduUO8Rb6o/JjczvEkmmG++KcLQ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIBANrmFU6rRDoH/2dsb2JhbABTEJdujzZ3iHukZp17hjgEh0mQA4sEVw X-IronPort-AV: E=Sophos;i="4.65,494,1304294400"; d="scan'208";a="737126" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-4.cisco.com with ESMTP; 07 Jul 2011 17:07:46 +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 p67H7kRi013821; Thu, 7 Jul 2011 17:07:46 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Jul 2011 10:07:45 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Jul 2011 10:07:44 -0700 Message-ID: In-Reply-To: <4E14D321.1030902@alum.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [siprec] Content (RFC 4796) attribute in SDP or XML thread-index: Acw8I5zwJ1faO4WXTUagzcZJAG6CYwApI7Kg References: <07465C1D981ABC41A344374066AE1A2C38AF6D40CC@TLVMBX01.nice.com><07465C1D981ABC41A344374066AE1A2C38AF6D4376@TLVMBX01.nice.com><07465C1D981ABC41A344374066AE1A2C38AFE9B1C0@TLVMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD06E358D2@XMB-BGL-417.cisco.com> <4E14D3 21.1030902@alum.mit.edu> From: "Charles Eckel (eckelcu)" To: "Paul Kyzivat" , X-OriginalArrivalTime: 07 Jul 2011 17:07:45.0860 (UTC) FILETIME=[642B8040:01CC3CC8] Subject: Re: [siprec] Content (RFC 4796) attribute in SDP or XML X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 17:07:48 -0000 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Wednesday, July 06, 2011 2:27 PM > To: siprec@ietf.org > Subject: Re: [siprec] Content (RFC 4796) attribute in SDP or XML >=20 > On 7/6/11 4:05 PM, Charles Eckel (eckelcu) wrote: > > RFC 4796 has registered the following values: > > > > slides RFC 4796 Presentation slides > > speaker RFC 4796 Image from the speaker > > sl RFC 4796 Sign language > > main RFC 4796 Main media stream > > alt RFC 4796 Alternative media stream > > > > Suppose we register the following new values: > > > > siprec1 RFC xxxx SIPREC value 1 > > siprec2 RFC xxxx SIPREC value 2 > > siprec3 RFC xxxx SIPREC value 3 >=20 > I don't get it. What is the purpose of siprecN? I don't have any purpose to assign or propose at this time. My understanding from previous thread is that others felt the existing set of values defined for the content attribute might not be sufficient. I was merely illustrating that we could define new values, if necessary. Cheers, Charles >=20 > I can perhaps see using a new value to indicate: this stream contains > some content from a stream that failed to indicate what sort of content > it contained. But you only need one value for that. >=20 > Thanks, > Paul >=20 > > If the CS has a media lines with the following content attributes > > > > CS MS1 - slides > > CS MS2 - main > > CS MS3 - siprec1 > > CS MS4 - siprec2 > > > > SRC sends two media streams to RS. RS MS1 is essentially CS MS1. RS MS2 > > is some composition of CS MS2, CS MS3 and CS MS4. > > This could be represented using the content attribute as: > > > > RS MS1 - slides > > RS MS2 - main, siprec1, siprec2 > > > > If this is all we think is required, using the content attribute does > > seem sufficient. However, my understanding is people want to be able to > > convey something other than the simple concatenation of content > > attribute values, and for that reason, prefer to use XML. In this case, > > the desired set of values is not bound by anything we will define in > > SIPREC. That is my understanding as to why XML is preferred over the RFC > > 4796 content attribute. > > > > Cheers, > > Charles > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From eckelcu@cisco.com Thu Jul 7 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 D076E11E809B for ; Thu, 7 Jul 2011 10:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.432 X-Spam-Level: X-Spam-Status: No, score=-5.432 tagged_above=-999 required=5 tests=[AWL=-3.433, 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 KslGhlV3U3cv for ; Thu, 7 Jul 2011 10:19:35 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6A73311E8080 for ; Thu, 7 Jul 2011 10:19:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=29366; q=dns/txt; s=iport; t=1310059174; x=1311268774; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=pthOoXhCw0Pn2+ruP1sPa9CmKYNQn90D6kyyjZDO5ew=; b=FyKcPniHZCnnslUPKxiQufZea8noCalbEa4hhQrJsimSqhTfl6Y096Bd jFh2iCPdL7ii3yG3eQjREftgy1+awGQSXoQ/9fe1p8FNf2kZT9pzpeEjE f/+c9bTqV5oajPQtZNYjt+4ApPkMK0u6Yhw2NddIPfcF/+BdU52QP68Bs 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIBAIfpFU6rRDoJ/2dsb2JhbABTl36PNneIe6RrnXeGOASHSZADi1s X-IronPort-AV: E=Sophos;i="4.65,494,1304294400"; d="scan'208";a="743413" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-1.cisco.com with ESMTP; 07 Jul 2011 17:19:33 +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 p67HJX0q019983; Thu, 7 Jul 2011 17:19:33 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Jul 2011 10:19: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: Thu, 7 Jul 2011 10:19:31 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [siprec] Content (RFC 4796) attribute in SDP or XML thread-index: Acw0mPHhxfeVJEDcQLSYWo3IAZGl7wABDbXgACpfOfAADTnVAAA/CH7wAL12yxAADByJIAAdm3FgAADcErAAQaGFkAAC7JoQAAMpvCAAAObikAAasOngAAJiC3AAGcWykAAW4scQABXhNTA= References: <07465C1D981ABC41A344374066AE1A2C38AF6D40CC@TLVMBX01.nice.com><07465C1D981ABC41A344374066AE1A2C38AF6D4376@TLVMBX01.nice.com><07465C1D981ABC41A344374066AE1A2C38AFE9B1C0@TLVMBX01.nice.com> <35BCE99A477D6A4986FB2216D8CF2CFD06E358D2@XMB-BGL-417.cisco.com> From: "Charles Eckel (eckelcu)" To: "Elwell, John" , "Ram Mohan R (rmohanr)" , "Parthasarathi R (partr)" , "Leon Portman" , X-OriginalArrivalTime: 07 Jul 2011 17:19:32.0954 (UTC) FILETIME=[09A17BA0:01CC3CCA] Subject: Re: [siprec] Content (RFC 4796) attribute in SDP or XML X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 17:19:36 -0000 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Thursday, July 07, 2011 12:06 AM > To: Charles Eckel (eckelcu); Ram Mohan R (rmohanr); Parthasarathi R (partr); Leon Portman; > siprec@ietf.org > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML >=20 > Charles, >=20 > I see how it COULD be done in the way you describe. I just feel it is architecturally wrong to > describe the CS MS as part of the RS MS description (i.e., the RS SDP). >=20 > However, I can also give a more specific reason. Suppose CS MS1 is slides and CS MS2 is speaker video. > But the XML does not tell me that CS MS1 is slides and CS MS1 is speaker video. Both CS MS1 and CS MS2 > are combined into RS MS1 (slides + speaker). The XML metadata tells me that at a given time > Participant P1 contributed to CS MS1 and P2 contributed to CS MS2. How can I tell that P1 contributed > to slides and P2 contributed to speaker? I agree, the RFC 4976 content attribute is not well suited for this. My point is, I think we need to clearly define what we mean when we say we want a content attribute in XML. If the XML content attribute is meant to convey. Within the SDP we have the content attribute. Within RTP/RTCP we have SSRC and CSRC. These can be used to describe the content and the contributors. If we want to be able to attribute specific content, or pieces or content within a composed/mixed stream to individual participants, I agree that something more is needed. We could define new SDP and/or RTP/RTCP functionality, or simply add more XML to the metadata. I prefer the latter in this case. In summary, I am not arguing that the RFC 4796 content attribute mechanism is sufficient or well suited to convey a rich description of an arbitrary media stream. I am saying merely stating the level of information for which it is well suited, and proposing that if that level of information is all we need to convey, we use the SDP content attribute rather than duplicating the same information in XML. Cheers, Charles =20 >=20 > See also below: >=20 > > -----Original Message----- > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > Sent: 06 July 2011 21:05 > > To: Ram Mohan R (rmohanr); Elwell, John; Parthasarathi R > > (partr); Leon Portman; siprec@ietf.org > > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML > > > > RFC 4796 has registered the following values: > > > > slides RFC 4796 Presentation slides > > speaker RFC 4796 Image from the speaker > > sl RFC 4796 Sign language > > main RFC 4796 Main media stream > > alt RFC 4796 Alternative media stream > > > > Suppose we register the following new values: > > > > siprec1 RFC xxxx SIPREC value 1 > > siprec2 RFC xxxx SIPREC value 2 > > siprec3 RFC xxxx SIPREC value 3 > > > > If the CS has a media lines with the following content attributes > > > > CS MS1 - slides > > CS MS2 - main > > CS MS3 - siprec1 > > CS MS4 - siprec2 > > > > SRC sends two media streams to RS. RS MS1 is essentially CS > > MS1. RS MS2 > > is some composition of CS MS2, CS MS3 and CS MS4. > > This could be represented using the content attribute as: > > > > RS MS1 - slides > > RS MS2 - main, siprec1, siprec2 > > > > If this is all we think is required, using the content attribute does > > seem sufficient. However, my understanding is people want to > > be able to > > convey something other than the simple concatenation of content > > attribute values, and for that reason, prefer to use XML. In > > this case, > > the desired set of values is not bound by anything we will define in > > SIPREC. That is my understanding as to why XML is preferred > > over the RFC > > 4796 content attribute. > [JRE] That was not my motivation, but perhaps others had that in mind. >=20 > John (as individual) >=20 > > > > Cheers, > > Charles > > > > > > > -----Original Message----- > > > From: Ram Mohan R (rmohanr) > > > Sent: Wednesday, July 06, 2011 12:33 AM > > > To: Elwell, John; Parthasarathi R (partr); Charles Eckel (eckelcu); > > Leon Portman; siprec@ietf.org > > > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML > > > > > > Just on this one > > > > > > > RS media stream is a mixed content type stream > > of "current > > > > speaker video" and "room video" and the resultant shall > > be named as > > > > "mixed current speaker video & room video" which shall be > > passed as > > > > new content type extension to SRS > > > [JRE] Right, so you agree this can't be passed in the RS > > SDP. I would > > challenge the need to define > > > (and register) a new RFC 4796 value "mixed current speaker video & > > room video". We have two MS > > > elements (representing the two CS video streams for current speaker > > and room. Why can't we just place > > > the respective RFC 4796 content types in the respective MS elements? > > And why does it need to be as > > > extension data - why can't it be standardized from day one? > > > > > > My thought here is since we have new content types "mixed current > > speaker video & room video" we need > > > to register/extend RFC 4796 for the same and send in RS SDP. I would > > prefer this approach instead of > > > sending it through recording metadata XML. Of course we need to > > discuss this in AVT to get their > > > opinion. > > > > > > Regards, > > > Ram > > > > > > > -----Original Message----- > > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > > > Behalf Of Elwell, John > > > > Sent: Wednesday, July 06, 2011 12:05 PM > > > > To: Parthasarathi R (partr); Charles Eckel (eckelcu); > > Leon Portman; > > > > siprec@ietf.org > > > > Subject: Re: [siprec] Content (RFC 4796) attribute in SDP or XML > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > > Sent: 05 July 2011 19:06 > > > > > To: Charles Eckel (eckelcu); Leon Portman; Elwell, John; > > > > > siprec@ietf.org > > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or XML > > > > > > > > > > John, > > > > > > > > > > Please read inline. > > > > > > > > > > Thanks > > > > > Partha > > > > > > > > > > > -----Original Message----- > > > > > > From: Charles Eckel (eckelcu) > > > > > > Sent: Tuesday, July 05, 2011 10:44 PM > > > > > > To: Leon Portman; Elwell, John; Parthasarathi R (partr); > > > > > > siprec@ietf.org > > > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in > > SDP or XML > > > > > > > > > > > > Okay by me. > > > > > > > > > > > > Cheers, > > > > > > Charles > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > > > > > > Sent: Tuesday, July 05, 2011 8:42 AM > > > > > > > To: Elwell, John; Parthasarathi R (partr); Charles Eckel > > > > > (eckelcu); > > > > > > > siprec@ietf.org > > > > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or > > XML > > > > > > > > > > > > > > I completely agree with the below. > > > > > > > > > > > > > > Leon > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Elwell, John > > [mailto:john.elwell@siemens-enterprise.com] > > > > > > > Sent: Tuesday, July 05, 2011 5:44 PM > > > > > > > To: Parthasarathi R (partr); Leon Portman; Charles Eckel > > > > > (eckelcu); > > > > > > > siprec@ietf.org > > > > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in SDP or > > XML > > > > > > > > > > > > > > (as chair) > > > > > > > We should try to avoid opening up old issues. I think we > > > > > > had agreed that: > > > > > > > - RS SDP describes the RS, and therefore just describes how > > > > > > recordable media is delivered to the SRS. > > > > > > > It does not describe how media is delivered between CS > > > > > > endpoints as part of the CS. > > > > > > > - Therefore anything to do with the CS (i.e., the session > > being > > > > > > > recorded) needs to be delivered to the SRS as metadata > > > > > > (i.e., in XML). > > > > > > > - We don't see a need to standardize delivery of things > > > > > > like CS codecs > > > > > > > in the metadata, but that could be done using the extension > > > > > > mechanism. > > > > > > > > > > > > Hope everyone agree here that CS SDP > > information could be > > > > > passed as extension-data. attribute within > > > > > > > may help to achieve this requirement. > > > > [JRE] Or even as the standardized part of an MS element > > if we wish. > > > > > > > > > > > > > > > > Focusing now on the content attribute, I don't > > think there is > > any > > > > > > > disagreement that the SRS needs to know the content type > > (e.g., > > > > > > > presentation) of a media stream. The SRC can obtain > > this from > > the > > > > > > > a=3Dcontent attribute of the CS SDP. The discussion is = about > > > > > > whether this content attribute should be conveyed to the SRS: > > > > > > > A) as an a=3Dcontent attribute of the RS SDP, or > > > > > > > B) within the metadata XML. > > > > > > > > > > > > > > (as individual) > > > > > > > According to past decisions, there is perhaps an argument > > > > > > for B). If, > > > > > > > for example, we wanted to convey the fact that a CS media > > > > > > stream was > > > > > > > subject to 256-bit encryption, this information would go > > > > > in the XML > > > > > > > > > > Here I have the doubt. In case 256-bit > > encryption is not > > > > used > > > > > by RS SDP, Please let me know the reason for passing the key > > > > > information > > > > > to SRS because RS SDP is not encrypted in that fashion. > > > > > > [JRE] I did not suggest passing the CS keying material to > > the SRS. I > > > > just suggested passing the information that the CS media > > stream used > > > > 256 bit encryption. Perhaps this was a bad example - it was just > > meant > > > > to illustrate the general principle that information about the CS > > > > should be passed in metadata XML. > > > > > > > > > > > > > > > > (it can't go in the RS SDP, because the RS might not use > > > > > > 256-bit encryption. Similarly, one could argue that the > > > > > > content type of a CS media stream should go in the XML, not > > > > > > in the RS SDP. > > > > > I'm seeing content-type attribute as one of > > the extension > > of > > > > > SDP a=3D attribute. In general, it is possible to convert CS > > > > mediastream > > > > > content type to RS media stream content type because SRC RS > > > > > media stream > > > > > is formed based on CS media stream except for the > > mixing scenarios > > > > > > > > > > > > > > > > > > > > > > > > I could even imagine cases where the content type of a CS > > > > > > media stream > > > > > > > does not equal the content type of an RS media stream, > > > > > > e.g., where the > > > > > > > SRC combines the current speaker video and the room video > > > > > into two > > > > > > > videos side-by-side in the same RS media stream. > > > > > > > > > > RS media stream is a mixed content type stream of > > "current > > > > > speaker video" and "room video" and the resultant shall be named > > as > > > > > "mixed current speaker video & room video" which shall be > > > > > passed as new > > > > > content type extension to SRS > > > > [JRE] Right, so you agree this can't be passed in the RS SDP. I > > would > > > > challenge the need to define (and register) a new RFC 4796 value > > "mixed > > > > current speaker video & room video". We have two MS elements > > > > (representing the two CS video streams for current > > speaker and room. > > > > Why can't we just place the respective RFC 4796 content > > types in the > > > > respective MS elements? And why does it need to be as > > extension data > > - > > > > why can't it be standardized from day one? > > > > > > > > John (as individual) > > > > > > > > > > > > > > In the > > > > > > metadata these would be two media streams, each with its own > > > > > > content type, but both would refer to the same RS > > media stream. > > > > > > > > > > > > It will be problematic approach because the > > actual media > > and > > > > > metadata are not related explicitly. As per the current > > description, > > > > > there are two element with different unique-id uses > > > > > same label > > > > > in SDP with different XML element ("content-type") within them. > > The > > > > > issue is whether media has stream1 behavior or stream2 > > behavior or > > > > > mixed. We will able to extent XML element for having single > > > > > interpretation but it is not fully clarified in the > > draft now. The > > > > > bottom-up matching like stream1 & stream2 has same label > > > > > element and it > > > > > has to be grouped together is not explicit in this scenario. We > > need > > > > > more investigation both information is required but not > > the actual > > > > > media. Please correct me in I'm missing something > > > > > > > > > > > > John > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > > > > > Sent: 04 July 2011 08:08 > > > > > > > > To: Leon Portman; Charles Eckel (eckelcu); Elwell, John; > > > > > > > > siprec@ietf.org > > > > > > > > Subject: RE: [siprec] Content (RFC 4796) > > attribute in SDP or > > > > XML > > > > > > > > > > > > > > > > Leon, > > > > > > > > > > > > > > > > Please read inline. > > > > > > > > > > > > > > > > Thanks > > > > > > > > Partha > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > > > > > > > > Sent: Monday, July 04, 2011 12:11 PM > > > > > > > > > To: Parthasarathi R (partr); Charles Eckel (eckelcu); > > Elwell, > > > > > > > > > John; siprec@ietf.org > > > > > > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in > > > > > SDP or XML > > > > > > > > > > > > > > > > > > Partha Hi > > > > > > > > > > > > > > > > > > Please see below. > > > > > > > > > > > > > > > > > > Leon > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > > > > > > > > Sent: Sunday, July 03, 2011 7:50 PM > > > > > > > > > To: Leon Portman; Charles Eckel (eckelcu); Elwell, John; > > > > > > > > > siprec@ietf.org > > > > > > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in > > > > > SDP or XML > > > > > > > > > > > > > > > > > > Leon, > > > > > > > > > > > > > > > > > > Please read inline. > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > Partha > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > > > > > > > > Sent: Sunday, July 03, 2011 4:13 PM > > > > > > > > > To: Charles Eckel (eckelcu); Elwell, John; > > Parthasarathi R > > > > > > > > > (partr); siprec@ietf.org > > > > > > > > > Subject: RE: [siprec] Content (RFC 4796) attribute in > > > > > SDP or XML > > > > > > > > > > > > > > > > > > I do prefer that metadata XML will be as > > self-contained as > > > > > > > > > possible and not rely on conveying some data via RS > > > > > SDP. RS SDP > > > > > > > > > should only be used to recording establishment and > > > > > > negotiation and > > > > > > > > > not as a mechanism for metadata reporting. > > > > > > > > > > > > > > > > > > In case Metadata XML has to be self-contained, > > the > > > > > > > > > complete SDP has to be converted into XML format or > > > > > > else XML has > > > > > > > > > to have sort of XML attribute which > > carries SDP. > > > > > > > > > Creating mapping for each SDP attribute with metadata > > > > > > XML element > > > > > > > > > does not seems to be feasible > > > > > > > > > > > > > > > > > > [LeonP] But if CS SDP is different from RS SDP, > > > > > anyway you will > > > > > > > > > need to encapsulate the original RS SDP, so why not in > > XML? > > > > > > > > > > > > > > > > I guess that the confusion is here. In the > > > > > > current format, > > > > > > > > RS SDP is only carried towards SRS and CS SDP is not > > forwarded. > > > > > > > > This design > > > > > > > > is closed as part of ticket #71 > > > > > > > > > > > > > > (http://www.ietf.org/mail- > > > > archive/web/siprec/current/msg02106.html). > > > > > > > > Please bring up with the usecase for CS SDP if required > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Otherwise we will not be able to reuse same format for > > > > > > reporting > > > > > > > > > metadata via web services As per IETF-80 and > > > > > > last interim > > > > > > > > > meeting, there is no intent of reusing this metadata > > > > > > XML in other > > > > > > > > > protocol. In case reusing same format for webservice > > > > > or XMPP is > > > > > > > > > the intent, the current metadata XML mechanism is not > > > > > > the appropriate. > > > > > > > > > This was discussed in > > > > > > > > > > > > > > > > > http://www.ietf.org/mail-archive/web/siprec/current/msg02151.html, > > > > > > > > > > > > > > > > > > > > > > > http://www.ietf.org/mail- > > > > archive/web/siprec/current/msg02155.html(1s > > > > > > > > t > > > > > > > > > point in format slide). In case you have difference > > > > > of opinion > > > > > > > > > even after this multiple discussion, let us again > > > > > > discuss at IETF-81. > > > > > > > > > > > > > > > > > > > > > > > > > > > [LeonP] I was not proposing replacing SIP with another > > > > > > transport > > > > > > > > > layer, just wanted to keep other options open. > > > > > > > > > > > > > > > > Current metadata format is customized for SIP > > > > > > transport. In > > > > > > > > case we need to keep the options open, the format > > has to be > > > > > > > > revisited from the scratch. In our analysis, we notice > > > > > that REST > > > > > > > > architecture with Metadata XML is best fit for HTTP, XMPP > > > > > > > > > > > > > > > > > > > > > > I am > > > > > > > > > very big supporter for metadata over SIP reporting > > > > > > > > > > > > > > > > > Thanks, Me too.. > > > > > > > > > > > > > > > > > or as dedicated SIP session. > > > > > > > > > In case Metadata is separate session > > from RS, RS > > > > > > > > > attribute like RS-id MUST be included within > > XML. This was > > > > > > > > > discussed at > > > > > > > > > http://www.ietf.org/mail- > > > > archive/web/siprec/current/msg02013.h > > > > > > > > tml. Could you please explain reason for the dedicated > > > > > > SIP > session > > > > > > > > for metadata. > > > > > > > > > > > > > > > > > > > > > > > > > > > [LeonP] The main use case is Recording on > > Demand, that is > > > > > > > > > triggered by SRS. In such case it will be very useful > > > > > > to have just > > > > > > > > > one SIP session and send all metadata over it (like CTI > > > > > > > > > link) and then only trigger recording (via external SRC > > > > > > > > > interface) only for specific call segments. > > > > > > > > > > > > > > > > > I understand the current implementation wherein > > > > > > few of the > > > > > > > > metadata like CDR records is passed through non-sip > > > > > > interface. It is > > > > > > > > outside the scope of SIPREC. The global-id in format > > > > > > shall be used > > > > > > > > to correlate. Please let me know in case any current > > > > > > SIPREC metadata > > > > > > > > attribute MUST be passed through this CTS link. > > > > > > > > > > > > > > > > > As for examples, the basic information as media type, > > labels, > > > > > > > > > volume etc. Any application level data can be relevant. > > Even > > > > > > > > > indication of encryption (for a case where RS is not > > > > > encrypted) > > > > > > > > > > > > > > > > > > Leon > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: siprec-bounces@ietf.org > > > > > > > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Charles > > Eckel > > > > > > > > (eckelcu) > > > > > > > > > Sent: Wednesday, June 29, 2011 7:17 PM > > > > > > > > > To: Elwell, John; Parthasarathi R (partr); > > siprec@ietf.org > > > > > > > > > Subject: Re: [siprec] Content (RFC 4796) attribute in > > > > > SDP or XML > > > > > > > > > > > > > > > > > > I think it is sufficient, especially since we can assign > > new > > > > > > > > > values if necessary. > > > > > > > > > Are there any examples of what people think they > > > > > might want to > > > > > > > > > capture in the SDP and/or metadata field? > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > Charles > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: siprec-bounces@ietf.org > > > > > > [mailto:siprec-bounces@ietf.org] > > > > > > > > > > On > > > > > > > > > Behalf Of Elwell, John > > > > > > > > > > Sent: Tuesday, June 28, 2011 3:11 AM > > > > > > > > > > To: Parthasarathi R (partr); siprec@ietf.org > > > > > > > > > > Subject: Re: [siprec] Content (RFC 4796) attribute in > > > > > > SDP or XML > > > > > > > > > > > > > > > > > > > > I would like other opinions on whether the > > SDP a=3Dcontent > > > > > > > > > attribute in > > > > > > > > > the RS SDP has the correct > > > > > > > > > > semantics for representing the content type of the > > > > > > > > recorded CS media > > > > > > > > > stream. > > > > > > > > > > > > > > > > > > > > John > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Parthasarathi R (partr) > > [mailto:partr@cisco.com] > > > > > > > > > > > Sent: 28 June 2011 10:45 > > > > > > > > > > > To: Elwell, John; siprec@ietf.org > > > > > > > > > > > Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > > > > > > > > > > Subject: RE: Content (RFC 4796) attribute in SDP or > > XML > > > > > > > > > > > > > > > > > > > > > > John, > > > > > > > > > > > > > > > > > > > > > > In case if it is the argument of whether CS > > MS content > > > > > > > > > type or RS MS > > > > > > > > > > > > > > > > > > > > content type in the metadata, it is better for us to > > > > > > > > > re-open ticket > > > > > > > > > > > #71 > > > > > > > > > > > > > > > > > > > > > > > > > > (http://www.ietf.org/mail- > > > > archive/web/siprec/current/msg02106.html). > > > > > > > > > > > Please let me know your opinion here. > > > > > > > > > > > > > > > > > > > > > > The basic idea in metadata format is to re-use as > > > > > > much as SDP > > > > > > > > > > > attribute (like direction, content) in > > media level for > > > > > > > > RS dialog > > > > > > > > > > > (using SDP label attribute as a pointer) until > > otherwise > > > > > > > > > there is a > > > > > > > > > > > restriction in using in such manner. As per > > RFC 4796, > > > > > > > > there is no > > > > > > > > > > > such restriction and so, I prefer to reuse > > as content > > SDP > > > > > > > > > attribute > > > > > > > > > > > rather than introducing the new > > > > > element for > > > > > > > > > > > this purpose. > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > Partha > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Elwell, John > > > > > > [mailto:john.elwell@siemens-enterprise.com] > > > > > > > > > > > Sent: Monday, June 27, 2011 1:18 PM > > > > > > > > > > > To: Parthasarathi R (partr); siprec@ietf.org > > > > > > > > > > > Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > > > > > > > > > > Subject: RE: Content (RFC 4796) attribute in SDP or > > XML > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: Parthasarathi R (partr) > > [mailto:partr@cisco.com] > > > > > > > > > > > > Sent: 27 June 2011 08:08 > > > > > > > > > > > > To: siprec@ietf.org; Elwell, John > > > > > > > > > > > > Cc: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat) > > > > > > > > > > > > Subject: Content (RFC 4796) attribute in > > SDP or XML > > > > > > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > > > > > > > As per the last interim SIPREC meeting, there is a > > > > > > > > consensus to > > > > > > > > > > > > describe the content of an MS using RFC 4796 & its > > > > > > > > > > > extension. As per > > > > > > > > > > > > RFC 4796, the multiple instance of > > content attribute > > > > > > > > is possible > > > > > > > > > to > > > > > > > > > > > > exist in SDP which shall be used in RS SDP. SRS > > > > > > shall group > > > > > > > > > > > the same > > > > > > > > > > > > media content types by "content" attribute in RS > > > > > > SDP. We are > > > > > > > > > > > > interested in knowing any specfic reason for this > > > > > > > > > attribute to be > > > > > > > > > > > > duplicated in Metadata XML. > > > > > > > > > > > [JRE] I don't have a reason for **duplication**. > > > > > > > > However, I think > > > > > > > > > > > there is a valid question to be asked whether the > > content > > > > > > > > > type of an > > > > > > > > > > > > > > > > > > > > MS should be represented: > > > > > > > > > > > A) in XML; or > > > > > > > > > > > B) in RS SDP as a=3Dcontent. > > > > > > > > > > > > > > > > > > > > > > The content type we are talking about is an > > MS content > > > > > > > > > type, i.e., > > > > > > > > > > > relating to the CS. One could argue that the > > > > > > > > > corresponding RS stream > > > > > > > > > > > > > > > > > > > > is NOT the same content type. For example: > > > > > > > > > > > - CS MS content type is "slides". > > > > > > > > > > > - RS media stream content type is "recording of > > slides". > > > > > > > > > > > > > > > > > > > > > > On this basis, I think the correct option for > > > > > > conveying the MS > > > > > > > > > content > > > > > > > > > > > type "slides" is A) (in the XML). > > > > > > > > > > > > > > > > > > > > > > Note that this would not involve > > duplication. The SDP > > > > > > > > > > > a=3Dcontent attribute is optional, so we need not use > > > > > > it for the RS. > > > > > > > > > > > > > > > > > > > > > > Perhaps my distinction is too theoretical, but I do > > > > > > > > feel a little > > > > > > > > > more > > > > > > > > > > > comfortable using the XML rather than the RS SDP. > > > > > > > > > > > > > > > > > > > > > > John (as individual) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > > > > > > > Partha > > > > > > > > > > > > > > > > > > > > > > > > last Interim SIPREC meeting Note: > > > > > > > > > > > > > > > > > > > > > > > > Slide 7: On the question of how to describe the > > content > > > > > > > > > of an MS, > > > > > > > > > > > > there was no objection to basing this on the types > > in > > > > > > > > > the RFC 4796 > > > > > > > > > > > > > > > > > > > > > registry (new values could be specified via the > > > > > > appropriate > > > > > > > > > > > means if > > > > > > > > > > > > needed). Paul had a slight concern that you might > > > > > > be mixing > > > > > > > > > > > multiple > > > > > > > > > > > > CS MSs into a single RS media stream and whether > > > > > > this might > > > > > > > > > > > result in > > > > > > > > > > > > cases not describable in this way, but in the end > > > > > > > > accepted the > > > > > > > > > > > > consensus. It needs to be discussed on the list > > > > > > > > whether this is > > > > > > > > > > > > conveyed in XML or in the RS SDP a=3Dcontent > > attribute. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > siprec mailing list > > > > > > > > > > siprec@ietf.org > > > > > > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > > _______________________________________________ > > > > > > > > > siprec mailing list > > > > > > > > > siprec@ietf.org > > > > > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > siprec mailing list > > > > siprec@ietf.org > > > > https://www.ietf.org/mailman/listinfo/siprec > > From pkyzivat@alum.mit.edu Thu Jul 7 19:05: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 B23A021F8685 for ; Thu, 7 Jul 2011 19:05:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.358 X-Spam-Level: X-Spam-Status: No, score=-2.358 tagged_above=-999 required=5 tests=[AWL=0.241, 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 btc2TMISAlCR for ; Thu, 7 Jul 2011 19:05:03 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by ietfa.amsl.com (Postfix) with ESMTP id 9F3A021F8684 for ; Thu, 7 Jul 2011 19:05:03 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta07.westchester.pa.mail.comcast.net with comcast id 5Dwk1h0051uE5Es57E547j; Fri, 08 Jul 2011 02:05:04 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta16.westchester.pa.mail.comcast.net with comcast id 5E531h00K0tdiYw3cE53bd; Fri, 08 Jul 2011 02:05:04 +0000 Message-ID: <4E1665CD.1040607@alum.mit.edu> Date: Thu, 07 Jul 2011 22:05:01 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "Charles Eckel (eckelcu)" References: <07465C1D981ABC41A344374066AE1A2C38AF6D40CC@TLVMBX01.nice.com><07465C1D981ABC41A344374066AE1A2C38AF6D4376@TLVMBX01.nice.com><07465C1D981ABC41A344374066AE1A2C38AFE9B1C0@TLVMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD06E358D2@XMB-BGL-417.cisco.com> <4E14D3 21.1030902@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: siprec@ietf.org Subject: Re: [siprec] Content (RFC 4796) attribute in SDP or XML X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 02:05:04 -0000 On 7/7/11 1:07 PM, Charles Eckel (eckelcu) wrote: >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Paul Kyzivat >> Sent: Wednesday, July 06, 2011 2:27 PM >> To: siprec@ietf.org >> Subject: Re: [siprec] Content (RFC 4796) attribute in SDP or XML >> >> On 7/6/11 4:05 PM, Charles Eckel (eckelcu) wrote: >>> RFC 4796 has registered the following values: >>> >>> slides RFC 4796 Presentation slides >>> speaker RFC 4796 Image from the speaker >>> sl RFC 4796 Sign language >>> main RFC 4796 Main media stream >>> alt RFC 4796 Alternative media stream >>> >>> Suppose we register the following new values: >>> >>> siprec1 RFC xxxx SIPREC value 1 >>> siprec2 RFC xxxx SIPREC value 2 >>> siprec3 RFC xxxx SIPREC value 3 >> >> I don't get it. What is the purpose of siprecN? > > I don't have any purpose to assign or propose at this time. My > understanding from previous thread is that others felt the existing set > of values defined for the content attribute might not be sufficient. I > was merely illustrating that we could define new values, if necessary. My thinking was that if we needed any new values (though I'm not sure we do) the purpose would be to communicate something special about the RS media streams, and so would never be seen in the CS media streams. Thanks, Paul From rmohanr@cisco.com Thu Jul 7 21:59: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 9A4B221F891A for ; Thu, 7 Jul 2011 21:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.419 X-Spam-Level: X-Spam-Status: No, score=-10.419 tagged_above=-999 required=5 tests=[AWL=0.180, 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 Hd65aNO1oxEq for ; Thu, 7 Jul 2011 21:59:06 -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 948A821F8915 for ; Thu, 7 Jul 2011 21:59:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=3500; q=dns/txt; s=iport; t=1310101146; x=1311310746; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=Wlq516lC04kz+wvsoUHF2I3DFAVEC9Jx80ZDf57jo7k=; b=fYfs9EX2aQrMSImgHdMc53xFmZLIG3uWY0yxUODPe4DpTkKf3/klezGb wrpj/aQrwLJjEJtxt1CCnx4uVNEgGWNnU2Dh+TEusglPn6raOdMbX9aTX CfweA/EiLKeXSVH1f5MUZ1VasisVoKW+923CYmde+nsv0fbYa2K3ln8Xk s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMBAM+NFk5Io8UQ/2dsb2JhbABTmAuPN3eIe6VonXuGOASHSpAIi0Y X-IronPort-AV: E=Sophos;i="4.65,498,1304294400"; d="scan'208";a="41153440" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-2.cisco.com with ESMTP; 08 Jul 2011 04:59:04 +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 p684x4tx012637; Fri, 8 Jul 2011 04:59: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); Fri, 8 Jul 2011 10:29: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: Fri, 8 Jul 2011 10:29:01 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD06F4FD89@XMB-BGL-417.cisco.com> In-reply-to: <07465C1D981ABC41A344374066AE1A2C38AFE9BB98@TLVMBX01.nice.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Comment on metadata-02 - Media Stream Thread-Index: Acw8qtezJdNopWF7RZqONH6e5tBRLgAAYkSAAB8nk4A= References: <07465C1D981ABC41A344374066AE1A2C38AFE9BB98@TLVMBX01.nice.com> From: "Ram Mohan R (rmohanr)" To: "Leon Portman" , "Elwell, John" , X-OriginalArrivalTime: 08 Jul 2011 04:59:04.0070 (UTC) FILETIME=[C25D8A60:01CC3D2B] Subject: Re: [siprec] Comment on metadata-02 - Media Stream X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 04:59:07 -0000 Hello John / Leon, Thanks for your comments on MS block in the metadata. I agree that the current text is little confusing. It is because when we started off with the metadata draft we intended that MS block represents properties of CS media. However after discussions we reached to a consensus that MS does not need to have CS media parameters.=20 John's suggestion for definition is > Possibly a definition like: > "A Media Stream block represents a single RTP session between an SRC > and an SRS. Note that, because of possible mixing at the SRC, a Media > Stream block does not necessarily represent a single RTP session > between CS participants." My suggestion is "An MS block/class represents an entity which helps to link participants ( of CS) to its associated Media Streams ( in RS), the properties of which will be carried in RS SDP". Please suggest if this text works fine. If not refine/suggest improvements. Regards, Ram > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Leon Portman > Sent: Thursday, July 07, 2011 7:20 PM > To: Elwell, John; siprec@ietf.org > Subject: Re: [siprec] Comment on metadata-02 - Media Stream >=20 > Actually I was expecting (a) as well. And it should point to the > relevant media lines in RS SDP. If two or more Media Streams point to > the same RS SDP m-line label, then we have mixing use case >=20 > So something like this: CS MS (1:1)- > XML MS -> (N:1) -> RS MS >=20 > Leon >=20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Elwell, John > Sent: Thursday, July 07, 2011 4:36 PM > To: siprec@ietf.org > Subject: [siprec] Comment on metadata-02 - Media Stream >=20 > In section 6.5, Media Stream seems to be defined as follows: > "A Media Stream block MUST have properties of media as seen by SRC and > sent to SRS." > Ignoring the possibly inappropriate RFC 2119 language, I don't think > this clearly defines whether: > a) this represents a medium of the CS (i.e., corresponding to a media > description in the CS SDP); or > b) this represents a medium of the RS (i.e., corresponding to a media > description in the RS SDP). >=20 > Both of these are "seen by SRC". There need not be a 1:1 relationship > between the two, and hence we need to make it clear which it > represents. >=20 > Although personally I had expected a), a couple of threads in recent > months have seemed to indicate b) is the general consensus. >=20 > Possibly a definition like: > "A Media Stream block represents a single RTP session between an SRC > and an SRS. Note that, because of possible mixing at the SRC, a Media > Stream block does not necessarily represent a single RTP session > between CS participants." >=20 > However, if we accept this principle, I wonder what the Start Time and > End Time attributes mean. The start and end of an RS RTP session > correspond to the relevant offer-answer exchanges, so they don't really > need to be in XML. So I suspect I still haven't drilled down into the > real meaning of MS sufficiently. >=20 > John (as individual) >=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 Jul 7 23:49: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 C208421F88D9 for ; Thu, 7 Jul 2011 23:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.416 X-Spam-Level: X-Spam-Status: No, score=-106.416 tagged_above=-999 required=5 tests=[AWL=0.183, 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 5wJo9FS3c7le for ; Thu, 7 Jul 2011 23:49:42 -0700 (PDT) Received: from mail174.messagelabs.com (mail174.messagelabs.com [85.158.138.51]) by ietfa.amsl.com (Postfix) with SMTP id AE66521F88C6 for ; Thu, 7 Jul 2011 23:49:38 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1310107777!24103728!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 6603 invoked from network); 8 Jul 2011 06:49:37 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-13.tower-174.messagelabs.com with SMTP; 8 Jul 2011 06:49:37 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 442651EB83EF; Fri, 8 Jul 2011 08:49:37 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 8 Jul 2011 08:49:37 +0200 From: "Elwell, John" To: "Ram Mohan R (rmohanr)" , Leon Portman , "siprec@ietf.org" Date: Fri, 8 Jul 2011 08:49:35 +0200 Thread-Topic: [siprec] Comment on metadata-02 - Media Stream Thread-Index: Acw8qtezJdNopWF7RZqONH6e5tBRLgAAYkSAAB8nk4AABHr7gA== Message-ID: References: <07465C1D981ABC41A344374066AE1A2C38AFE9BB98@TLVMBX01.nice.com> <35BCE99A477D6A4986FB2216D8CF2CFD06F4FD89@XMB-BGL-417.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD06F4FD89@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] Comment on metadata-02 - Media Stream X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 06:49:42 -0000 Ram, In my opinion your proposed definition is too abstract - I think a reader w= ould have a hard time understanding what such an object represents in the r= eal world. Can you pinpoint your objections to my proposal? Thanks, John =20 > -----Original Message----- > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com]=20 > Sent: 08 July 2011 05:59 > To: Leon Portman; Elwell, John; siprec@ietf.org > Subject: RE: [siprec] Comment on metadata-02 - Media Stream >=20 > Hello John / Leon, >=20 > Thanks for your comments on MS block in the metadata. I agree that the > current text is little confusing. > It is because when we started off with the metadata draft we intended > that MS block represents properties of CS media. >=20 > However after discussions we reached to a consensus that MS does not > need to have CS media parameters.=20 >=20 > John's suggestion for definition is >=20 > > Possibly a definition like: > > "A Media Stream block represents a single RTP session between an SRC > > and an SRS. Note that, because of possible mixing at the=20 > SRC, a Media > > Stream block does not necessarily represent a single RTP session > > between CS participants." >=20 > My suggestion is >=20 > "An MS block/class represents an entity which helps to link=20 > participants > ( of CS) to its associated Media Streams ( in RS), the properties of > which will be carried in RS SDP". >=20 > Please suggest if this text works fine. If not refine/suggest > improvements. >=20 > Regards, > Ram >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Leon Portman > > Sent: Thursday, July 07, 2011 7:20 PM > > To: Elwell, John; siprec@ietf.org > > Subject: Re: [siprec] Comment on metadata-02 - Media Stream > >=20 > > Actually I was expecting (a) as well. And it should point to the > > relevant media lines in RS SDP. If two or more Media=20 > Streams point to > > the same RS SDP m-line label, then we have mixing use case > >=20 > > So something like this: CS MS (1:1)- > XML MS -> (N:1) -> RS MS > >=20 > > Leon > >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Elwell, John > > Sent: Thursday, July 07, 2011 4:36 PM > > To: siprec@ietf.org > > Subject: [siprec] Comment on metadata-02 - Media Stream > >=20 > > In section 6.5, Media Stream seems to be defined as follows: > > "A Media Stream block MUST have properties of media as seen=20 > by SRC and > > sent to SRS." > > Ignoring the possibly inappropriate RFC 2119 language, I don't think > > this clearly defines whether: > > a) this represents a medium of the CS (i.e., corresponding=20 > to a media > > description in the CS SDP); or > > b) this represents a medium of the RS (i.e., corresponding=20 > to a media > > description in the RS SDP). > >=20 > > Both of these are "seen by SRC". There need not be a 1:1=20 > relationship > > between the two, and hence we need to make it clear which it > > represents. > >=20 > > Although personally I had expected a), a couple of threads in recent > > months have seemed to indicate b) is the general consensus. > >=20 > > Possibly a definition like: > > "A Media Stream block represents a single RTP session between an SRC > > and an SRS. Note that, because of possible mixing at the=20 > SRC, a Media > > Stream block does not necessarily represent a single RTP session > > between CS participants." > >=20 > > However, if we accept this principle, I wonder what the=20 > Start Time and > > End Time attributes mean. The start and end of an RS RTP session > > correspond to the relevant offer-answer exchanges, so they don't > really > > need to be in XML. So I suspect I still haven't drilled=20 > down into the > > real meaning of MS sufficiently. > >=20 > > John (as individual) > >=20 > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > = From rmohanr@cisco.com Fri Jul 8 00:00: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 A3CEE21F86C7 for ; Fri, 8 Jul 2011 00:00:26 -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 DTM5KeU1raPC for ; Fri, 8 Jul 2011 00:00:25 -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 3905A21F88BC for ; Fri, 8 Jul 2011 00:00:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=5038; q=dns/txt; s=iport; t=1310108425; x=1311318025; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=GEqcKUPlBUcRwBblIbzF7nTqOXcnwrL0pQ7aaLnqx6o=; b=iBOSHDwiZ1nOERwgf8SHmf9S7UUA4bGA0LO/85iwl8QIfoZu0C2j6+aF 5P03M8tLAxllBqSynCRt77rgaUDjb/VETKFjrJtdj/KsdGVzHSfppvQM5 B1nNLADLZ3RPr4r8yii6O8X6Z+7R2KnI1LVob2ePNDmxa0jayEJeixcDS U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMBAO+pFk5Io8UT/2dsb2JhbABTmAuPN3eue51yhjgEh0qQCItG X-IronPort-AV: E=Sophos;i="4.65,498,1304294400"; d="scan'208";a="41174142" Received: from bgl-core-4.cisco.com ([72.163.197.19]) by ams-iport-2.cisco.com with ESMTP; 08 Jul 2011 07:00:23 +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 p6870M8B032206; Fri, 8 Jul 2011 07:00:22 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Jul 2011 12:30:22 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 8 Jul 2011 12:30:21 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD06F4FE0B@XMB-BGL-417.cisco.com> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Comment on metadata-02 - Media Stream Thread-Index: Acw8qtezJdNopWF7RZqONH6e5tBRLgAAYkSAAB8nk4AABHr7gAAAZo/Q References: <07465C1D981ABC41A344374066AE1A2C38AFE9BB98@TLVMBX01.nice.com> <35BCE99A477D6A4986FB2216D8CF2CFD06F4FD89@XMB-BGL-417.cisco.com> From: "Ram Mohan R (rmohanr)" To: "Elwell, John" , "Leon Portman" , X-OriginalArrivalTime: 08 Jul 2011 07:00:22.0691 (UTC) FILETIME=[B4C2F730:01CC3D3C] Subject: Re: [siprec] Comment on metadata-02 - Media Stream X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 07:00:26 -0000 John, I don't have any such issues with your definition. I think we can add " MS block helps to link participants ( of CS) to its associated Media Streams ( in RS), the properties of which will be carried in RS SDP" to your definition.=20 I would like to have this line as it clearly says the intention /purpose of MS block. Regards, Ram > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Friday, July 08, 2011 12:20 PM > To: Ram Mohan R (rmohanr); Leon Portman; siprec@ietf.org > Subject: RE: [siprec] Comment on metadata-02 - Media Stream >=20 > Ram, >=20 > In my opinion your proposed definition is too abstract - I think a > reader would have a hard time understanding what such an object > represents in the real world. Can you pinpoint your objections to my > proposal? >=20 > Thanks, >=20 > John >=20 >=20 > > -----Original Message----- > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > Sent: 08 July 2011 05:59 > > To: Leon Portman; Elwell, John; siprec@ietf.org > > Subject: RE: [siprec] Comment on metadata-02 - Media Stream > > > > Hello John / Leon, > > > > Thanks for your comments on MS block in the metadata. I agree that > the > > current text is little confusing. > > It is because when we started off with the metadata draft we intended > > that MS block represents properties of CS media. > > > > However after discussions we reached to a consensus that MS does not > > need to have CS media parameters. > > > > John's suggestion for definition is > > > > > Possibly a definition like: > > > "A Media Stream block represents a single RTP session between an > SRC > > > and an SRS. Note that, because of possible mixing at the > > SRC, a Media > > > Stream block does not necessarily represent a single RTP session > > > between CS participants." > > > > My suggestion is > > > > "An MS block/class represents an entity which helps to link > > participants > > ( of CS) to its associated Media Streams ( in RS), the properties of > > which will be carried in RS SDP". > > > > Please suggest if this text works fine. If not refine/suggest > > improvements. > > > > Regards, > > Ram > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > > Behalf Of Leon Portman > > > Sent: Thursday, July 07, 2011 7:20 PM > > > To: Elwell, John; siprec@ietf.org > > > Subject: Re: [siprec] Comment on metadata-02 - Media Stream > > > > > > Actually I was expecting (a) as well. And it should point to the > > > relevant media lines in RS SDP. If two or more Media > > Streams point to > > > the same RS SDP m-line label, then we have mixing use case > > > > > > So something like this: CS MS (1:1)- > XML MS -> (N:1) -> RS MS > > > > > > Leon > > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > > Behalf Of Elwell, John > > > Sent: Thursday, July 07, 2011 4:36 PM > > > To: siprec@ietf.org > > > Subject: [siprec] Comment on metadata-02 - Media Stream > > > > > > In section 6.5, Media Stream seems to be defined as follows: > > > "A Media Stream block MUST have properties of media as seen > > by SRC and > > > sent to SRS." > > > Ignoring the possibly inappropriate RFC 2119 language, I don't > think > > > this clearly defines whether: > > > a) this represents a medium of the CS (i.e., corresponding > > to a media > > > description in the CS SDP); or > > > b) this represents a medium of the RS (i.e., corresponding > > to a media > > > description in the RS SDP). > > > > > > Both of these are "seen by SRC". There need not be a 1:1 > > relationship > > > between the two, and hence we need to make it clear which it > > > represents. > > > > > > Although personally I had expected a), a couple of threads in > recent > > > months have seemed to indicate b) is the general consensus. > > > > > > Possibly a definition like: > > > "A Media Stream block represents a single RTP session between an > SRC > > > and an SRS. Note that, because of possible mixing at the > > SRC, a Media > > > Stream block does not necessarily represent a single RTP session > > > between CS participants." > > > > > > However, if we accept this principle, I wonder what the > > Start Time and > > > End Time attributes mean. The start and end of an RS RTP session > > > correspond to the relevant offer-answer exchanges, so they don't > > really > > > need to be in XML. So I suspect I still haven't drilled > > down into the > > > real meaning of MS sufficiently. > > > > > > John (as individual) > > > > > > _______________________________________________ > > > siprec mailing list > > > siprec@ietf.org > > > https://www.ietf.org/mailman/listinfo/siprec > > > _______________________________________________ > > > siprec mailing list > > > siprec@ietf.org > > > https://www.ietf.org/mailman/listinfo/siprec > > From john.elwell@siemens-enterprise.com Fri Jul 8 05:31: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 71D2521F854E for ; Fri, 8 Jul 2011 05:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.424 X-Spam-Level: X-Spam-Status: No, score=-106.424 tagged_above=-999 required=5 tests=[AWL=0.175, 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 Mlb45Jwc9RtZ for ; Fri, 8 Jul 2011 05:31:49 -0700 (PDT) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfa.amsl.com (Postfix) with SMTP id 153AA21F854D for ; Fri, 8 Jul 2011 05:31:48 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1310128303!40535906!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 2167 invoked from network); 8 Jul 2011 12:31:43 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-15.tower-27.messagelabs.com with SMTP; 8 Jul 2011 12:31:43 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 607561EB83F2; Fri, 8 Jul 2011 14:31:47 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 8 Jul 2011 14:31:45 +0200 From: "Elwell, John" To: "Ram Mohan R (rmohanr)" , Leon Portman , "siprec@ietf.org" Date: Fri, 8 Jul 2011 14:31:44 +0200 Thread-Topic: [siprec] Comment on metadata-02 - Media Stream Thread-Index: Acw8qtezJdNopWF7RZqONH6e5tBRLgAAYkSAAB8nk4AABHr7gAAAZo/QAAucg6A= Message-ID: References: <07465C1D981ABC41A344374066AE1A2C38AFE9BB98@TLVMBX01.nice.com> <35BCE99A477D6A4986FB2216D8CF2CFD06F4FD89@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD06F4FE0B@XMB-BGL-417.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD06F4FE0B@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] Comment on metadata-02 - Media Stream X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 12:31:50 -0000 OK, sounds like a good compromise. John=20 > -----Original Message----- > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com]=20 > Sent: 08 July 2011 08:00 > To: Elwell, John; Leon Portman; siprec@ietf.org > Subject: RE: [siprec] Comment on metadata-02 - Media Stream >=20 > John, >=20 > I don't have any such issues with your definition. I think we=20 > can add " > MS block helps to link participants ( of CS) to its associated Media > Streams ( in RS), the properties of which will be carried in=20 > RS SDP" to > your definition.=20 >=20 > I would like to have this line as it clearly says the=20 > intention /purpose > of MS block. >=20 > Regards, > Ram >=20 > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Friday, July 08, 2011 12:20 PM > > To: Ram Mohan R (rmohanr); Leon Portman; siprec@ietf.org > > Subject: RE: [siprec] Comment on metadata-02 - Media Stream > >=20 > > Ram, > >=20 > > In my opinion your proposed definition is too abstract - I think a > > reader would have a hard time understanding what such an object > > represents in the real world. Can you pinpoint your objections to my > > proposal? > >=20 > > Thanks, > >=20 > > John > >=20 > >=20 > > > -----Original Message----- > > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > > Sent: 08 July 2011 05:59 > > > To: Leon Portman; Elwell, John; siprec@ietf.org > > > Subject: RE: [siprec] Comment on metadata-02 - Media Stream > > > > > > Hello John / Leon, > > > > > > Thanks for your comments on MS block in the metadata. I agree that > > the > > > current text is little confusing. > > > It is because when we started off with the metadata draft we > intended > > > that MS block represents properties of CS media. > > > > > > However after discussions we reached to a consensus that=20 > MS does not > > > need to have CS media parameters. > > > > > > John's suggestion for definition is > > > > > > > Possibly a definition like: > > > > "A Media Stream block represents a single RTP session between an > > SRC > > > > and an SRS. Note that, because of possible mixing at the > > > SRC, a Media > > > > Stream block does not necessarily represent a single RTP session > > > > between CS participants." > > > > > > My suggestion is > > > > > > "An MS block/class represents an entity which helps to link > > > participants > > > ( of CS) to its associated Media Streams ( in RS), the=20 > properties of > > > which will be carried in RS SDP". > > > > > > Please suggest if this text works fine. If not refine/suggest > > > improvements. > > > > > > Regards, > > > Ram > > > > > > > -----Original Message----- > > > > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On > > > > Behalf Of Leon Portman > > > > Sent: Thursday, July 07, 2011 7:20 PM > > > > To: Elwell, John; siprec@ietf.org > > > > Subject: Re: [siprec] Comment on metadata-02 - Media Stream > > > > > > > > Actually I was expecting (a) as well. And it should point to the > > > > relevant media lines in RS SDP. If two or more Media > > > Streams point to > > > > the same RS SDP m-line label, then we have mixing use case > > > > > > > > So something like this: CS MS (1:1)- > XML MS -> (N:1) -> RS MS > > > > > > > > Leon > > > > > > > > -----Original Message----- > > > > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On > > > > Behalf Of Elwell, John > > > > Sent: Thursday, July 07, 2011 4:36 PM > > > > To: siprec@ietf.org > > > > Subject: [siprec] Comment on metadata-02 - Media Stream > > > > > > > > In section 6.5, Media Stream seems to be defined as follows: > > > > "A Media Stream block MUST have properties of media as seen > > > by SRC and > > > > sent to SRS." > > > > Ignoring the possibly inappropriate RFC 2119 language, I don't > > think > > > > this clearly defines whether: > > > > a) this represents a medium of the CS (i.e., corresponding > > > to a media > > > > description in the CS SDP); or > > > > b) this represents a medium of the RS (i.e., corresponding > > > to a media > > > > description in the RS SDP). > > > > > > > > Both of these are "seen by SRC". There need not be a 1:1 > > > relationship > > > > between the two, and hence we need to make it clear which it > > > > represents. > > > > > > > > Although personally I had expected a), a couple of threads in > > recent > > > > months have seemed to indicate b) is the general consensus. > > > > > > > > Possibly a definition like: > > > > "A Media Stream block represents a single RTP session between an > > SRC > > > > and an SRS. Note that, because of possible mixing at the > > > SRC, a Media > > > > Stream block does not necessarily represent a single RTP session > > > > between CS participants." > > > > > > > > However, if we accept this principle, I wonder what the > > > Start Time and > > > > End Time attributes mean. The start and end of an RS RTP session > > > > correspond to the relevant offer-answer exchanges, so they don't > > > really > > > > need to be in XML. So I suspect I still haven't drilled > > > down into the > > > > real meaning of MS sufficiently. > > > > > > > > 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 Fri Jul 8 08:51: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 4969F21F8AF5 for ; Fri, 8 Jul 2011 08:51:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.17 X-Spam-Level: X-Spam-Status: No, score=-10.17 tagged_above=-999 required=5 tests=[AWL=-0.172, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_53=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 EjG959DUbvUb for ; Fri, 8 Jul 2011 08:51: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 B5EA721F8AFD for ; Fri, 8 Jul 2011 08:51:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=15008; q=dns/txt; s=iport; t=1310140282; x=1311349882; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=z7HYwWLtVDbOfWu5pSv5xXoo8lBcvoJcmi6W0FvS7/M=; b=QRgKojHMDVfDtl8kYy0M+oRYGi9fldvsWKdKkJdLvm3+YL0Af87StQZs vPSiS0OE/9cvavzTPZNMLCvp8jU1M4Z5Qz1H9B22Mc40+uxIoTGBkHla/ tHH+8NIxSYjRclMV7aU7mXJaM2UfiEGFWdg2XVTjUV4Cqotwg2zHqIK5+ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvkAAGkmF05Io8US/2dsb2JhbABSglGVPockiBN3rSGdeIY4BIdKkAiLRg X-IronPort-AV: E=Sophos;i="4.65,499,1304294400"; d="scan'208,217";a="100382702" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-1.cisco.com with ESMTP; 08 Jul 2011 15:51:20 +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 p68FpKNm021143 for ; Fri, 8 Jul 2011 15:51:20 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Jul 2011 21:21:20 +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_01CC3D86.E133C13E" Date: Fri, 8 Jul 2011 21:21:18 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD06F4FF7F@XMB-BGL-417.cisco.com> In-reply-to: <35BCE99A477D6A4986FB2216D8CF2CFD06D3323D@XMB-BGL-417.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] CSG start & stop time attribute requirement Thread-Index: Acw0kGxvAtp8hudRQFqbSwPv+BTXsQARfy2AAiwW7rA= References: <35BCE99A477D6A4986FB2216D8CF2CFD06D3323D@XMB-BGL-417.cisco.com> From: "Ram Mohan R (rmohanr)" To: X-OriginalArrivalTime: 08 Jul 2011 15:51:20.0358 (UTC) FILETIME=[E1692C60:01CC3D86] Subject: Re: [siprec] CSG start & stop time attribute requirement X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 15:51:24 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC3D86.E133C13E Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable I have not heard back any comments on this. Can people let us know your thoughts on having Start/Stop time attribute for CSG block ? =20 Regards, Ram From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Ram Mohan R (rmohanr) Sent: Monday, June 27, 2011 8:33 PM To: Parthasarathi R (partr); siprec@ietf.org Subject: Re: [siprec] CSG start & stop time attribute requirement =20 To add more to what Partha has mentioned another use case is when multiple RSs are used for recording a CSG it is easy to determine start/ Stop time when explicitly indicated in CSG. So I would prefer to have Start/ Stop time explicitly indicated in CS-Group and which would indicate when a Group Starts/ End. =20 Ram =20 From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi R (partr) Sent: Monday, June 27, 2011 11:37 AM To: siprec@ietf.org Subject: [siprec] CSG start & stop time attribute requirement =20 Hi all, =20 As per interim meeting, there is a need to explain the reason for having start/stop time in CSG group. Two reasons for having this attribute: =20 1) BYE will serve the purpose in case CSG is within single RS or ending at the end of some RS. In case CSG is terminated in the middle of RS session (persistent session), there is a need of an attribute. As it is middle of the RS, it is better to have the exact time. =20 2) In case partial-update of metadata format, there is an need of XML element to indicate the termination of CSG ("group") element. It shall be achieved by "stop-time" element within CSG. =20 Thanks Partha =20 Note: Topic - Metadata model(Ram Mohan) draft-ietf-siprec-metadata-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-ietf-siprec-metadata/ =20 Slides: http://trac.tools.ietf.org/wg/siprec/trac/attachment/wiki/WikiStart/SIPR EC%20Metamodel%20-%20Virtual%20Interim-23Jun_2011.pptx =20 Side 5: On the issue of whether a CSG element needs a start/stop time, Ram explained that the information could be derived from the start/stop times of the CSs that form part of that group (although he was concerned about the complications of overlapping CSs), or could be explicitly indicated for the group. Leon and John thought that implicit should be sufficient. Partha tried to express a point concerning termination of a CSG, but this needs to be raised on the list. ------_=_NextPart_001_01CC3D86.E133C13E Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

I have not heard back any comments on this. Can people let us know = your thoughts on having Start/Stop time attribute for CSG block = ?

 

Regards,

Ram

From:= = siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of = Ram Mohan R (rmohanr)
Sent: Monday, June 27, 2011 8:33 = PM
To: Parthasarathi R (partr); = siprec@ietf.org
Subject: Re: [siprec] CSG start & stop = time attribute requirement

 

To add more to what Partha has mentioned another use case is when = multiple RSs are used for recording a CSG it is easy to determine start/ = Stop time when explicitly indicated in CSG.

So I would prefer to have Start/ Stop time explicitly indicated in = CS-Group and which would indicate when a Group Starts/ = End.

 

Ram

 

From:= = siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of = Parthasarathi R (partr)
Sent: Monday, June 27, 2011 11:37 = AM
To: siprec@ietf.org
Subject: [siprec] CSG start = & stop time attribute = requirement

 

Hi = all,

 

As per = interim meeting, there is a need to explain the reason for having = start/stop time in CSG group. Two reasons for having this = attribute:

 

1) BYE will = serve the purpose in case CSG is within single RS or ending at the end = of some RS. In case CSG is terminated in the middle of RS session = (persistent session), there is a need of an attribute.  As it is = middle of the RS, it is better to have the exact = time.

 

2) In case = partial-update of metadata format, there is an need of XML element to = indicate the termination of CSG ("group") element. It = shall be achieved by "stop-time" element within = CSG.

 

Thanks=

Partha=

 

Note:<= o:p>

Topic - = Metadata model(Ram Mohan)

draft-ietf-si= prec-metadata-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<= /p>

Draft: = https://datatracker.ietf.org/doc/draft-ietf-siprec-metadata/

Slides: = http://trac.tools.ietf.org/wg/siprec/trac/attachment/wiki/WikiS= tart/SIPREC%20Metamodel%20-%20Virtual%20Interim-23Jun_2011.pptx

Side 5: On = the issue of whether a CSG element needs a start/stop time, Ram = explained that the information could be derived from the start/stop = times of the CSs that form part of that group (although he was concerned = about the complications of overlapping CSs), or could be explicitly = indicated for the group. Leon and John thought that implicit should be = sufficient. Partha tried to express a point concerning termination of a = CSG, but this needs to be raised on the = list.

------_=_NextPart_001_01CC3D86.E133C13E-- From rmohanr@cisco.com Fri Jul 8 09:25: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 CA1D121F8BBC for ; Fri, 8 Jul 2011 09:25:08 -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 8z12fQ0ndpYo for ; Fri, 8 Jul 2011 09:25:08 -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 B87B521F8BB7 for ; Fri, 8 Jul 2011 09:25:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=3273; q=dns/txt; s=iport; t=1310142307; x=1311351907; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=dSuTjOSHqqr19os//fiINBEx6cultwxEBQ02C0MBL+0=; b=IavQilMmLsP+DQSOYqttt94rblPxKq6ep3j41w8qK+CZl0wKPEaAY1OP aw/dHWWefDThh23zgTdlN0JM+8R+xHOPBtPHw1UlJxF0CgQbFqwpnwxPv INC8VKxtETLof4hbgUihPzeJx6XC9kd3v9HLFVxx2PkileimxhiPRmo9f U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvgAAHAuF05Io8UR/2dsb2JhbABTmBGPN3etF51whjgEh0qQCItG X-IronPort-AV: E=Sophos;i="4.65,500,1304294400"; d="scan'208";a="100386915" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-1.cisco.com with ESMTP; 08 Jul 2011 16:25:06 +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 p68GP5cs011591; Fri, 8 Jul 2011 16:25:05 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Jul 2011 21:55:05 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 8 Jul 2011 21:55:03 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD06F4FF83@XMB-BGL-417.cisco.com> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What does Start / Stop time attributes signify for Media Stream block ? [ was RE: [siprec] Comment on metadata-02 - Media Stream ] Thread-Index: Acw8qtezJdNopWF7RZqONH6e5tBRLgA3uo+Q References: From: "Ram Mohan R (rmohanr)" To: X-OriginalArrivalTime: 08 Jul 2011 16:25:05.0275 (UTC) FILETIME=[985AFCB0:01CC3D8B] Subject: [siprec] What does Start / Stop time attributes signify for Media Stream block ? [ was RE: Comment on metadata-02 - Media Stream ] X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 16:25:08 -0000 Hello John, Regarding your other question on Start/Stop time attribute in MS block The definition as per the current draft is: Start Time - Represents Media Start time at SRC. End Time - Represents Media End time at SRC. We had a long discussion couple of months back on the Start/Stop time attribute and what it means. It was a long thread with title " [siprec] start/stop times & the metamodel". I just went through the thread again to refresh my memory. It looks we *did not* reach to a *concrete* conclusion even though there were some general agreements. Refer to parts of mail thread here http://www.ietf.org/mail-archive/web/siprec/current/msg01850.html http://www.ietf.org/mail-archive/web/siprec/current/msg01814.html To summarize these are some of the salient points we discussed at that time: - the start time of a media stream is the time (according to the CS) of the first participant to a new media stream, and the stop time as the time that the last participant leaves the media stream. - There were discussions around how SRC derives this time (is it based on wall clock time of SRC e.t.c) - There was also discussions on what is the significance of start/stop time w.r.t different RTP models (translator, endpoint) and how SRS may want to use it for synchronization and playback Now would be a good time to re-start the discussion again so that we can conclude at least in IETF 81. Regards, Ram > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Elwell, John > Sent: Thursday, July 07, 2011 7:06 PM > To: siprec@ietf.org > Subject: [siprec] Comment on metadata-02 - Media Stream >=20 > In section 6.5, Media Stream seems to be defined as follows: > "A Media Stream block MUST have properties of media as seen by SRC and > sent to SRS." > Ignoring the possibly inappropriate RFC 2119 language, I don't think > this clearly defines whether: > a) this represents a medium of the CS (i.e., corresponding to a media > description in the CS SDP); or > b) this represents a medium of the RS (i.e., corresponding to a media > description in the RS SDP). >=20 > Both of these are "seen by SRC". There need not be a 1:1 relationship > between the two, and hence we need to make it clear which it > represents. >=20 > Although personally I had expected a), a couple of threads in recent > months have seemed to indicate b) is the general consensus. >=20 > Possibly a definition like: > "A Media Stream block represents a single RTP session between an SRC > and an SRS. Note that, because of possible mixing at the SRC, a Media > Stream block does not necessarily represent a single RTP session > between CS participants." >=20 > However, if we accept this principle, I wonder what the Start Time and > End Time attributes mean. The start and end of an RS RTP session > correspond to the relevant offer-answer exchanges, so they don't really > need to be in XML. So I suspect I still haven't drilled down into the > real meaning of MS sufficiently. >=20 > John (as individual) >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From rmohanr@cisco.com Fri Jul 8 09:29: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 290D421F8BBA for ; Fri, 8 Jul 2011 09:29:40 -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 74XT-zbWg-Ea for ; Fri, 8 Jul 2011 09:29:39 -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 A1B9D21F8BA6 for ; Fri, 8 Jul 2011 09:29:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=6799; q=dns/txt; s=iport; t=1310142580; x=1311352180; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=/YCQeq5pAQTIljKQTqZhbjJXL9wEn9e+CmBzoQ1r2Wg=; b=h7fYoDuvuDA7W0EzPx2uGqmoqmWfIftIbnyTO1abl4SArTaddOeDqu1e kL5Oy66/H+7Q06LXuNNph9GS5/oWBH6+tu2gnr7lOZKB5MkpolCwESfS+ zVM+ZxArn4Lp+u1IWr8hr1HYQJAQNsrtD4J82rFbtD4N4x2jIGxrCwVZD g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvgAAIMvF05Io8UT/2dsb2JhbABTmBGPN3etDJ1whjgEh0qQCItG X-IronPort-AV: E=Sophos;i="4.65,500,1304294400"; d="scan'208";a="41268027" Received: from bgl-core-4.cisco.com ([72.163.197.19]) by ams-iport-2.cisco.com with ESMTP; 08 Jul 2011 16:29: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 p68GTaf2023671; Fri, 8 Jul 2011 16:29:36 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Jul 2011 21:59: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: Fri, 8 Jul 2011 21:59:35 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD06F4FF85@XMB-BGL-417.cisco.com> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Comment on metadata-02 - Media Stream Thread-Index: Acw8qtezJdNopWF7RZqONH6e5tBRLgAAYkSAAB8nk4AABHr7gAAAZo/QAAucg6AACEOLMA== References: <07465C1D981ABC41A344374066AE1A2C38AFE9BB98@TLVMBX01.nice.com> <35BCE99A477D6A4986FB2216D8CF2CFD06F4FD89@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD06F4FE0B@XMB-BGL-417.cisco.com> From: "Ram Mohan R (rmohanr)" To: "Elwell, John" , "Leon Portman" , X-OriginalArrivalTime: 08 Jul 2011 16:29:36.0493 (UTC) FILETIME=[3A0391D0:01CC3D8C] Subject: Re: [siprec] Comment on metadata-02 - Media Stream X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 16:29:40 -0000 So I would combine and have the text for MS block as: " A Media Stream block represents a single RTP session between an SRC and an SRS. Note that, because of possible mixing at the SRC, a Media Stream block does not necessarily represent a single RTP session between CS participants. MS block helps to link participants ( of CS) to its associated Media Streams ( in RS), the properties of which will be carried in RS SDP" Please let me know if anyone has concerns otherwise I will incorporate this text in the next version of draft. Regards, Ram > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Friday, July 08, 2011 6:02 PM > To: Ram Mohan R (rmohanr); Leon Portman; siprec@ietf.org > Subject: RE: [siprec] Comment on metadata-02 - Media Stream >=20 > OK, sounds like a good compromise. >=20 > John >=20 > > -----Original Message----- > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > Sent: 08 July 2011 08:00 > > To: Elwell, John; Leon Portman; siprec@ietf.org > > Subject: RE: [siprec] Comment on metadata-02 - Media Stream > > > > John, > > > > I don't have any such issues with your definition. I think we > > can add " > > MS block helps to link participants ( of CS) to its associated Media > > Streams ( in RS), the properties of which will be carried in > > RS SDP" to > > your definition. > > > > I would like to have this line as it clearly says the > > intention /purpose > > of MS block. > > > > Regards, > > Ram > > > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > Sent: Friday, July 08, 2011 12:20 PM > > > To: Ram Mohan R (rmohanr); Leon Portman; siprec@ietf.org > > > Subject: RE: [siprec] Comment on metadata-02 - Media Stream > > > > > > Ram, > > > > > > In my opinion your proposed definition is too abstract - I think a > > > reader would have a hard time understanding what such an object > > > represents in the real world. Can you pinpoint your objections to > my > > > proposal? > > > > > > Thanks, > > > > > > John > > > > > > > > > > -----Original Message----- > > > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > > > Sent: 08 July 2011 05:59 > > > > To: Leon Portman; Elwell, John; siprec@ietf.org > > > > Subject: RE: [siprec] Comment on metadata-02 - Media Stream > > > > > > > > Hello John / Leon, > > > > > > > > Thanks for your comments on MS block in the metadata. I agree > that > > > the > > > > current text is little confusing. > > > > It is because when we started off with the metadata draft we > > intended > > > > that MS block represents properties of CS media. > > > > > > > > However after discussions we reached to a consensus that > > MS does not > > > > need to have CS media parameters. > > > > > > > > John's suggestion for definition is > > > > > > > > > Possibly a definition like: > > > > > "A Media Stream block represents a single RTP session between > an > > > SRC > > > > > and an SRS. Note that, because of possible mixing at the > > > > SRC, a Media > > > > > Stream block does not necessarily represent a single RTP > session > > > > > between CS participants." > > > > > > > > My suggestion is > > > > > > > > "An MS block/class represents an entity which helps to link > > > > participants > > > > ( of CS) to its associated Media Streams ( in RS), the > > properties of > > > > which will be carried in RS SDP". > > > > > > > > Please suggest if this text works fine. If not refine/suggest > > > > improvements. > > > > > > > > Regards, > > > > Ram > > > > > > > > > -----Original Message----- > > > > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On > > > > > Behalf Of Leon Portman > > > > > Sent: Thursday, July 07, 2011 7:20 PM > > > > > To: Elwell, John; siprec@ietf.org > > > > > Subject: Re: [siprec] Comment on metadata-02 - Media Stream > > > > > > > > > > Actually I was expecting (a) as well. And it should point to > the > > > > > relevant media lines in RS SDP. If two or more Media > > > > Streams point to > > > > > the same RS SDP m-line label, then we have mixing use case > > > > > > > > > > So something like this: CS MS (1:1)- > XML MS -> (N:1) -> RS > MS > > > > > > > > > > Leon > > > > > > > > > > -----Original Message----- > > > > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On > > > > > Behalf Of Elwell, John > > > > > Sent: Thursday, July 07, 2011 4:36 PM > > > > > To: siprec@ietf.org > > > > > Subject: [siprec] Comment on metadata-02 - Media Stream > > > > > > > > > > In section 6.5, Media Stream seems to be defined as follows: > > > > > "A Media Stream block MUST have properties of media as seen > > > > by SRC and > > > > > sent to SRS." > > > > > Ignoring the possibly inappropriate RFC 2119 language, I don't > > > think > > > > > this clearly defines whether: > > > > > a) this represents a medium of the CS (i.e., corresponding > > > > to a media > > > > > description in the CS SDP); or > > > > > b) this represents a medium of the RS (i.e., corresponding > > > > to a media > > > > > description in the RS SDP). > > > > > > > > > > Both of these are "seen by SRC". There need not be a 1:1 > > > > relationship > > > > > between the two, and hence we need to make it clear which it > > > > > represents. > > > > > > > > > > Although personally I had expected a), a couple of threads in > > > recent > > > > > months have seemed to indicate b) is the general consensus. > > > > > > > > > > Possibly a definition like: > > > > > "A Media Stream block represents a single RTP session between > an > > > SRC > > > > > and an SRS. Note that, because of possible mixing at the > > > > SRC, a Media > > > > > Stream block does not necessarily represent a single RTP > session > > > > > between CS participants." > > > > > > > > > > However, if we accept this principle, I wonder what the > > > > Start Time and > > > > > End Time attributes mean. The start and end of an RS RTP > session > > > > > correspond to the relevant offer-answer exchanges, so they > don't > > > > really > > > > > need to be in XML. So I suspect I still haven't drilled > > > > down into the > > > > > real meaning of MS sufficiently. > > > > > > > > > > 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 Fri Jul 8 10:31: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 CDBFC21F8B2B for ; Fri, 8 Jul 2011 10:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.479 X-Spam-Level: X-Spam-Status: No, score=-10.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 drcyXShQORcM for ; Fri, 8 Jul 2011 10:31: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 D2EA521F8B1E for ; Fri, 8 Jul 2011 10:31:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=3027; q=dns/txt; s=iport; t=1310146314; x=1311355914; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=hq5/Hk+R6pKwSi2sm9TnRvtqc34HgWlBIjalYpARRLw=; b=O/635dkvbEcxR0CQ3s5d0Pd0ATWU/6T5O3fOXNJXXSZ1ZOxfmd7uoqBg t3k4XR64AMBBDmgmukZ6UXJYSggpXJMfa9KkQ6ge6CzF0tmEYfrO4Me1y AF2u3rH17PFpUdNj8PI1oV6dZLk71Bj8C7oQZunN7oP/35dxAUT73Wv3g 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvgAAAM+F05Io8US/2dsb2JhbABUmBePN3eIe6NsnWSGOASHSpAIi0Y X-IronPort-AV: E=Sophos;i="4.65,500,1304294400"; d="scan'208";a="41273860" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-2.cisco.com with ESMTP; 08 Jul 2011 17:31:51 +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 p68HVoSI001854; Fri, 8 Jul 2011 17:31:50 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Jul 2011 23:01:51 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 8 Jul 2011 23:01:49 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD06F4FF9B@XMB-BGL-417.cisco.com> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Question on current speaker video Thread-Index: Acw8qvyln0YwIJofTL6nlIWCMtcIuQA5kaNA References: From: "Ram Mohan R (rmohanr)" To: "Elwell, John" , , "Charles Eckel (eckelcu)" X-OriginalArrivalTime: 08 Jul 2011 17:31:51.0027 (UTC) FILETIME=[EBF83C30:01CC3D94] Subject: Re: [siprec] Question on 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, 08 Jul 2011 17:31:54 -0000 Hi John, Please see inline for my comments. I am adding Charles to provide his comments here. > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Elwell, John > Sent: Thursday, July 07, 2011 7:07 PM > To: siprec@ietf.org > Subject: [siprec] Question on current speaker video >=20 > Consider a CS with a single video medium that is used by an MCU to show > the current speaker. All participants receive that medium. However, at > any one time only one participant is contributing to the medium. >=20 > Now suppose there is an SRC that sends that medium (unmixed with any > other medium) to an SRS. The metadata would represent this as a single > MS element. There would also be n Participant elements (assuming > sufficient information is available to the SRC). I assume that we would > simply say that all n Participants are contributing to that MS, and all > n Participants are recipients of that MS. Then there is no need to > update the metadata every time the speaker changes (which could be very > frequently). This could be modeled different ways depending on how we look at (whether MCU mixing or just selecting active speaker video).=20 In case the SRC is also the MCU, it will have the knowledge of which participant sent the video medium. So the model at *that* instance could like only one participant(active speaker) sending a MS and all n Participants receiving the MS.=20 P1 P2 ..Pn Recv ||sends |recv | recv MS MS MS=20 (video medium) In case the SRC is another user in the conference and just receives a medium from MCU it may not be able to find out the contributor directly ( without subscribing to Conf package).Assuming it learns, the model instance would be same as I mentioned above. I understand your concern on frequently updating the metadata every time a speaker changes. If we wish to avoid we would have to model it the way you said. In that case I would think we have to inform the active speaker through metadata at the least. I would like to hear from others if they are ok to not have the finer details( like current speaker) at SRS. >=20 > Similarly for an audio bridge that filters out all but the loudest > speaker or speakers. That could be signalled in RTP using > https://datatracker.ietf.org/doc/draft-ietf-avtext-mixer-to-client- > audio-level/, but would not be signalled by rapid updates of metadata. Here again the question is how the model would look. Will we have a single MS and say all Participants (P1.. Pn) sends it or just the Px ( loudest speaker) send it ? Regards, Ram >=20 > Can folks confirm this is a correct understanding? It might require > mention in the metadata draft, or possibly in the architecture draft. >=20 > John > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From pkyzivat@alum.mit.edu Fri Jul 8 12:09: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 93EDB21F8C60 for ; Fri, 8 Jul 2011 12:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=0.201, 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 c0-tdek12et5 for ; Fri, 8 Jul 2011 12:09:37 -0700 (PDT) Received: from qmta08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD0821F8C09 for ; Fri, 8 Jul 2011 12:09:36 -0700 (PDT) Received: from omta14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by qmta08.emeryville.ca.mail.comcast.net with comcast id 5X6X1h0051HpZEsA8X9akz; Fri, 08 Jul 2011 19:09:34 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta14.emeryville.ca.mail.comcast.net with comcast id 5X9Z1h0010tdiYw8aX9ZVA; Fri, 08 Jul 2011 19:09:34 +0000 Message-ID: <4E1755EE.9050700@alum.mit.edu> Date: Fri, 08 Jul 2011 15:09:34 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: siprec@ietf.org References: <35BCE99A477D6A4986FB2216D8CF2CFD06F4FF9B@XMB-BGL-417.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD06F4FF9B@XMB-BGL-417.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] Question on 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, 08 Jul 2011 19:09:37 -0000 Couldn't it also be the case that the metadata is as John described, but the RTP of the video changes SSRC according to who the video is from? (That then would leave the SRS with the problem of mapping SSRC to participant.) Thanks, Paul On 7/8/11 1:31 PM, Ram Mohan R (rmohanr) wrote: > Hi John, > > Please see inline for my comments. I am adding Charles to provide his > comments here. > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Elwell, John >> Sent: Thursday, July 07, 2011 7:07 PM >> To: siprec@ietf.org >> Subject: [siprec] Question on current speaker video >> >> Consider a CS with a single video medium that is used by an MCU to > show >> the current speaker. All participants receive that medium. However, at >> any one time only one participant is contributing to the medium. >> >> Now suppose there is an SRC that sends that medium (unmixed with any >> other medium) to an SRS. The metadata would represent this as a single >> MS element. There would also be n Participant elements (assuming >> sufficient information is available to the SRC). I assume that we > would >> simply say that all n Participants are contributing to that MS, and > all >> n Participants are recipients of that MS. Then there is no need to >> update the metadata every time the speaker changes (which could be > very >> frequently). > > > This could be modeled different ways depending on how we look at > (whether MCU mixing or just selecting active speaker video). > > In case the SRC is also the MCU, it will have the knowledge of which > participant sent the video medium. So the model at *that* instance could > like only one participant(active speaker) sending a MS and all n > Participants receiving the MS. > > P1 P2 ..Pn > Recv ||sends |recv | recv > MS MS MS > (video medium) > > In case the SRC is another user in the conference and just receives a > medium from MCU it may not be able to find out the contributor directly > ( without subscribing to Conf package).Assuming it learns, the model > instance would be same as I mentioned above. > > I understand your concern on frequently updating the metadata every time > a speaker changes. If we wish to avoid we would have to model it the way > you said. In that case I would think we have to inform the active > speaker through metadata at the least. I would like to hear from others > if they are ok to not have the finer details( like current speaker) at > SRS. > >> >> Similarly for an audio bridge that filters out all but the loudest >> speaker or speakers. That could be signalled in RTP using >> https://datatracker.ietf.org/doc/draft-ietf-avtext-mixer-to-client- >> audio-level/, but would not be signalled by rapid updates of metadata. > > > Here again the question is how the model would look. Will we have a > single MS and say all Participants (P1.. Pn) sends it or just the Px ( > loudest speaker) send it ? > > Regards, > Ram > >> >> Can folks confirm this is a correct understanding? It might require >> mention in the metadata draft, or possibly in the architecture draft. >> >> John >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From eckelcu@cisco.com Fri Jul 8 13:51: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 7801B21F8B59 for ; Fri, 8 Jul 2011 13:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.242 X-Spam-Level: X-Spam-Status: No, score=-5.242 tagged_above=-999 required=5 tests=[AWL=-2.643, 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 lpvpZn+Uee76 for ; Fri, 8 Jul 2011 13:51:43 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4CACB21F8B30 for ; Fri, 8 Jul 2011 13:51:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=4659; q=dns/txt; s=iport; t=1310158302; x=1311367902; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=mj7jS3ovHgItxyOa4l1IhJSdajRzqYGQIazYn/LvEQE=; b=F3ocnc3FYJ1LKp3ab6FDNpuCCTcGnQTd+EU75rLbqon9F8aJr93Ge0vX qCMBZwLEHZp7xEnXeZFA8i2hEpO8AHDZtNgQWCAdAs1Fd9/GDXO4G/EQJ WrXMEIuOGQubAccMFGPQsjxUhUfcF+bjju7fP2od2w/x83XhLqp0IZF6d E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAAJdtF06rRDoJ/2dsb2JhbABUEJgKjzR3rAOdWoY4BIdLkAaLB1c X-IronPort-AV: E=Sophos;i="4.65,500,1304294400"; d="scan'208";a="1183953" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-6.cisco.com with ESMTP; 08 Jul 2011 20:51:41 +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 p68KpeOZ003396; Fri, 8 Jul 2011 20:51:41 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, 8 Jul 2011 13:51: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: Fri, 8 Jul 2011 13:50:44 -0700 Message-ID: In-Reply-To: <4E1755EE.9050700@alum.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [siprec] Question on current speaker video thread-index: Acw9oplJimIdo1PlR/2t7fm/WxWkXQADSrjg References: <35BCE99A477D6A4986FB2216D8CF2CFD06F4FF9B@XMB-BGL-417.cisco.com> <4E1755EE.9050700@alum.mit.edu> From: "Charles Eckel (eckelcu)" To: "Paul Kyzivat" , X-OriginalArrivalTime: 08 Jul 2011 20:51:40.0887 (UTC) FILETIME=[D67BAE70:01CC3DB0] Subject: Re: [siprec] Question on 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, 08 Jul 2011 20:51:47 -0000 I agree. RTP/RTCP already provides an efficient mechanism for this, and I think we should use it rather than modeling in such a way that it forced a metadata change every time the active speaker changes. I suppose the model itself should be, and is, flexible enough to allow one to represent such a case as a single MS with 'n' participants, or 'n' MSs each with a single participant; but I expect the former to be a much more common implementation approach. Cheers, Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Friday, July 08, 2011 12:10 PM > To: siprec@ietf.org > Subject: Re: [siprec] Question on current speaker video >=20 > Couldn't it also be the case that the metadata is as John described, but > the RTP of the video changes SSRC according to who the video is from? >=20 > (That then would leave the SRS with the problem of mapping SSRC to > participant.) >=20 > Thanks, > Paul >=20 >=20 > On 7/8/11 1:31 PM, Ram Mohan R (rmohanr) wrote: > > Hi John, > > > > Please see inline for my comments. I am adding Charles to provide his > > comments here. > > > >> -----Original Message----- > >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >> Behalf Of Elwell, John > >> Sent: Thursday, July 07, 2011 7:07 PM > >> To: siprec@ietf.org > >> Subject: [siprec] Question on current speaker video > >> > >> Consider a CS with a single video medium that is used by an MCU to > > show > >> the current speaker. All participants receive that medium. However, at > >> any one time only one participant is contributing to the medium. > >> > >> Now suppose there is an SRC that sends that medium (unmixed with any > >> other medium) to an SRS. The metadata would represent this as a single > >> MS element. There would also be n Participant elements (assuming > >> sufficient information is available to the SRC). I assume that we > > would > >> simply say that all n Participants are contributing to that MS, and > > all > >> n Participants are recipients of that MS. Then there is no need to > >> update the metadata every time the speaker changes (which could be > > very > >> frequently). > > > > > > This could be modeled different ways depending on how we look at > > (whether MCU mixing or just selecting active speaker video). > > > > In case the SRC is also the MCU, it will have the knowledge of which > > participant sent the video medium. So the model at *that* instance could > > like only one participant(active speaker) sending a MS and all n > > Participants receiving the MS. > > > > P1 P2 ..Pn > > Recv ||sends |recv | recv > > MS MS MS > > (video medium) > > > > In case the SRC is another user in the conference and just receives a > > medium from MCU it may not be able to find out the contributor directly > > ( without subscribing to Conf package).Assuming it learns, the model > > instance would be same as I mentioned above. > > > > I understand your concern on frequently updating the metadata every time > > a speaker changes. If we wish to avoid we would have to model it the way > > you said. In that case I would think we have to inform the active > > speaker through metadata at the least. I would like to hear from others > > if they are ok to not have the finer details( like current speaker) at > > SRS. > > > >> > >> Similarly for an audio bridge that filters out all but the loudest > >> speaker or speakers. That could be signalled in RTP using > >> https://datatracker.ietf.org/doc/draft-ietf-avtext-mixer-to-client- > >> audio-level/, but would not be signalled by rapid updates of metadata. > > > > > > Here again the question is how the model would look. Will we have a > > single MS and say all Participants (P1.. Pn) sends it or just the Px ( > > loudest speaker) send it ? > > > > Regards, > > Ram > > > >> > >> Can folks confirm this is a correct understanding? It might require > >> mention in the metadata draft, or possibly in the architecture draft. > >> > >> John > >> _______________________________________________ > >> siprec mailing list > >> siprec@ietf.org > >> https://www.ietf.org/mailman/listinfo/siprec > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > > >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From rmohanr@cisco.com Fri Jul 8 19:05: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 585029E802E for ; Fri, 8 Jul 2011 19:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.49 X-Spam-Level: X-Spam-Status: No, score=-10.49 tagged_above=-999 required=5 tests=[AWL=0.109, 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 iHqVz584fLcC for ; Fri, 8 Jul 2011 19:05:24 -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 C87689E802C for ; Fri, 8 Jul 2011 19:05:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=5511; q=dns/txt; s=iport; t=1310177123; x=1311386723; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=dJrI5dwm+Jhdl7wd5lX+WxfTFM8+mcj2du25YOXj7YI=; b=DsIfbmQ9HdA5ONacq8+rDn6Z92g4AsT5yf5g7Bpq/bfGlASouKW99iuR koOy6v42GKMnXw/kS0Gv0nFXgIO91tOoACeBm7gl2o8xnk4ukIygZhG0C fcMDO9XzZLKeoO+L63iJU8y63gOdQ8ru0bJ9WO4E9SlgUqfi44CBiFg9i c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAALK2F05Io8US/2dsb2JhbABTEJgKjzR3qzmdToY4BIdJkAiLBz8 X-IronPort-AV: E=Sophos;i="4.65,501,1304294400"; d="scan'208";a="41306848" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-2.cisco.com with ESMTP; 09 Jul 2011 02:05:21 +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 p6925L0s000514; Sat, 9 Jul 2011 02:05:21 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 9 Jul 2011 07:35:21 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Sat, 9 Jul 2011 07:35:14 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD06F4FFD1@XMB-BGL-417.cisco.com> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Question on current speaker video Thread-Index: Acw9oplJimIdo1PlR/2t7fm/WxWkXQADSrjgAAsahsA= References: <35BCE99A477D6A4986FB2216D8CF2CFD06F4FF9B@XMB-BGL-417.cisco.com><4E1755EE.9050700@alum.mit.edu> From: "Ram Mohan R (rmohanr)" To: "Charles Eckel (eckelcu)" , "Paul Kyzivat" , X-OriginalArrivalTime: 09 Jul 2011 02:05:21.0556 (UTC) FILETIME=[A879DD40:01CC3DDC] Subject: Re: [siprec] Question on 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: Sat, 09 Jul 2011 02:05:25 -0000 Charles, I do agree that RTP/RTCP has mechanisms for the same. I am fine with this approach in case everyone agrees. Regards, Ram > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Charles Eckel (eckelcu) > Sent: Saturday, July 09, 2011 2:21 AM > To: Paul Kyzivat; siprec@ietf.org > Subject: Re: [siprec] Question on current speaker video >=20 > I agree. RTP/RTCP already provides an efficient mechanism for this, and > I think we should use it rather than modeling in such a way that it > forced a metadata change every time the active speaker changes. I > suppose the model itself should be, and is, flexible enough to allow > one > to represent such a case as a single MS with 'n' participants, or 'n' > MSs each with a single participant; but I expect the former to be a > much > more common implementation approach. >=20 > Cheers, > Charles >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Paul Kyzivat > > Sent: Friday, July 08, 2011 12:10 PM > > To: siprec@ietf.org > > Subject: Re: [siprec] Question on current speaker video > > > > Couldn't it also be the case that the metadata is as John described, > but > > the RTP of the video changes SSRC according to who the video is from? > > > > (That then would leave the SRS with the problem of mapping SSRC to > > participant.) > > > > Thanks, > > Paul > > > > > > On 7/8/11 1:31 PM, Ram Mohan R (rmohanr) wrote: > > > Hi John, > > > > > > Please see inline for my comments. I am adding Charles to provide > his > > > comments here. > > > > > >> -----Original Message----- > > >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > >> Behalf Of Elwell, John > > >> Sent: Thursday, July 07, 2011 7:07 PM > > >> To: siprec@ietf.org > > >> Subject: [siprec] Question on current speaker video > > >> > > >> Consider a CS with a single video medium that is used by an MCU to > > > show > > >> the current speaker. All participants receive that medium. > However, > at > > >> any one time only one participant is contributing to the medium. > > >> > > >> Now suppose there is an SRC that sends that medium (unmixed with > any > > >> other medium) to an SRS. The metadata would represent this as a > single > > >> MS element. There would also be n Participant elements (assuming > > >> sufficient information is available to the SRC). I assume that we > > > would > > >> simply say that all n Participants are contributing to that MS, > and > > > all > > >> n Participants are recipients of that MS. Then there is no need to > > >> update the metadata every time the speaker changes (which could be > > > very > > >> frequently). > > > > > > > > > This could be modeled different ways depending on how we look at > > > (whether MCU mixing or just selecting active speaker video). > > > > > > In case the SRC is also the MCU, it will have the knowledge of > which > > > participant sent the video medium. So the model at *that* instance > could > > > like only one participant(active speaker) sending a MS and all n > > > Participants receiving the MS. > > > > > > P1 P2 ..Pn > > > Recv ||sends |recv | recv > > > MS MS MS > > > (video medium) > > > > > > In case the SRC is another user in the conference and just receives > a > > > medium from MCU it may not be able to find out the contributor > directly > > > ( without subscribing to Conf package).Assuming it learns, the > model > > > instance would be same as I mentioned above. > > > > > > I understand your concern on frequently updating the metadata every > time > > > a speaker changes. If we wish to avoid we would have to model it > the > way > > > you said. In that case I would think we have to inform the active > > > speaker through metadata at the least. I would like to hear from > others > > > if they are ok to not have the finer details( like current speaker) > at > > > SRS. > > > > > >> > > >> Similarly for an audio bridge that filters out all but the loudest > > >> speaker or speakers. That could be signalled in RTP using > > >> https://datatracker.ietf.org/doc/draft-ietf-avtext-mixer-to- > client- > > >> audio-level/, but would not be signalled by rapid updates of > metadata. > > > > > > > > > Here again the question is how the model would look. Will we have a > > > single MS and say all Participants (P1.. Pn) sends it or just the > Px > ( > > > loudest speaker) send it ? > > > > > > Regards, > > > Ram > > > > > >> > > >> Can folks confirm this is a correct understanding? It might > require > > >> mention in the metadata draft, or possibly in the architecture > draft. > > >> > > >> John > > >> _______________________________________________ > > >> siprec mailing list > > >> siprec@ietf.org > > >> https://www.ietf.org/mailman/listinfo/siprec > > > _______________________________________________ > > > siprec mailing list > > > siprec@ietf.org > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From internet-drafts@ietf.org Sat Jul 9 09:15: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 9090921F88AF; Sat, 9 Jul 2011 09:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.289 X-Spam-Level: X-Spam-Status: No, score=-102.289 tagged_above=-999 required=5 tests=[AWL=0.310, 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 1dNcfD3OTE+F; Sat, 9 Jul 2011 09:15:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07D8D21F88A5; Sat, 9 Jul 2011 09:15:29 -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: <20110709161529.3715.64641.idtracker@ietfa.amsl.com> Date: Sat, 09 Jul 2011 09:15:29 -0700 Cc: siprec@ietf.org Subject: [siprec] I-D Action: draft-ietf-siprec-metadata-03.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: Sat, 09 Jul 2011 16:15:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP Recording Working Group of the IE= TF. Title : Session Initiation Protocol (SIP) Recording Metadata Author(s) : Ram Mohan Ravindranath Parthasarathi Ravindran Paul Kyzivat Filename : draft-ietf-siprec-metadata-03.txt Pages : 34 Date : 2011-07-09 Session recording is a critical requirement in many communications environments such as call centers and financial trading. In some of these environments, all calls must be recorded for regulatory, compliance, and consumer protection reasons. Recording of a session is typically performed by sending a copy of a media stream to a recording device. This document describes the metadata model as viewed by Session Recording Server(SRS) and the Recording metadata format. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-siprec-metadata-03.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-metadata-03.txt From Leon.Portman@nice.com Sun Jul 10 00:50: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 D463F21F88AC for ; Sun, 10 Jul 2011 00:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 r8fmVUPhRaxb for ; Sun, 10 Jul 2011 00:50:08 -0700 (PDT) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id 49AD121F889F for ; Sun, 10 Jul 2011 00:50:06 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.15]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Sun, 10 Jul 2011 10:50:04 +0300 From: Leon Portman To: "Elwell, John" , "Ram Mohan R (rmohanr)" , "siprec@ietf.org" Date: Sun, 10 Jul 2011 10:50:03 +0300 Thread-Topic: [siprec] Comment on metadata-02 - Media Stream Thread-Index: Acw8qtezJdNopWF7RZqONH6e5tBRLgAAYkSAAB8nk4AABHr7gAAAZo/QAAucg6AAWrlmsA== Message-ID: <07465C1D981ABC41A344374066AE1A2C38B006A890@TLVMBX01.nice.com> References: <07465C1D981ABC41A344374066AE1A2C38AFE9BB98@TLVMBX01.nice.com> <35BCE99A477D6A4986FB2216D8CF2CFD06F4FD89@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD06F4FE0B@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] Comment on metadata-02 - Media Stream X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jul 2011 07:50:09 -0000 Sound good to me as well. May be we should say "to link participant media"? Leon -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 Sent: Friday, July 08, 2011 3:32 PM To: Ram Mohan R (rmohanr); Leon Portman; siprec@ietf.org Subject: RE: [siprec] Comment on metadata-02 - Media Stream OK, sounds like a good compromise. John=20 > -----Original Message----- > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > Sent: 08 July 2011 08:00 > To: Elwell, John; Leon Portman; siprec@ietf.org > Subject: RE: [siprec] Comment on metadata-02 - Media Stream >=20 > John, >=20 > I don't have any such issues with your definition. I think we can add=20 > " > MS block helps to link participants ( of CS) to its associated Media=20 > Streams ( in RS), the properties of which will be carried in RS SDP"=20 > to your definition. >=20 > I would like to have this line as it clearly says the intention=20 > /purpose of MS block. >=20 > Regards, > Ram >=20 > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Friday, July 08, 2011 12:20 PM > > To: Ram Mohan R (rmohanr); Leon Portman; siprec@ietf.org > > Subject: RE: [siprec] Comment on metadata-02 - Media Stream > >=20 > > Ram, > >=20 > > In my opinion your proposed definition is too abstract - I think a=20 > > reader would have a hard time understanding what such an object=20 > > represents in the real world. Can you pinpoint your objections to my=20 > > proposal? > >=20 > > Thanks, > >=20 > > John > >=20 > >=20 > > > -----Original Message----- > > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > > Sent: 08 July 2011 05:59 > > > To: Leon Portman; Elwell, John; siprec@ietf.org > > > Subject: RE: [siprec] Comment on metadata-02 - Media Stream > > > > > > Hello John / Leon, > > > > > > Thanks for your comments on MS block in the metadata. I agree that > > the > > > current text is little confusing. > > > It is because when we started off with the metadata draft we > intended > > > that MS block represents properties of CS media. > > > > > > However after discussions we reached to a consensus that > MS does not > > > need to have CS media parameters. > > > > > > John's suggestion for definition is > > > > > > > Possibly a definition like: > > > > "A Media Stream block represents a single RTP session between an > > SRC > > > > and an SRS. Note that, because of possible mixing at the > > > SRC, a Media > > > > Stream block does not necessarily represent a single RTP session=20 > > > > between CS participants." > > > > > > My suggestion is > > > > > > "An MS block/class represents an entity which helps to link=20 > > > participants ( of CS) to its associated Media Streams ( in RS),=20 > > > the > properties of > > > which will be carried in RS SDP". > > > > > > Please suggest if this text works fine. If not refine/suggest=20 > > > improvements. > > > > > > Regards, > > > Ram > > > > > > > -----Original Message----- > > > > From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On > > > > Behalf Of Leon Portman > > > > Sent: Thursday, July 07, 2011 7:20 PM > > > > To: Elwell, John; siprec@ietf.org > > > > Subject: Re: [siprec] Comment on metadata-02 - Media Stream > > > > > > > > Actually I was expecting (a) as well. And it should point to the=20 > > > > relevant media lines in RS SDP. If two or more Media > > > Streams point to > > > > the same RS SDP m-line label, then we have mixing use case > > > > > > > > So something like this: CS MS (1:1)- > XML MS -> (N:1) -> RS MS > > > > > > > > Leon > > > > > > > > -----Original Message----- > > > > From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On > > > > Behalf Of Elwell, John > > > > Sent: Thursday, July 07, 2011 4:36 PM > > > > To: siprec@ietf.org > > > > Subject: [siprec] Comment on metadata-02 - Media Stream > > > > > > > > In section 6.5, Media Stream seems to be defined as follows: > > > > "A Media Stream block MUST have properties of media as seen > > > by SRC and > > > > sent to SRS." > > > > Ignoring the possibly inappropriate RFC 2119 language, I don't > > think > > > > this clearly defines whether: > > > > a) this represents a medium of the CS (i.e., corresponding > > > to a media > > > > description in the CS SDP); or > > > > b) this represents a medium of the RS (i.e., corresponding > > > to a media > > > > description in the RS SDP). > > > > > > > > Both of these are "seen by SRC". There need not be a 1:1 > > > relationship > > > > between the two, and hence we need to make it clear which it=20 > > > > represents. > > > > > > > > Although personally I had expected a), a couple of threads in > > recent > > > > months have seemed to indicate b) is the general consensus. > > > > > > > > Possibly a definition like: > > > > "A Media Stream block represents a single RTP session between an > > SRC > > > > and an SRS. Note that, because of possible mixing at the > > > SRC, a Media > > > > Stream block does not necessarily represent a single RTP session=20 > > > > between CS participants." > > > > > > > > However, if we accept this principle, I wonder what the > > > Start Time and > > > > End Time attributes mean. The start and end of an RS RTP session=20 > > > > correspond to the relevant offer-answer exchanges, so they don't > > > really > > > > need to be in XML. So I suspect I still haven't drilled > > > down into the > > > > real meaning of MS sufficiently. > > > > > > > > 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 > > > >=20 From Leon.Portman@nice.com Sun Jul 10 00:53: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 14D9821F890B for ; Sun, 10 Jul 2011 00:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.16 X-Spam-Level: X-Spam-Status: No, score=-2.16 tagged_above=-999 required=5 tests=[AWL=-0.162, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_53=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 2HABOd5UKSjB for ; Sun, 10 Jul 2011 00:53:00 -0700 (PDT) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id 68AFF21F88B0 for ; Sun, 10 Jul 2011 00:52:59 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.15]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Sun, 10 Jul 2011 10:52:58 +0300 From: Leon Portman To: "Ram Mohan R (rmohanr)" , "siprec@ietf.org" Date: Sun, 10 Jul 2011 10:52:57 +0300 Thread-Topic: [siprec] CSG start & stop time attribute requirement Thread-Index: Acw0kGxvAtp8hudRQFqbSwPv+BTXsQARfy2AAiwW7rAAU+aocA== Message-ID: <07465C1D981ABC41A344374066AE1A2C38B006A896@TLVMBX01.nice.com> References: <35BCE99A477D6A4986FB2216D8CF2CFD06D3323D@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD06F4FF7F@XMB-BGL-417.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD06F4FF7F@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: multipart/alternative; boundary="_000_07465C1D981ABC41A344374066AE1A2C38B006A896TLVMBX01nicec_" MIME-Version: 1.0 Subject: Re: [siprec] CSG start & stop time attribute requirement X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jul 2011 07:53:01 -0000 --_000_07465C1D981ABC41A344374066AE1A2C38B006A896TLVMBX01nicec_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am ok Leon From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Ram Mohan R (rmohanr) Sent: Friday, July 08, 2011 6:51 PM To: siprec@ietf.org Subject: Re: [siprec] CSG start & stop time attribute requirement I have not heard back any comments on this. Can people let us know your tho= ughts on having Start/Stop time attribute for CSG block ? Regards, Ram From: siprec-bounces@ietf.org [mailto:sipre= c-bounces@ietf.org] On Behalf Of R= am Mohan R (rmohanr) Sent: Monday, June 27, 2011 8:33 PM To: Parthasarathi R (partr); siprec@ietf.org Subject: Re: [siprec] CSG start & stop time attribute requirement To add more to what Partha has mentioned another use case is when multiple = RSs are used for recording a CSG it is easy to determine start/ Stop time w= hen explicitly indicated in CSG. So I would prefer to have Start/ Stop time explicitly indicated in CS-Group= and which would indicate when a Group Starts/ End. Ram From: siprec-bounces@ietf.org [mailto:sipre= c-bounces@ietf.org] On Behalf Of P= arthasarathi R (partr) Sent: Monday, June 27, 2011 11:37 AM To: siprec@ietf.org Subject: [siprec] CSG start & stop time attribute requirement Hi all, As per interim meeting, there is a need to explain the reason for having st= art/stop time in CSG group. Two reasons for having this attribute: 1) BYE will serve the purpose in case CSG is within single RS or ending at = the end of some RS. In case CSG is terminated in the middle of RS session (= persistent session), there is a need of an attribute. As it is middle of t= he RS, it is better to have the exact time. 2) In case partial-update of metadata format, there is an need of XML eleme= nt to indicate the termination of CSG ("group") element. It shall be achiev= ed by "stop-time" element within CSG. Thanks Partha Note: Topic - Metadata model(Ram Mohan) draft-ietf-siprec-metadata-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-ietf-siprec-metadata/ Slides: http://trac.tools.ietf.org/wg/siprec/trac/attachment/wiki/WikiStart= /SIPREC%20Metamodel%20-%20Virtual%20Interim-23Jun_2011.pptx Side 5: On the issue of whether a CSG element needs a start/stop time, Ram = explained that the information could be derived from the start/stop times o= f the CSs that form part of that group (although he was concerned about the= complications of overlapping CSs), or could be explicitly indicated for th= e group. Leon and John thought that implicit should be sufficient. Partha t= ried to express a point concerning termination of a CSG, but this needs to = be raised on the list. --_000_07465C1D981ABC41A344374066AE1A2C38B006A896TLVMBX01nicec_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am ok

 

Leon

 

<= span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From: = siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Ram Mohan R (rmohanr)
Sent: Friday, July 08, 2011 6:51 PM
To: siprec@ietf.org
Subject: Re: [siprec] CSG start & st= op time attribute requirement

 

I have not heard = back any comments on this. Can people let us know your thoughts on having S= tart/Stop time attribute for CSG block ?

 

Rega= rds,

Ram=

From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Ram Mohan R (rmohanr)
Sent: Monday, June 27, 2011 8:33 PMTo: Parthasarathi R (partr); sip= rec@ietf.org
Subject: Re: [siprec] CSG start & stop time = attribute requirement

 

To add more to what Parth= a has mentioned another use case is when multiple RSs are used for recordin= g a CSG it is easy to determine start/ Stop time when explicitly indicated = in CSG.

So I would prefer = to have Start/ Stop time explicitly indicated in CS-Group and which would i= ndicate when a Group Starts/ End.

 

Ram

 

From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Part= hasarathi R (partr)
Sent: Monday, June 27, 2011 11:37 AM
To= : siprec@ietf.org
Subject:= [siprec] CSG start & stop time attribute requirement

 

Hi all,

 

As per interim meeting, there is a need t= o explain the reason for having start/stop time in CSG group. Two = ;reasons for having this attribute:

 

1) BYE will serve= the purpose in case CSG is within single RS or ending at the end of some R= S. In case CSG is terminated in the middle of RS session (persistent sessio= n), there is a need of an attribute.  As it is middle of the RS, it is= better to have the exact time.

 

2) In case partial-u= pdate of metadata format, there is an need of XML element to indicate the t= ermination of CSG ("group") element. It shall be achieved by= "stop-time" element within CSG.

=

 

<= span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>Thanks

Partha

=

 

Note:=

Topic - Metadata model(Ram Mohan)=

draft-ietf-siprec-metadata-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-ietf-siprec-metadata/

Slides: <= /span>http://trac.tools.ietf.org/wg/siprec/trac/attachment/wiki/WikiStart/SIPRE= C%20Metamodel%20-%20Virtual%20Interim-23Jun_2011.pptx=

Side 5: On the issue of whether a CSG element needs a start/= stop time, Ram explained that the information could be derived from the sta= rt/stop times of the CSs that form part of that group (although he was conc= erned about the complications of overlapping CSs), or could be explicitly i= ndicated for the group. Leon and John thought that implicit should be suffi= cient. Partha tried to express a point concerning termination of a CSG, but= this needs to be raised on the list.

= --_000_07465C1D981ABC41A344374066AE1A2C38B006A896TLVMBX01nicec_-- From Leon.Portman@nice.com Sun Jul 10 00:57: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 A1ABF21F86ED for ; Sun, 10 Jul 2011 00:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 Dz7aV-A7W6qO for ; Sun, 10 Jul 2011 00:57:54 -0700 (PDT) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id 481D021F86EC for ; Sun, 10 Jul 2011 00:57:54 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.15]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Sun, 10 Jul 2011 10:57:47 +0300 From: Leon Portman To: "Ram Mohan R (rmohanr)" , "Elwell, John" , "siprec@ietf.org" Date: Sun, 10 Jul 2011 10:57:46 +0300 Thread-Topic: [siprec] Comment on metadata-02 - Media Stream Thread-Index: Acw8qtezJdNopWF7RZqONH6e5tBRLgAAYkSAAB8nk4AABHr7gAAAZo/QAAucg6AACEOLMABSr+wA Message-ID: <07465C1D981ABC41A344374066AE1A2C38B006A89D@TLVMBX01.nice.com> References: <07465C1D981ABC41A344374066AE1A2C38AFE9BB98@TLVMBX01.nice.com> <35BCE99A477D6A4986FB2216D8CF2CFD06F4FD89@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD06F4FE0B@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD06F4FF85@XMB-BGL-417.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD06F4FF85@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] Comment on metadata-02 - Media Stream X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jul 2011 07:57:55 -0000 Ram Hi But do we want to link participant to RS media or Participant media to RS m= edia? What will be the logic to reconstruct participant media sessions ( I = am not talking about codecs and ports but types of the media for example). = Specially ones that are not recorded or offered. I remember that we had dis= cussion to support it. Regards Leon -----Original Message----- From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com]=20 Sent: Friday, July 08, 2011 7:30 PM To: Elwell, John; Leon Portman; siprec@ietf.org Subject: RE: [siprec] Comment on metadata-02 - Media Stream So I would combine and have the text for MS block as: " A Media Stream block represents a single RTP session between an SRC and a= n SRS. Note that, because of possible mixing at the SRC, a Media Stream blo= ck does not necessarily represent a single RTP session between CS participa= nts. MS block helps to link participants ( of CS) to its associated Media S= treams ( in RS), the properties of which will be carried in RS SDP" Please let me know if anyone has concerns otherwise I will incorporate this= text in the next version of draft. Regards, Ram > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Friday, July 08, 2011 6:02 PM > To: Ram Mohan R (rmohanr); Leon Portman; siprec@ietf.org > Subject: RE: [siprec] Comment on metadata-02 - Media Stream >=20 > OK, sounds like a good compromise. >=20 > John >=20 > > -----Original Message----- > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > Sent: 08 July 2011 08:00 > > To: Elwell, John; Leon Portman; siprec@ietf.org > > Subject: RE: [siprec] Comment on metadata-02 - Media Stream > > > > John, > > > > I don't have any such issues with your definition. I think we can=20 > > add " > > MS block helps to link participants ( of CS) to its associated Media=20 > > Streams ( in RS), the properties of which will be carried in RS SDP"=20 > > to your definition. > > > > I would like to have this line as it clearly says the intention=20 > > /purpose of MS block. > > > > Regards, > > Ram > > > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > Sent: Friday, July 08, 2011 12:20 PM > > > To: Ram Mohan R (rmohanr); Leon Portman; siprec@ietf.org > > > Subject: RE: [siprec] Comment on metadata-02 - Media Stream > > > > > > Ram, > > > > > > In my opinion your proposed definition is too abstract - I think a=20 > > > reader would have a hard time understanding what such an object=20 > > > represents in the real world. Can you pinpoint your objections to > my > > > proposal? > > > > > > Thanks, > > > > > > John > > > > > > > > > > -----Original Message----- > > > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > > > Sent: 08 July 2011 05:59 > > > > To: Leon Portman; Elwell, John; siprec@ietf.org > > > > Subject: RE: [siprec] Comment on metadata-02 - Media Stream > > > > > > > > Hello John / Leon, > > > > > > > > Thanks for your comments on MS block in the metadata. I agree > that > > > the > > > > current text is little confusing. > > > > It is because when we started off with the metadata draft we > > intended > > > > that MS block represents properties of CS media. > > > > > > > > However after discussions we reached to a consensus that > > MS does not > > > > need to have CS media parameters. > > > > > > > > John's suggestion for definition is > > > > > > > > > Possibly a definition like: > > > > > "A Media Stream block represents a single RTP session between > an > > > SRC > > > > > and an SRS. Note that, because of possible mixing at the > > > > SRC, a Media > > > > > Stream block does not necessarily represent a single RTP > session > > > > > between CS participants." > > > > > > > > My suggestion is > > > > > > > > "An MS block/class represents an entity which helps to link=20 > > > > participants ( of CS) to its associated Media Streams ( in RS),=20 > > > > the > > properties of > > > > which will be carried in RS SDP". > > > > > > > > Please suggest if this text works fine. If not refine/suggest=20 > > > > improvements. > > > > > > > > Regards, > > > > Ram > > > > > > > > > -----Original Message----- > > > > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On > > > > > Behalf Of Leon Portman > > > > > Sent: Thursday, July 07, 2011 7:20 PM > > > > > To: Elwell, John; siprec@ietf.org > > > > > Subject: Re: [siprec] Comment on metadata-02 - Media Stream > > > > > > > > > > Actually I was expecting (a) as well. And it should point to > the > > > > > relevant media lines in RS SDP. If two or more Media > > > > Streams point to > > > > > the same RS SDP m-line label, then we have mixing use case > > > > > > > > > > So something like this: CS MS (1:1)- > XML MS -> (N:1) -> RS > MS > > > > > > > > > > Leon > > > > > > > > > > -----Original Message----- > > > > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On > > > > > Behalf Of Elwell, John > > > > > Sent: Thursday, July 07, 2011 4:36 PM > > > > > To: siprec@ietf.org > > > > > Subject: [siprec] Comment on metadata-02 - Media Stream > > > > > > > > > > In section 6.5, Media Stream seems to be defined as follows: > > > > > "A Media Stream block MUST have properties of media as seen > > > > by SRC and > > > > > sent to SRS." > > > > > Ignoring the possibly inappropriate RFC 2119 language, I don't > > > think > > > > > this clearly defines whether: > > > > > a) this represents a medium of the CS (i.e., corresponding > > > > to a media > > > > > description in the CS SDP); or > > > > > b) this represents a medium of the RS (i.e., corresponding > > > > to a media > > > > > description in the RS SDP). > > > > > > > > > > Both of these are "seen by SRC". There need not be a 1:1 > > > > relationship > > > > > between the two, and hence we need to make it clear which it=20 > > > > > represents. > > > > > > > > > > Although personally I had expected a), a couple of threads in > > > recent > > > > > months have seemed to indicate b) is the general consensus. > > > > > > > > > > Possibly a definition like: > > > > > "A Media Stream block represents a single RTP session between > an > > > SRC > > > > > and an SRS. Note that, because of possible mixing at the > > > > SRC, a Media > > > > > Stream block does not necessarily represent a single RTP > session > > > > > between CS participants." > > > > > > > > > > However, if we accept this principle, I wonder what the > > > > Start Time and > > > > > End Time attributes mean. The start and end of an RS RTP > session > > > > > correspond to the relevant offer-answer exchanges, so they > don't > > > > really > > > > > need to be in XML. So I suspect I still haven't drilled > > > > down into the > > > > > real meaning of MS sufficiently. > > > > > > > > > > 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 Sun Jul 10 02:02: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 C780021F85CD for ; Sun, 10 Jul 2011 02:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.298 X-Spam-Level: X-Spam-Status: No, score=-10.298 tagged_above=-999 required=5 tests=[AWL=0.301, 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 Q-hH6CZXKSxw for ; Sun, 10 Jul 2011 02:02: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 2B26C21F85CF for ; Sun, 10 Jul 2011 02:02:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=8711; q=dns/txt; s=iport; t=1310288524; x=1311498124; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=1pqwBTUhr10q0G/FzyUwGm4PfUQN6fBiNFz+q9wmXy8=; b=Q1p9fkntxyOFwi78FmZXxAdadkZ4e9wqMTjV7HvMnA/+/k370RXbdenC PvXbwcD+7StisY65dkoyfOqw7kGus1ifIcektTnMqdkPDsIGX/miIMFcK ot7Ih3HWOAGHSJ02J6KDgryAEmaajkBfCIK9MijmJDplnnnR41tPxErR1 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUBAH9pGU5Io8US/2dsb2JhbABTmB6PNnescJ0MhVtfBIdMkA+LSA X-IronPort-AV: E=Sophos;i="4.65,507,1304294400"; d="scan'208";a="41402023" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-2.cisco.com with ESMTP; 10 Jul 2011 09:02:01 +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 p6A9206q030576; Sun, 10 Jul 2011 09:02:00 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); Sun, 10 Jul 2011 14:32: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: Sun, 10 Jul 2011 14:31:59 +0530 Message-ID: In-Reply-To: <07465C1D981ABC41A344374066AE1A2C38B006A89D@TLVMBX01.nice.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Comment on metadata-02 - Media Stream Thread-Index: Acw8qtezJdNopWF7RZqONH6e5tBRLgAAYkSAAB8nk4AABHr7gAAAZo/QAAucg6AACEOLMABSr+wAAAIIyiA= References: <07465C1D981ABC41A344374066AE1A2C38AFE9BB98@TLVMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD06F4FD89@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD06F4FE0B@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD06F4FF85@XMB-BGL-417.cisco.com> <07465C1D981ABC41A344374066AE1A2C38B006A89D@TLVMBX01.nice.com> From: "Parthasarathi R (partr)" To: "Leon Portman" , "Ram Mohan R (rmohanr)" , "Elwell, John" , X-OriginalArrivalTime: 10 Jul 2011 09:02:00.0306 (UTC) FILETIME=[074E2520:01CC3EE0] Subject: Re: [siprec] Comment on metadata-02 - Media Stream X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jul 2011 09:02:05 -0000 Leon, As you mentioned, it is possible to indicate special case of "not recorded" through RS SDP as port value containing 0 in the media ("m=3D" line) level. Actual RTP session is NULL for those MS. In case you feel that this definition has to be reworded, Pls suggest the text. Thanks Partha =20 > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Leon Portman > Sent: Sunday, July 10, 2011 1:28 PM > To: Ram Mohan R (rmohanr); Elwell, John; siprec@ietf.org > Subject: Re: [siprec] Comment on metadata-02 - Media Stream >=20 > Ram Hi >=20 > But do we want to link participant to RS media or Participant=20 > media to RS media? What will be the logic to reconstruct=20 > participant media sessions ( I am not talking about codecs=20 > and ports but types of the media for example). Specially ones=20 > that are not recorded or offered. I remember that we had=20 > discussion to support it. >=20 > Regards >=20 > Leon >=20 > -----Original Message----- > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > Sent: Friday, July 08, 2011 7:30 PM > To: Elwell, John; Leon Portman; siprec@ietf.org > Subject: RE: [siprec] Comment on metadata-02 - Media Stream >=20 > So I would combine and have the text for MS block as: >=20 > " A Media Stream block represents a single RTP session=20 > between an SRC and an SRS. Note that, because of possible=20 > mixing at the SRC, a Media Stream block does not necessarily=20 > represent a single RTP session between CS participants. MS=20 > block helps to link participants ( of CS) to its associated=20 > Media Streams ( in RS), the properties of which will be=20 > carried in RS SDP" >=20 > Please let me know if anyone has concerns otherwise I will=20 > incorporate this text in the next version of draft. >=20 > Regards, > Ram >=20 > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Friday, July 08, 2011 6:02 PM > > To: Ram Mohan R (rmohanr); Leon Portman; siprec@ietf.org > > Subject: RE: [siprec] Comment on metadata-02 - Media Stream > >=20 > > OK, sounds like a good compromise. > >=20 > > John > >=20 > > > -----Original Message----- > > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > > Sent: 08 July 2011 08:00 > > > To: Elwell, John; Leon Portman; siprec@ietf.org > > > Subject: RE: [siprec] Comment on metadata-02 - Media Stream > > > > > > John, > > > > > > I don't have any such issues with your definition. I think we can=20 > > > add " > > > MS block helps to link participants ( of CS) to its=20 > associated Media=20 > > > Streams ( in RS), the properties of which will be carried=20 > in RS SDP" > > > to your definition. > > > > > > I would like to have this line as it clearly says the intention=20 > > > /purpose of MS block. > > > > > > Regards, > > > Ram > > > > > > > -----Original Message----- > > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > Sent: Friday, July 08, 2011 12:20 PM > > > > To: Ram Mohan R (rmohanr); Leon Portman; siprec@ietf.org > > > > Subject: RE: [siprec] Comment on metadata-02 - Media Stream > > > > > > > > Ram, > > > > > > > > In my opinion your proposed definition is too abstract=20 > - I think a=20 > > > > reader would have a hard time understanding what such an object=20 > > > > represents in the real world. Can you pinpoint your=20 > objections to > > my > > > > proposal? > > > > > > > > Thanks, > > > > > > > > John > > > > > > > > > > > > > -----Original Message----- > > > > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > > > > Sent: 08 July 2011 05:59 > > > > > To: Leon Portman; Elwell, John; siprec@ietf.org > > > > > Subject: RE: [siprec] Comment on metadata-02 - Media Stream > > > > > > > > > > Hello John / Leon, > > > > > > > > > > Thanks for your comments on MS block in the metadata. I agree > > that > > > > the > > > > > current text is little confusing. > > > > > It is because when we started off with the metadata draft we > > > intended > > > > > that MS block represents properties of CS media. > > > > > > > > > > However after discussions we reached to a consensus that > > > MS does not > > > > > need to have CS media parameters. > > > > > > > > > > John's suggestion for definition is > > > > > > > > > > > Possibly a definition like: > > > > > > "A Media Stream block represents a single RTP=20 > session between > > an > > > > SRC > > > > > > and an SRS. Note that, because of possible mixing at the > > > > > SRC, a Media > > > > > > Stream block does not necessarily represent a single RTP > > session > > > > > > between CS participants." > > > > > > > > > > My suggestion is > > > > > > > > > > "An MS block/class represents an entity which helps to link=20 > > > > > participants ( of CS) to its associated Media Streams=20 > ( in RS),=20 > > > > > the > > > properties of > > > > > which will be carried in RS SDP". > > > > > > > > > > Please suggest if this text works fine. If not refine/suggest=20 > > > > > improvements. > > > > > > > > > > Regards, > > > > > Ram > > > > > > > > > > > -----Original Message----- > > > > > > From: siprec-bounces@ietf.org > > > [mailto:siprec-bounces@ietf.org] On > > > > > > Behalf Of Leon Portman > > > > > > Sent: Thursday, July 07, 2011 7:20 PM > > > > > > To: Elwell, John; siprec@ietf.org > > > > > > Subject: Re: [siprec] Comment on metadata-02 - Media Stream > > > > > > > > > > > > Actually I was expecting (a) as well. And it should point to > > the > > > > > > relevant media lines in RS SDP. If two or more Media > > > > > Streams point to > > > > > > the same RS SDP m-line label, then we have mixing use case > > > > > > > > > > > > So something like this: CS MS (1:1)- > XML MS ->=20 > (N:1) -> RS > > MS > > > > > > > > > > > > Leon > > > > > > > > > > > > -----Original Message----- > > > > > > From: siprec-bounces@ietf.org > > > [mailto:siprec-bounces@ietf.org] On > > > > > > Behalf Of Elwell, John > > > > > > Sent: Thursday, July 07, 2011 4:36 PM > > > > > > To: siprec@ietf.org > > > > > > Subject: [siprec] Comment on metadata-02 - Media Stream > > > > > > > > > > > > In section 6.5, Media Stream seems to be defined as follows: > > > > > > "A Media Stream block MUST have properties of media as seen > > > > > by SRC and > > > > > > sent to SRS." > > > > > > Ignoring the possibly inappropriate RFC 2119=20 > language, I don't > > > > think > > > > > > this clearly defines whether: > > > > > > a) this represents a medium of the CS (i.e., corresponding > > > > > to a media > > > > > > description in the CS SDP); or > > > > > > b) this represents a medium of the RS (i.e., corresponding > > > > > to a media > > > > > > description in the RS SDP). > > > > > > > > > > > > Both of these are "seen by SRC". There need not be a 1:1 > > > > > relationship > > > > > > between the two, and hence we need to make it clear=20 > which it=20 > > > > > > represents. > > > > > > > > > > > > Although personally I had expected a), a couple of=20 > threads in > > > > recent > > > > > > months have seemed to indicate b) is the general consensus. > > > > > > > > > > > > Possibly a definition like: > > > > > > "A Media Stream block represents a single RTP=20 > session between > > an > > > > SRC > > > > > > and an SRS. Note that, because of possible mixing at the > > > > > SRC, a Media > > > > > > Stream block does not necessarily represent a single RTP > > session > > > > > > between CS participants." > > > > > > > > > > > > However, if we accept this principle, I wonder what the > > > > > Start Time and > > > > > > End Time attributes mean. The start and end of an RS RTP > > session > > > > > > correspond to the relevant offer-answer exchanges, so they > > don't > > > > > really > > > > > > need to be in XML. So I suspect I still haven't drilled > > > > > down into the > > > > > > real meaning of MS sufficiently. > > > > > > > > > > > > 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 Leon.Portman@nice.com Sun Jul 10 03:23: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 E88FA21F854D for ; Sun, 10 Jul 2011 03:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.459 X-Spam-Level: X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[AWL=0.140, 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 t-kDzeu7hFth for ; Sun, 10 Jul 2011 03:23:50 -0700 (PDT) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id 6C34E21F8541 for ; Sun, 10 Jul 2011 03:23:49 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.15]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Sun, 10 Jul 2011 13:23:39 +0300 From: Leon Portman To: "Parthasarathi R (partr)" , "Ram Mohan R (rmohanr)" , "Elwell, John" , "siprec@ietf.org" Date: Sun, 10 Jul 2011 13:23:38 +0300 Thread-Topic: [siprec] Comment on metadata-02 - Media Stream Thread-Index: Acw8qtezJdNopWF7RZqONH6e5tBRLgAAYkSAAB8nk4AABHr7gAAAZo/QAAucg6AACEOLMABSr+wAAAIIyiAAAxLScA== Message-ID: <07465C1D981ABC41A344374066AE1A2C38B006A957@TLVMBX01.nice.com> References: <07465C1D981ABC41A344374066AE1A2C38AFE9BB98@TLVMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD06F4FD89@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD06F4FE0B@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD06F4FF85@XMB-BGL-417.cisco.com> <07465C1D981ABC41A344374066AE1A2C38B006A89D@TLVMBX01.nice.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Comment on metadata-02 - Media Stream X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jul 2011 10:23:51 -0000 Ram Hi I agree that we can indicate it via RS SDP but I don't think it will be mo= st elegant solution.=20 What is from your point of view, is the main compelling reason for MS blo= ck to represent RS media and not CS media? Regards Leon -----Original Message----- From: Parthasarathi R (partr) [mailto:partr@cisco.com]=20 Sent: Sunday, July 10, 2011 12:02 PM To: Leon Portman; Ram Mohan R (rmohanr); Elwell, John; siprec@ietf.org Subject: RE: [siprec] Comment on metadata-02 - Media Stream Leon, As you mentioned, it is possible to indicate special case of "not recorded"= through RS SDP as port value containing 0 in the media ("m=3D" line) level. Actual RTP session is NULL for those MS. In case you feel that= this definition has to be reworded, Pls suggest the text. Thanks Partha =20 > -----Original Message----- > From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] On Behalf Of Leon Portman > Sent: Sunday, July 10, 2011 1:28 PM > To: Ram Mohan R (rmohanr); Elwell, John; siprec@ietf.org > Subject: Re: [siprec] Comment on metadata-02 - Media Stream >=20 > Ram Hi >=20 > But do we want to link participant to RS media or Participant media to=20 > RS media? What will be the logic to reconstruct participant media=20 > sessions ( I am not talking about codecs and ports but types of the=20 > media for example). Specially ones that are not recorded or offered. I=20 > remember that we had discussion to support it. >=20 > Regards >=20 > Leon >=20 > -----Original Message----- > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > Sent: Friday, July 08, 2011 7:30 PM > To: Elwell, John; Leon Portman; siprec@ietf.org > Subject: RE: [siprec] Comment on metadata-02 - Media Stream >=20 > So I would combine and have the text for MS block as: >=20 > " A Media Stream block represents a single RTP session between an SRC=20 > and an SRS. Note that, because of possible mixing at the SRC, a Media=20 > Stream block does not necessarily represent a single RTP session=20 > between CS participants. MS block helps to link participants ( of CS)=20 > to its associated Media Streams ( in RS), the properties of which will=20 > be carried in RS SDP" >=20 > Please let me know if anyone has concerns otherwise I will incorporate=20 > this text in the next version of draft. >=20 > Regards, > Ram >=20 > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Friday, July 08, 2011 6:02 PM > > To: Ram Mohan R (rmohanr); Leon Portman; siprec@ietf.org > > Subject: RE: [siprec] Comment on metadata-02 - Media Stream > >=20 > > OK, sounds like a good compromise. > >=20 > > John > >=20 > > > -----Original Message----- > > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > > Sent: 08 July 2011 08:00 > > > To: Elwell, John; Leon Portman; siprec@ietf.org > > > Subject: RE: [siprec] Comment on metadata-02 - Media Stream > > > > > > John, > > > > > > I don't have any such issues with your definition. I think we can=20 > > > add " > > > MS block helps to link participants ( of CS) to its > associated Media > > > Streams ( in RS), the properties of which will be carried > in RS SDP" > > > to your definition. > > > > > > I would like to have this line as it clearly says the intention=20 > > > /purpose of MS block. > > > > > > Regards, > > > Ram > > > > > > > -----Original Message----- > > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > Sent: Friday, July 08, 2011 12:20 PM > > > > To: Ram Mohan R (rmohanr); Leon Portman; siprec@ietf.org > > > > Subject: RE: [siprec] Comment on metadata-02 - Media Stream > > > > > > > > Ram, > > > > > > > > In my opinion your proposed definition is too abstract > - I think a > > > > reader would have a hard time understanding what such an object=20 > > > > represents in the real world. Can you pinpoint your > objections to > > my > > > > proposal? > > > > > > > > Thanks, > > > > > > > > John > > > > > > > > > > > > > -----Original Message----- > > > > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > > > > Sent: 08 July 2011 05:59 > > > > > To: Leon Portman; Elwell, John; siprec@ietf.org > > > > > Subject: RE: [siprec] Comment on metadata-02 - Media Stream > > > > > > > > > > Hello John / Leon, > > > > > > > > > > Thanks for your comments on MS block in the metadata. I agree > > that > > > > the > > > > > current text is little confusing. > > > > > It is because when we started off with the metadata draft we > > > intended > > > > > that MS block represents properties of CS media. > > > > > > > > > > However after discussions we reached to a consensus that > > > MS does not > > > > > need to have CS media parameters. > > > > > > > > > > John's suggestion for definition is > > > > > > > > > > > Possibly a definition like: > > > > > > "A Media Stream block represents a single RTP > session between > > an > > > > SRC > > > > > > and an SRS. Note that, because of possible mixing at the > > > > > SRC, a Media > > > > > > Stream block does not necessarily represent a single RTP > > session > > > > > > between CS participants." > > > > > > > > > > My suggestion is > > > > > > > > > > "An MS block/class represents an entity which helps to link=20 > > > > > participants ( of CS) to its associated Media Streams > ( in RS), > > > > > the > > > properties of > > > > > which will be carried in RS SDP". > > > > > > > > > > Please suggest if this text works fine. If not refine/suggest=20 > > > > > improvements. > > > > > > > > > > Regards, > > > > > Ram > > > > > > > > > > > -----Original Message----- > > > > > > From: siprec-bounces@ietf.org > > > [mailto:siprec-bounces@ietf.org] On > > > > > > Behalf Of Leon Portman > > > > > > Sent: Thursday, July 07, 2011 7:20 PM > > > > > > To: Elwell, John; siprec@ietf.org > > > > > > Subject: Re: [siprec] Comment on metadata-02 - Media Stream > > > > > > > > > > > > Actually I was expecting (a) as well. And it should point to > > the > > > > > > relevant media lines in RS SDP. If two or more Media > > > > > Streams point to > > > > > > the same RS SDP m-line label, then we have mixing use case > > > > > > > > > > > > So something like this: CS MS (1:1)- > XML MS -> > (N:1) -> RS > > MS > > > > > > > > > > > > Leon > > > > > > > > > > > > -----Original Message----- > > > > > > From: siprec-bounces@ietf.org > > > [mailto:siprec-bounces@ietf.org] On > > > > > > Behalf Of Elwell, John > > > > > > Sent: Thursday, July 07, 2011 4:36 PM > > > > > > To: siprec@ietf.org > > > > > > Subject: [siprec] Comment on metadata-02 - Media Stream > > > > > > > > > > > > In section 6.5, Media Stream seems to be defined as follows: > > > > > > "A Media Stream block MUST have properties of media as seen > > > > > by SRC and > > > > > > sent to SRS." > > > > > > Ignoring the possibly inappropriate RFC 2119 > language, I don't > > > > think > > > > > > this clearly defines whether: > > > > > > a) this represents a medium of the CS (i.e., corresponding > > > > > to a media > > > > > > description in the CS SDP); or > > > > > > b) this represents a medium of the RS (i.e., corresponding > > > > > to a media > > > > > > description in the RS SDP). > > > > > > > > > > > > Both of these are "seen by SRC". There need not be a 1:1 > > > > > relationship > > > > > > between the two, and hence we need to make it clear > which it > > > > > > represents. > > > > > > > > > > > > Although personally I had expected a), a couple of > threads in > > > > recent > > > > > > months have seemed to indicate b) is the general consensus. > > > > > > > > > > > > Possibly a definition like: > > > > > > "A Media Stream block represents a single RTP > session between > > an > > > > SRC > > > > > > and an SRS. Note that, because of possible mixing at the > > > > > SRC, a Media > > > > > > Stream block does not necessarily represent a single RTP > > session > > > > > > between CS participants." > > > > > > > > > > > > However, if we accept this principle, I wonder what the > > > > > Start Time and > > > > > > End Time attributes mean. The start and end of an RS RTP > > session > > > > > > correspond to the relevant offer-answer exchanges, so they > > don't > > > > > really > > > > > > need to be in XML. So I suspect I still haven't drilled > > > > > down into the > > > > > > real meaning of MS sufficiently. > > > > > > > > > > > > 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 Henry.Lum@alcatel-lucent.com Sun Jul 10 18:47: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 B476021F8804 for ; Sun, 10 Jul 2011 18:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RlvBX8Z7w46g for ; Sun, 10 Jul 2011 18:47:25 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 248B921F87BD for ; Sun, 10 Jul 2011 18:47:25 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p6B1lMxU012521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 10 Jul 2011 20:47:23 -0500 (CDT) Received: from relay-out1.wc.genesyslab.com (relay-out1.wc.genesyslab.com [172.22.70.114]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p6B1lLEm000916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 10 Jul 2011 20:47:22 -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 p6B1lKUE020729 for ; Sun, 10 Jul 2011 18:47:20 -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, 10 Jul 2011 18:47:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Sun, 10 Jul 2011 18:47:19 -0700 Message-ID: <059AF07365DC474393A19A3AF187DF74074805B8@NAHALD.us.int.genesyslab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-portman-siprec-protocol-05.txt Thread-Index: Acw/bEd9Zgez18kRS5a9SsapIVfEfQAAAgyQ From: "Henry Lum" To: X-OriginalArrivalTime: 11 Jul 2011 01:47:20.0777 (UTC) FILETIME=[791B9390:01CC3F6C] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: [siprec] FW: New Version Notification for draft-portman-siprec-protocol-05.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 01:47:25 -0000 SGksIA0KDQpUaGUgdXBkYXRlZCBkcmFmdCB0cmllcyB0byBhZGRyZXNzIGFsbCB0aGUgb3V0c3Rh bmRpbmcgaXNzdWVzIGZyb20gdGhlIGludGVyaW0gY2FsbCBhbmQgaW4gdGhlIG1haWxpbmcgbGlz dC4NCg0KUmVnYXJkcywNCkhlbnJ5DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmddIA0KU2VudDogU3VuZGF5LCBKdWx5IDEwLCAyMDExIDk6NDYgUE0NClRvOiBIZW5yeSBMdW0N CkNjOiBIZW5yeSBMdW07IGxlb24ucG9ydG1hbkBuaWNlLmNvbTsgYWxhbi5iLmpvaG5zdG9uQGdt YWlsLmNvbTsgYW5kcmV3Lmh1dHRvbkBzaWVtZW5zLWVudGVycHJpc2UuY29tDQpTdWJqZWN0OiBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXBvcnRtYW4tc2lwcmVjLXByb3RvY29s LTA1LnR4dA0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtcG9ydG1hbi1zaXByZWMtcHJv dG9jb2wtMDUudHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgSGVucnkgTHVt IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC1w b3J0bWFuLXNpcHJlYy1wcm90b2NvbA0KUmV2aXNpb246CSAwNQ0KVGl0bGU6CQkgU2Vzc2lvbiBS ZWNvcmRpbmcgUHJvdG9jb2wNCkNyZWF0aW9uIGRhdGU6CSAyMDExLTA3LTA4DQpXRyBJRDoJCSBJ bmRpdmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczogMjINCg0KQWJzdHJhY3Q6DQog ICBUaGUgU2Vzc2lvbiBSZWNvcmRpbmcgUHJvdG9jb2wgaXMgdXNlZCBmb3IgZXN0YWJsaXNoaW5n IHJlY29yZGluZw0KICAgc2Vzc2lvbiBhbmQgcmVwb3J0aW5nIG9mIHRoZSBtZXRhZGF0YSBvZiB0 aGUgY29tbXVuaWNhdGlvbiBzZXNzaW9uLg0KDQogICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyB0 aGUgU2Vzc2lvbiBSZWNvcmRpbmcgUHJvdG9jb2wuICBUaGUgcHJvdG9jb2wNCiAgIGlzIHVzZWQg YmV0d2VlbiBTZXNzaW9uIFJlY29yZGluZyBDbGllbnQgKFNSQykgYW5kIFNlc3Npb24gUmVjb3Jk aW5nDQogICBTZXJ2ZXIgKFNSUykuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpU aGUgSUVURiBTZWNyZXRhcmlhdA0KDQoJCQkJCQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQ09ORklERU5USUFMSVRZIE5PVElDRTog VGhpcyBlLW1haWwgYW5kIGFueSBmaWxlcyBhdHRhY2hlZCBtYXkgY29udGFpbiBjb25maWRlbnRp YWwgYW5kIHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uIG9mIEFsY2F0ZWwtTHVjZW50IGFuZC9vciBp dHMgYWZmaWxpYXRlZCBlbnRpdGllcy4gQWNjZXNzIGJ5IHRoZSBpbnRlbmRlZCByZWNpcGllbnQg b25seSBpcyBhdXRob3JpemVkLiBBbnkgbGlhYmlsaXR5IGFyaXNpbmcgZnJvbSBhbnkgcGFydHkg YWN0aW5nLCBvciByZWZyYWluaW5nIGZyb20gYWN0aW5nLCBvbiBhbnkgaW5mb3JtYXRpb24gY29u dGFpbmVkIGluIHRoaXMgZS1tYWlsIGlzIGhlcmVieSBleGNsdWRlZC4gSWYgeW91IGFyZSBub3Qg dGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0 ZWx5LCBkZXN0cm95IHRoZSBvcmlnaW5hbCB0cmFuc21pc3Npb24gYW5kIGl0cyBhdHRhY2htZW50 cyBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1 c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBp biBhbnkgbWVkaXVtLiBDb3B5cmlnaHQgaW4gdGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50 cyBiZWxvbmdzIHRvIEFsY2F0ZWwtTHVjZW50IGFuZC9vciBpdHMgYWZmaWxpYXRlZCBlbnRpdGll cy4NCgkJCQkJDQo= From rmohanr@cisco.com Sun Jul 10 20:59: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 072CD21F8876 for ; Sun, 10 Jul 2011 20:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_14=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 ERVzc+FeMkth for ; Sun, 10 Jul 2011 20:59:46 -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 06C2D21F8546 for ; Sun, 10 Jul 2011 20:59:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=10847; q=dns/txt; s=iport; t=1310356786; x=1311566386; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=XGF+2U9YtaaNLLoffHFMKbWgEK1zFtdkI1HZV9x2U2w=; b=kTBy5wk2g71M/IEyT+VuqHXfEcENfycYqj10xJ4JUbAzNzmitY8EB5sY ejSTU8EcEL4frqHeZ0ZqC5wlpDFFEvB+b2d0BulrSfJVAsdwMtBJhQ39J S1wYSkK0q4hyUTPplKbriZOlJXhN515RWWvwdYqpCCRDNxYqg7yafSrE3 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQBAKh0Gk5Io8UR/2dsb2JhbABTmAePNneIeqEXnS+FW18Eh0yQD4tI X-IronPort-AV: E=Sophos;i="4.65,512,1304294400"; d="scan'208";a="41470269" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-2.cisco.com with ESMTP; 11 Jul 2011 03:59:43 +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 p6B3xhRq005394; Mon, 11 Jul 2011 03:59:43 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 11 Jul 2011 09:29:42 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 11 Jul 2011 09:29:40 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD06F500AB@XMB-BGL-417.cisco.com> In-reply-to: <07465C1D981ABC41A344374066AE1A2C38B006A957@TLVMBX01.nice.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Comment on metadata-02 - Media Stream Thread-Index: Acw8qtezJdNopWF7RZqONH6e5tBRLgAAYkSAAB8nk4AABHr7gAAAZo/QAAucg6AACEOLMABSr+wAAAIIyiAAAxLScAAkEbZg References: <07465C1D981ABC41A344374066AE1A2C38AFE9BB98@TLVMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD06F4FD89@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD06F4FE0B@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD06F4FF85@XMB-BGL-417.cisco.com> <07465C1D981ABC41A344374066AE1A2C38B006A89D@TLVMBX01.nice.com> <07465C1D981ABC41A344374066AE1A2C38B006A957@TLVMBX01.nice.com> From: "Ram Mohan R (rmohanr)" To: "Leon Portman" , "Parthasarathi R (partr)" , "Elwell, John" , X-OriginalArrivalTime: 11 Jul 2011 03:59:42.0940 (UTC) FILETIME=[F70179C0:01CC3F7E] Subject: Re: [siprec] Comment on metadata-02 - Media Stream X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 03:59:48 -0000 Hi Leon, 1) For the use case where SRC offers a set of streams (say audio and video) but SRS does chose to record only part of them (say audio only), the SRC may still continue to send updates for that m-line ( with port =3D0). =20 2) For the use case SRC may not offer all the media types ( of CS) as it may not have capability to record, the SRC can still send the initial offer with port 0 in the m=3Dline. I remember this was something for which there was no concerns from any one. In case you see some issues with this approach, Please let us know the same. Please refer to one of the mail threads for an earlier discussion on this topic http://www.ietf.org/mail-archive/web/siprec/current/msg01304.html I would not prefer MS block to represent CS media for just these cases as it would be duplication at XML level when we have agreed that MS block represents RS media for all other use-cases. Regards, Ram > -----Original Message----- > From: Leon Portman [mailto:Leon.Portman@nice.com] > Sent: Sunday, July 10, 2011 3:54 PM > To: Parthasarathi R (partr); Ram Mohan R (rmohanr); Elwell, John; > siprec@ietf.org > Subject: RE: [siprec] Comment on metadata-02 - Media Stream >=20 > Ram Hi > I agree that we can indicate it via RS SDP but I don't think it will > be most elegant solution. > What is from your point of view, is the main compelling reason for MS > block to represent RS media and not CS media? >=20 > Regards >=20 > Leon >=20 > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > Sent: Sunday, July 10, 2011 12:02 PM > To: Leon Portman; Ram Mohan R (rmohanr); Elwell, John; siprec@ietf.org > Subject: RE: [siprec] Comment on metadata-02 - Media Stream >=20 > Leon, >=20 > As you mentioned, it is possible to indicate special case of "not > recorded" through RS SDP as port value containing 0 in the media = ("m=3D" > line) level. Actual RTP session is NULL for those MS. In case you feel > that this definition has to be reworded, Pls suggest the text. >=20 > Thanks > Partha >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf Of Leon Portman > > Sent: Sunday, July 10, 2011 1:28 PM > > To: Ram Mohan R (rmohanr); Elwell, John; siprec@ietf.org > > Subject: Re: [siprec] Comment on metadata-02 - Media Stream > > > > Ram Hi > > > > But do we want to link participant to RS media or Participant media > to > > RS media? What will be the logic to reconstruct participant media > > sessions ( I am not talking about codecs and ports but types of the > > media for example). Specially ones that are not recorded or offered. > I > > remember that we had discussion to support it. > > > > Regards > > > > Leon > > > > -----Original Message----- > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > Sent: Friday, July 08, 2011 7:30 PM > > To: Elwell, John; Leon Portman; siprec@ietf.org > > Subject: RE: [siprec] Comment on metadata-02 - Media Stream > > > > So I would combine and have the text for MS block as: > > > > " A Media Stream block represents a single RTP session between an SRC > > and an SRS. Note that, because of possible mixing at the SRC, a Media > > Stream block does not necessarily represent a single RTP session > > between CS participants. MS block helps to link participants ( of CS) > > to its associated Media Streams ( in RS), the properties of which > will > > be carried in RS SDP" > > > > Please let me know if anyone has concerns otherwise I will > incorporate > > this text in the next version of draft. > > > > Regards, > > Ram > > > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > Sent: Friday, July 08, 2011 6:02 PM > > > To: Ram Mohan R (rmohanr); Leon Portman; siprec@ietf.org > > > Subject: RE: [siprec] Comment on metadata-02 - Media Stream > > > > > > OK, sounds like a good compromise. > > > > > > John > > > > > > > -----Original Message----- > > > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > > > Sent: 08 July 2011 08:00 > > > > To: Elwell, John; Leon Portman; siprec@ietf.org > > > > Subject: RE: [siprec] Comment on metadata-02 - Media Stream > > > > > > > > John, > > > > > > > > I don't have any such issues with your definition. I think we can > > > > add " > > > > MS block helps to link participants ( of CS) to its > > associated Media > > > > Streams ( in RS), the properties of which will be carried > > in RS SDP" > > > > to your definition. > > > > > > > > I would like to have this line as it clearly says the intention > > > > /purpose of MS block. > > > > > > > > Regards, > > > > Ram > > > > > > > > > -----Original Message----- > > > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > > Sent: Friday, July 08, 2011 12:20 PM > > > > > To: Ram Mohan R (rmohanr); Leon Portman; siprec@ietf.org > > > > > Subject: RE: [siprec] Comment on metadata-02 - Media Stream > > > > > > > > > > Ram, > > > > > > > > > > In my opinion your proposed definition is too abstract > > - I think a > > > > > reader would have a hard time understanding what such an object > > > > > represents in the real world. Can you pinpoint your > > objections to > > > my > > > > > proposal? > > > > > > > > > > Thanks, > > > > > > > > > > John > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > > > > > Sent: 08 July 2011 05:59 > > > > > > To: Leon Portman; Elwell, John; siprec@ietf.org > > > > > > Subject: RE: [siprec] Comment on metadata-02 - Media Stream > > > > > > > > > > > > Hello John / Leon, > > > > > > > > > > > > Thanks for your comments on MS block in the metadata. I agree > > > that > > > > > the > > > > > > current text is little confusing. > > > > > > It is because when we started off with the metadata draft we > > > > intended > > > > > > that MS block represents properties of CS media. > > > > > > > > > > > > However after discussions we reached to a consensus that > > > > MS does not > > > > > > need to have CS media parameters. > > > > > > > > > > > > John's suggestion for definition is > > > > > > > > > > > > > Possibly a definition like: > > > > > > > "A Media Stream block represents a single RTP > > session between > > > an > > > > > SRC > > > > > > > and an SRS. Note that, because of possible mixing at the > > > > > > SRC, a Media > > > > > > > Stream block does not necessarily represent a single RTP > > > session > > > > > > > between CS participants." > > > > > > > > > > > > My suggestion is > > > > > > > > > > > > "An MS block/class represents an entity which helps to link > > > > > > participants ( of CS) to its associated Media Streams > > ( in RS), > > > > > > the > > > > properties of > > > > > > which will be carried in RS SDP". > > > > > > > > > > > > Please suggest if this text works fine. If not refine/suggest > > > > > > improvements. > > > > > > > > > > > > Regards, > > > > > > Ram > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: siprec-bounces@ietf.org > > > > [mailto:siprec-bounces@ietf.org] On > > > > > > > Behalf Of Leon Portman > > > > > > > Sent: Thursday, July 07, 2011 7:20 PM > > > > > > > To: Elwell, John; siprec@ietf.org > > > > > > > Subject: Re: [siprec] Comment on metadata-02 - Media Stream > > > > > > > > > > > > > > Actually I was expecting (a) as well. And it should point > to > > > the > > > > > > > relevant media lines in RS SDP. If two or more Media > > > > > > Streams point to > > > > > > > the same RS SDP m-line label, then we have mixing use case > > > > > > > > > > > > > > So something like this: CS MS (1:1)- > XML MS -> > > (N:1) -> RS > > > MS > > > > > > > > > > > > > > Leon > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: siprec-bounces@ietf.org > > > > [mailto:siprec-bounces@ietf.org] On > > > > > > > Behalf Of Elwell, John > > > > > > > Sent: Thursday, July 07, 2011 4:36 PM > > > > > > > To: siprec@ietf.org > > > > > > > Subject: [siprec] Comment on metadata-02 - Media Stream > > > > > > > > > > > > > > In section 6.5, Media Stream seems to be defined as > follows: > > > > > > > "A Media Stream block MUST have properties of media as seen > > > > > > by SRC and > > > > > > > sent to SRS." > > > > > > > Ignoring the possibly inappropriate RFC 2119 > > language, I don't > > > > > think > > > > > > > this clearly defines whether: > > > > > > > a) this represents a medium of the CS (i.e., corresponding > > > > > > to a media > > > > > > > description in the CS SDP); or > > > > > > > b) this represents a medium of the RS (i.e., corresponding > > > > > > to a media > > > > > > > description in the RS SDP). > > > > > > > > > > > > > > Both of these are "seen by SRC". There need not be a 1:1 > > > > > > relationship > > > > > > > between the two, and hence we need to make it clear > > which it > > > > > > > represents. > > > > > > > > > > > > > > Although personally I had expected a), a couple of > > threads in > > > > > recent > > > > > > > months have seemed to indicate b) is the general consensus. > > > > > > > > > > > > > > Possibly a definition like: > > > > > > > "A Media Stream block represents a single RTP > > session between > > > an > > > > > SRC > > > > > > > and an SRS. Note that, because of possible mixing at the > > > > > > SRC, a Media > > > > > > > Stream block does not necessarily represent a single RTP > > > session > > > > > > > between CS participants." > > > > > > > > > > > > > > However, if we accept this principle, I wonder what the > > > > > > Start Time and > > > > > > > End Time attributes mean. The start and end of an RS RTP > > > session > > > > > > > correspond to the relevant offer-answer exchanges, so they > > > don't > > > > > > really > > > > > > > need to be in XML. So I suspect I still haven't drilled > > > > > > down into the > > > > > > > real meaning of MS sufficiently. > > > > > > > > > > > > > > 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 Leon.Portman@nice.com Mon Jul 11 03:49: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 7137A21F88AB for ; Mon, 11 Jul 2011 03:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.168 X-Spam-Level: X-Spam-Status: No, score=-2.168 tagged_above=-999 required=5 tests=[AWL=-0.169, BAYES_00=-2.599, J_CHICKENPOX_14=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 6RUWfq05zAe6 for ; Mon, 11 Jul 2011 03:49:08 -0700 (PDT) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id CBA2621F869F for ; Mon, 11 Jul 2011 03:49:07 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.15]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Mon, 11 Jul 2011 13:49:06 +0300 From: Leon Portman To: "Ram Mohan R (rmohanr)" , "Parthasarathi R (partr)" , "Elwell, John" , "siprec@ietf.org" Date: Mon, 11 Jul 2011 13:49:05 +0300 Thread-Topic: [siprec] Comment on metadata-02 - Media Stream Thread-Index: Acw8qtezJdNopWF7RZqONH6e5tBRLgAAYkSAAB8nk4AABHr7gAAAZo/QAAucg6AACEOLMABSr+wAAAIIyiAAAxLScAAkEbZgAA8O9BA= Message-ID: <07465C1D981ABC41A344374066AE1A2C38B006ADB8@TLVMBX01.nice.com> References: <07465C1D981ABC41A344374066AE1A2C38AFE9BB98@TLVMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD06F4FD89@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD06F4FE0B@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD06F4FF85@XMB-BGL-417.cisco.com> <07465C1D981ABC41A344374066AE1A2C38B006A89D@TLVMBX01.nice.com> <07465C1D981ABC41A344374066AE1A2C38B006A957@TLVMBX01.nice.com> <35BCE99A477D6A4986FB2216D8CF2CFD06F500AB@XMB-BGL-417.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD06F500AB@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] Comment on metadata-02 - Media Stream X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 10:49:09 -0000 Ram Hi My concern is not technical implementation but logical meaning. Metadata X= ML represents CS: participants, states, medias. It is very confusing (at le= ast for me) that media is about recording session and not communication ses= sion. However If everybody ok with that, let's go forward with the current= approach. Leon -----Original Message----- From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com]=20 Sent: Monday, July 11, 2011 7:00 AM To: Leon Portman; Parthasarathi R (partr); Elwell, John; siprec@ietf.org Subject: RE: [siprec] Comment on metadata-02 - Media Stream Hi Leon, 1) For the use case where SRC offers a set of streams (say audio and video) but SRS does chose to record only part of them (say audio only), the= SRC may still continue to send updates for that m-line ( with port =3D0). = =20 2) For the use case SRC may not offer all the media types ( of CS) as it ma= y not have capability to record, the SRC can still send the initial offer w= ith port 0 in the m=3Dline. I remember this was something for which there was no concerns from any one.= In case you see some issues with this approach, Please let us know the sam= e. Please refer to one of the mail threads for an earlier discussion on this t= opic http://www.ietf.org/mail-archive/web/siprec/current/msg01304.html I would not prefer MS block to represent CS media for just these cases as i= t would be duplication at XML level when we have agreed that MS block repre= sents RS media for all other use-cases. Regards, Ram > -----Original Message----- > From: Leon Portman [mailto:Leon.Portman@nice.com] > Sent: Sunday, July 10, 2011 3:54 PM > To: Parthasarathi R (partr); Ram Mohan R (rmohanr); Elwell, John;=20 > siprec@ietf.org > Subject: RE: [siprec] Comment on metadata-02 - Media Stream >=20 > Ram Hi > I agree that we can indicate it via RS SDP but I don't think it will=20 > be most elegant solution. > What is from your point of view, is the main compelling reason for MS > block to represent RS media and not CS media? >=20 > Regards >=20 > Leon >=20 > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > Sent: Sunday, July 10, 2011 12:02 PM > To: Leon Portman; Ram Mohan R (rmohanr); Elwell, John; siprec@ietf.org > Subject: RE: [siprec] Comment on metadata-02 - Media Stream >=20 > Leon, >=20 > As you mentioned, it is possible to indicate special case of "not=20 > recorded" through RS SDP as port value containing 0 in the media ("m=3D" > line) level. Actual RTP session is NULL for those MS. In case you feel=20 > that this definition has to be reworded, Pls suggest the text. >=20 > Thanks > Partha >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf Of Leon Portman > > Sent: Sunday, July 10, 2011 1:28 PM > > To: Ram Mohan R (rmohanr); Elwell, John; siprec@ietf.org > > Subject: Re: [siprec] Comment on metadata-02 - Media Stream > > > > Ram Hi > > > > But do we want to link participant to RS media or Participant media > to > > RS media? What will be the logic to reconstruct participant media=20 > > sessions ( I am not talking about codecs and ports but types of the=20 > > media for example). Specially ones that are not recorded or offered. > I > > remember that we had discussion to support it. > > > > Regards > > > > Leon > > > > -----Original Message----- > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > Sent: Friday, July 08, 2011 7:30 PM > > To: Elwell, John; Leon Portman; siprec@ietf.org > > Subject: RE: [siprec] Comment on metadata-02 - Media Stream > > > > So I would combine and have the text for MS block as: > > > > " A Media Stream block represents a single RTP session between an SRC > > and an SRS. Note that, because of possible mixing at the SRC, a Media > > Stream block does not necessarily represent a single RTP session=20 > > between CS participants. MS block helps to link participants ( of CS) > > to its associated Media Streams ( in RS), the properties of which > will > > be carried in RS SDP" > > > > Please let me know if anyone has concerns otherwise I will > incorporate > > this text in the next version of draft. > > > > Regards, > > Ram > > > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > Sent: Friday, July 08, 2011 6:02 PM > > > To: Ram Mohan R (rmohanr); Leon Portman; siprec@ietf.org > > > Subject: RE: [siprec] Comment on metadata-02 - Media Stream > > > > > > OK, sounds like a good compromise. > > > > > > John > > > > > > > -----Original Message----- > > > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > > > Sent: 08 July 2011 08:00 > > > > To: Elwell, John; Leon Portman; siprec@ietf.org > > > > Subject: RE: [siprec] Comment on metadata-02 - Media Stream > > > > > > > > John, > > > > > > > > I don't have any such issues with your definition. I think we can > > > > add " > > > > MS block helps to link participants ( of CS) to its > > associated Media > > > > Streams ( in RS), the properties of which will be carried > > in RS SDP" > > > > to your definition. > > > > > > > > I would like to have this line as it clearly says the intention=20 > > > > /purpose of MS block. > > > > > > > > Regards, > > > > Ram > > > > > > > > > -----Original Message----- > > > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > > Sent: Friday, July 08, 2011 12:20 PM > > > > > To: Ram Mohan R (rmohanr); Leon Portman; siprec@ietf.org > > > > > Subject: RE: [siprec] Comment on metadata-02 - Media Stream > > > > > > > > > > Ram, > > > > > > > > > > In my opinion your proposed definition is too abstract > > - I think a > > > > > reader would have a hard time understanding what such an object > > > > > represents in the real world. Can you pinpoint your > > objections to > > > my > > > > > proposal? > > > > > > > > > > Thanks, > > > > > > > > > > John > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > > > > > Sent: 08 July 2011 05:59 > > > > > > To: Leon Portman; Elwell, John; siprec@ietf.org > > > > > > Subject: RE: [siprec] Comment on metadata-02 - Media Stream > > > > > > > > > > > > Hello John / Leon, > > > > > > > > > > > > Thanks for your comments on MS block in the metadata. I agree > > > that > > > > > the > > > > > > current text is little confusing. > > > > > > It is because when we started off with the metadata draft we > > > > intended > > > > > > that MS block represents properties of CS media. > > > > > > > > > > > > However after discussions we reached to a consensus that > > > > MS does not > > > > > > need to have CS media parameters. > > > > > > > > > > > > John's suggestion for definition is > > > > > > > > > > > > > Possibly a definition like: > > > > > > > "A Media Stream block represents a single RTP > > session between > > > an > > > > > SRC > > > > > > > and an SRS. Note that, because of possible mixing at the > > > > > > SRC, a Media > > > > > > > Stream block does not necessarily represent a single RTP > > > session > > > > > > > between CS participants." > > > > > > > > > > > > My suggestion is > > > > > > > > > > > > "An MS block/class represents an entity which helps to link=20 > > > > > > participants ( of CS) to its associated Media Streams > > ( in RS), > > > > > > the > > > > properties of > > > > > > which will be carried in RS SDP". > > > > > > > > > > > > Please suggest if this text works fine. If not refine/suggest > > > > > > improvements. > > > > > > > > > > > > Regards, > > > > > > Ram > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: siprec-bounces@ietf.org > > > > [mailto:siprec-bounces@ietf.org] On > > > > > > > Behalf Of Leon Portman > > > > > > > Sent: Thursday, July 07, 2011 7:20 PM > > > > > > > To: Elwell, John; siprec@ietf.org > > > > > > > Subject: Re: [siprec] Comment on metadata-02 - Media Stream > > > > > > > > > > > > > > Actually I was expecting (a) as well. And it should point > to > > > the > > > > > > > relevant media lines in RS SDP. If two or more Media > > > > > > Streams point to > > > > > > > the same RS SDP m-line label, then we have mixing use case > > > > > > > > > > > > > > So something like this: CS MS (1:1)- > XML MS -> > > (N:1) -> RS > > > MS > > > > > > > > > > > > > > Leon > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: siprec-bounces@ietf.org > > > > [mailto:siprec-bounces@ietf.org] On > > > > > > > Behalf Of Elwell, John > > > > > > > Sent: Thursday, July 07, 2011 4:36 PM > > > > > > > To: siprec@ietf.org > > > > > > > Subject: [siprec] Comment on metadata-02 - Media Stream > > > > > > > > > > > > > > In section 6.5, Media Stream seems to be defined as > follows: > > > > > > > "A Media Stream block MUST have properties of media as seen > > > > > > by SRC and > > > > > > > sent to SRS." > > > > > > > Ignoring the possibly inappropriate RFC 2119 > > language, I don't > > > > > think > > > > > > > this clearly defines whether: > > > > > > > a) this represents a medium of the CS (i.e., corresponding > > > > > > to a media > > > > > > > description in the CS SDP); or > > > > > > > b) this represents a medium of the RS (i.e., corresponding > > > > > > to a media > > > > > > > description in the RS SDP). > > > > > > > > > > > > > > Both of these are "seen by SRC". There need not be a 1:1 > > > > > > relationship > > > > > > > between the two, and hence we need to make it clear > > which it > > > > > > > represents. > > > > > > > > > > > > > > Although personally I had expected a), a couple of > > threads in > > > > > recent > > > > > > > months have seemed to indicate b) is the general consensus. > > > > > > > > > > > > > > Possibly a definition like: > > > > > > > "A Media Stream block represents a single RTP > > session between > > > an > > > > > SRC > > > > > > > and an SRS. Note that, because of possible mixing at the > > > > > > SRC, a Media > > > > > > > Stream block does not necessarily represent a single RTP > > > session > > > > > > > between CS participants." > > > > > > > > > > > > > > However, if we accept this principle, I wonder what the > > > > > > Start Time and > > > > > > > End Time attributes mean. The start and end of an RS RTP > > > session > > > > > > > correspond to the relevant offer-answer exchanges, so they > > > don't > > > > > > really > > > > > > > need to be in XML. So I suspect I still haven't drilled > > > > > > down into the > > > > > > > real meaning of MS sufficiently. > > > > > > > > > > > > > > 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 Mon Jul 11 03:56: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 4253E21F8B12 for ; Mon, 11 Jul 2011 03:56:16 -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.185, BAYES_00=-2.599, J_CHICKENPOX_14=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 Ue4RoH8djjlf for ; Mon, 11 Jul 2011 03:56: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 2FC5321F8B0F for ; Mon, 11 Jul 2011 03:56:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=13363; q=dns/txt; s=iport; t=1310381774; x=1311591374; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=MRgJhnR/ndHucAhAnzEuuCDw1DICpo2o/vSb22Qd4b8=; b=UVRJ9RT762oYxTwN6Ms0fOhcKSll9L8bYKJbRlVUkyNBN5QblR+rkUn2 TvlIoFWztsRZwl4IeM7d9OaqaWDoNAlLvkNMigcP+74kIuXzIqPgoBKy4 Woo6JwgyAiOrSO80IMuS3QGFpn4SOiIJYqUkwMilLbZh+nObl52Eymzly Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvIAAODVGk5Io8UR/2dsb2JhbABTmAKPN3eIeqABnV2FW18Eh0yQD4tI X-IronPort-AV: E=Sophos;i="4.65,515,1304294400"; d="scan'208";a="100687446" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-1.cisco.com with ESMTP; 11 Jul 2011 10:56:11 +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 p6BAuBMY013572; Mon, 11 Jul 2011 10:56:11 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 11 Jul 2011 16:26: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: Mon, 11 Jul 2011 16:26:07 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD06F502A0@XMB-BGL-417.cisco.com> In-reply-to: <07465C1D981ABC41A344374066AE1A2C38B006ADB8@TLVMBX01.nice.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Comment on metadata-02 - Media Stream Thread-Index: Acw8qtezJdNopWF7RZqONH6e5tBRLgAAYkSAAB8nk4AABHr7gAAAZo/QAAucg6AACEOLMABSr+wAAAIIyiAAAxLScAAkEbZgAA8O9BAAACc8AA== References: <07465C1D981ABC41A344374066AE1A2C38AFE9BB98@TLVMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD06F4FD89@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD06F4FE0B@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD06F4FF85@XMB-BGL-417.cisco.com> <07465C1D981ABC41A344374066AE1A2C38B006A89D@TLVMBX01.nice.com> <07465C1D981ABC41A344374066AE1A2C38B006A957@TLVMBX01.nice.com> <35BCE99A477D6A4986FB2216D8CF2CFD06F500AB@XMB-BGL-417.cisco.com> <07465C1D981ABC41A344374066AE1A2C38B006ADB8@TLVMBX01.nice.com> From: "Ram Mohan R (rmohanr)" To: "Leon Portman" , "Parthasarathi R (partr)" , "Elwell, John" , X-OriginalArrivalTime: 11 Jul 2011 10:56:11.0208 (UTC) FILETIME=[252C9480:01CC3FB9] Subject: Re: [siprec] Comment on metadata-02 - Media Stream X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 10:56:16 -0000 Hi Leon, Please see inline > -----Original Message----- > From: Leon Portman [mailto:Leon.Portman@nice.com] > Sent: Monday, July 11, 2011 4:19 PM > To: Ram Mohan R (rmohanr); Parthasarathi R (partr); Elwell, John; > siprec@ietf.org > Subject: RE: [siprec] Comment on metadata-02 - Media Stream >=20 > Ram Hi >=20 > My concern is not technical implementation but logical meaning. > Metadata XML represents CS: participants, states, medias. It is very > confusing (at least for me) that media is about recording session and > not communication session. However If everybody ok with that, let's go > forward with the current approach. One reason why I want to avoid explicitly saying MS block logically represents media of CS is the media of RS can be different from CS [ possibly due to SRC acting as endpoint and doing transcoding e.t.c]. In such cases it will be confusing to say MS block represents CS media.=20 Current proposed text is " A Media Stream block represents a single RTP session between an SRC and an SRS. Note that, because of possible mixing at the SRC, a Media Stream block does not necessarily represent a single RTP session between CS participants. MS block helps to link participants ( of CS) to its associated Media Streams ( in RS), the properties of which will be carried in RS SDP"" I feel the above text conveys sufficient meaning that the MS block represents media of the participants (who are part of CS) If the text I proposed below is confusing, Please suggest some more edits to make it more clear. Regards, Ram >=20 > Leon > -----Original Message----- > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > Sent: Monday, July 11, 2011 7:00 AM > To: Leon Portman; Parthasarathi R (partr); Elwell, John; > siprec@ietf.org > Subject: RE: [siprec] Comment on metadata-02 - Media Stream >=20 > Hi Leon, >=20 > 1) For the use case where SRC offers a set of streams (say audio and > video) but SRS does chose to record only part of them (say audio only), > the SRC may still continue to send updates for that m-line ( with port > =3D0). > 2) For the use case SRC may not offer all the media types ( of CS) as > it may not have capability to record, the SRC can still send the > initial offer with port 0 in the m=3Dline. >=20 > I remember this was something for which there was no concerns from any > one. In case you see some issues with this approach, Please let us know > the same. > Please refer to one of the mail threads for an earlier discussion on > this topic http://www.ietf.org/mail- > archive/web/siprec/current/msg01304.html >=20 > I would not prefer MS block to represent CS media for just these cases > as it would be duplication at XML level when we have agreed that MS > block represents RS media for all other use-cases. >=20 > Regards, > Ram >=20 > > -----Original Message----- > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > Sent: Sunday, July 10, 2011 3:54 PM > > To: Parthasarathi R (partr); Ram Mohan R (rmohanr); Elwell, John; > > siprec@ietf.org > > Subject: RE: [siprec] Comment on metadata-02 - Media Stream > > > > Ram Hi > > I agree that we can indicate it via RS SDP but I don't think it will > > be most elegant solution. > > What is from your point of view, is the main compelling reason for > MS > > block to represent RS media and not CS media? > > > > Regards > > > > Leon > > > > -----Original Message----- > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > Sent: Sunday, July 10, 2011 12:02 PM > > To: Leon Portman; Ram Mohan R (rmohanr); Elwell, John; > siprec@ietf.org > > Subject: RE: [siprec] Comment on metadata-02 - Media Stream > > > > Leon, > > > > As you mentioned, it is possible to indicate special case of "not > > recorded" through RS SDP as port value containing 0 in the media > ("m=3D" > > line) level. Actual RTP session is NULL for those MS. In case you > feel > > that this definition has to be reworded, Pls suggest the text. > > > > Thanks > > Partha > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Leon Portman > > > Sent: Sunday, July 10, 2011 1:28 PM > > > To: Ram Mohan R (rmohanr); Elwell, John; siprec@ietf.org > > > Subject: Re: [siprec] Comment on metadata-02 - Media Stream > > > > > > Ram Hi > > > > > > But do we want to link participant to RS media or Participant media > > to > > > RS media? What will be the logic to reconstruct participant media > > > sessions ( I am not talking about codecs and ports but types of the > > > media for example). Specially ones that are not recorded or > offered. > > I > > > remember that we had discussion to support it. > > > > > > Regards > > > > > > Leon > > > > > > -----Original Message----- > > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > > Sent: Friday, July 08, 2011 7:30 PM > > > To: Elwell, John; Leon Portman; siprec@ietf.org > > > Subject: RE: [siprec] Comment on metadata-02 - Media Stream > > > > > > So I would combine and have the text for MS block as: > > > > > > " A Media Stream block represents a single RTP session between an > SRC > > > and an SRS. Note that, because of possible mixing at the SRC, a > Media > > > Stream block does not necessarily represent a single RTP session > > > between CS participants. MS block helps to link participants ( of > CS) > > > to its associated Media Streams ( in RS), the properties of which > > will > > > be carried in RS SDP" > > > > > > Please let me know if anyone has concerns otherwise I will > > incorporate > > > this text in the next version of draft. > > > > > > Regards, > > > Ram > > > > > > > -----Original Message----- > > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > Sent: Friday, July 08, 2011 6:02 PM > > > > To: Ram Mohan R (rmohanr); Leon Portman; siprec@ietf.org > > > > Subject: RE: [siprec] Comment on metadata-02 - Media Stream > > > > > > > > OK, sounds like a good compromise. > > > > > > > > John > > > > > > > > > -----Original Message----- > > > > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > > > > Sent: 08 July 2011 08:00 > > > > > To: Elwell, John; Leon Portman; siprec@ietf.org > > > > > Subject: RE: [siprec] Comment on metadata-02 - Media Stream > > > > > > > > > > John, > > > > > > > > > > I don't have any such issues with your definition. I think we > can > > > > > add " > > > > > MS block helps to link participants ( of CS) to its > > > associated Media > > > > > Streams ( in RS), the properties of which will be carried > > > in RS SDP" > > > > > to your definition. > > > > > > > > > > I would like to have this line as it clearly says the intention > > > > > /purpose of MS block. > > > > > > > > > > Regards, > > > > > Ram > > > > > > > > > > > -----Original Message----- > > > > > > From: Elwell, John [mailto:john.elwell@siemens- > enterprise.com] > > > > > > Sent: Friday, July 08, 2011 12:20 PM > > > > > > To: Ram Mohan R (rmohanr); Leon Portman; siprec@ietf.org > > > > > > Subject: RE: [siprec] Comment on metadata-02 - Media Stream > > > > > > > > > > > > Ram, > > > > > > > > > > > > In my opinion your proposed definition is too abstract > > > - I think a > > > > > > reader would have a hard time understanding what such an > object > > > > > > represents in the real world. Can you pinpoint your > > > objections to > > > > my > > > > > > proposal? > > > > > > > > > > > > Thanks, > > > > > > > > > > > > John > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > > > > > > Sent: 08 July 2011 05:59 > > > > > > > To: Leon Portman; Elwell, John; siprec@ietf.org > > > > > > > Subject: RE: [siprec] Comment on metadata-02 - Media Stream > > > > > > > > > > > > > > Hello John / Leon, > > > > > > > > > > > > > > Thanks for your comments on MS block in the metadata. I > agree > > > > that > > > > > > the > > > > > > > current text is little confusing. > > > > > > > It is because when we started off with the metadata draft > we > > > > > intended > > > > > > > that MS block represents properties of CS media. > > > > > > > > > > > > > > However after discussions we reached to a consensus that > > > > > MS does not > > > > > > > need to have CS media parameters. > > > > > > > > > > > > > > John's suggestion for definition is > > > > > > > > > > > > > > > Possibly a definition like: > > > > > > > > "A Media Stream block represents a single RTP > > > session between > > > > an > > > > > > SRC > > > > > > > > and an SRS. Note that, because of possible mixing at the > > > > > > > SRC, a Media > > > > > > > > Stream block does not necessarily represent a single RTP > > > > session > > > > > > > > between CS participants." > > > > > > > > > > > > > > My suggestion is > > > > > > > > > > > > > > "An MS block/class represents an entity which helps to link > > > > > > > participants ( of CS) to its associated Media Streams > > > ( in RS), > > > > > > > the > > > > > properties of > > > > > > > which will be carried in RS SDP". > > > > > > > > > > > > > > Please suggest if this text works fine. If not > refine/suggest > > > > > > > improvements. > > > > > > > > > > > > > > Regards, > > > > > > > Ram > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: siprec-bounces@ietf.org > > > > > [mailto:siprec-bounces@ietf.org] On > > > > > > > > Behalf Of Leon Portman > > > > > > > > Sent: Thursday, July 07, 2011 7:20 PM > > > > > > > > To: Elwell, John; siprec@ietf.org > > > > > > > > Subject: Re: [siprec] Comment on metadata-02 - Media > Stream > > > > > > > > > > > > > > > > Actually I was expecting (a) as well. And it should point > > to > > > > the > > > > > > > > relevant media lines in RS SDP. If two or more Media > > > > > > > Streams point to > > > > > > > > the same RS SDP m-line label, then we have mixing use > case > > > > > > > > > > > > > > > > So something like this: CS MS (1:1)- > XML MS -> > > > (N:1) -> RS > > > > MS > > > > > > > > > > > > > > > > Leon > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: siprec-bounces@ietf.org > > > > > [mailto:siprec-bounces@ietf.org] On > > > > > > > > Behalf Of Elwell, John > > > > > > > > Sent: Thursday, July 07, 2011 4:36 PM > > > > > > > > To: siprec@ietf.org > > > > > > > > Subject: [siprec] Comment on metadata-02 - Media Stream > > > > > > > > > > > > > > > > In section 6.5, Media Stream seems to be defined as > > follows: > > > > > > > > "A Media Stream block MUST have properties of media as > seen > > > > > > > by SRC and > > > > > > > > sent to SRS." > > > > > > > > Ignoring the possibly inappropriate RFC 2119 > > > language, I don't > > > > > > think > > > > > > > > this clearly defines whether: > > > > > > > > a) this represents a medium of the CS (i.e., > corresponding > > > > > > > to a media > > > > > > > > description in the CS SDP); or > > > > > > > > b) this represents a medium of the RS (i.e., > corresponding > > > > > > > to a media > > > > > > > > description in the RS SDP). > > > > > > > > > > > > > > > > Both of these are "seen by SRC". There need not be a 1:1 > > > > > > > relationship > > > > > > > > between the two, and hence we need to make it clear > > > which it > > > > > > > > represents. > > > > > > > > > > > > > > > > Although personally I had expected a), a couple of > > > threads in > > > > > > recent > > > > > > > > months have seemed to indicate b) is the general > consensus. > > > > > > > > > > > > > > > > Possibly a definition like: > > > > > > > > "A Media Stream block represents a single RTP > > > session between > > > > an > > > > > > SRC > > > > > > > > and an SRS. Note that, because of possible mixing at the > > > > > > > SRC, a Media > > > > > > > > Stream block does not necessarily represent a single RTP > > > > session > > > > > > > > between CS participants." > > > > > > > > > > > > > > > > However, if we accept this principle, I wonder what the > > > > > > > Start Time and > > > > > > > > End Time attributes mean. The start and end of an RS RTP > > > > session > > > > > > > > correspond to the relevant offer-answer exchanges, so > they > > > > don't > > > > > > > really > > > > > > > > need to be in XML. So I suspect I still haven't drilled > > > > > > > down into the > > > > > > > > real meaning of MS sufficiently. > > > > > > > > > > > > > > > > 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 Leon.Portman@nice.com Mon Jul 11 05:53: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 8F08B21F85F0 for ; Mon, 11 Jul 2011 05:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.158 X-Spam-Level: X-Spam-Status: No, score=-2.158 tagged_above=-999 required=5 tests=[AWL=-0.159, BAYES_00=-2.599, J_CHICKENPOX_14=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 fpuTbuYTKWm2 for ; Mon, 11 Jul 2011 05:53:12 -0700 (PDT) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id 87C5221F858A for ; Mon, 11 Jul 2011 05:53:11 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.15]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Mon, 11 Jul 2011 15:53:10 +0300 From: Leon Portman To: "Ram Mohan R (rmohanr)" , "Parthasarathi R (partr)" , "Elwell, John" , "siprec@ietf.org" Date: Mon, 11 Jul 2011 15:53:09 +0300 Thread-Topic: [siprec] Comment on metadata-02 - Media Stream Thread-Index: Acw8qtezJdNopWF7RZqONH6e5tBRLgAAYkSAAB8nk4AABHr7gAAAZo/QAAucg6AACEOLMABSr+wAAAIIyiAAAxLScAAkEbZgAA8O9BAAACc8AAAEP4pw Message-ID: <07465C1D981ABC41A344374066AE1A2C38B006AEED@TLVMBX01.nice.com> References: <07465C1D981ABC41A344374066AE1A2C38AFE9BB98@TLVMBX01.nice.com><35BCE99A477D6A4986FB2216D8CF2CFD06F4FD89@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD06F4FE0B@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD06F4FF85@XMB-BGL-417.cisco.com> <07465C1D981ABC41A344374066AE1A2C38B006A89D@TLVMBX01.nice.com> <07465C1D981ABC41A344374066AE1A2C38B006A957@TLVMBX01.nice.com> <35BCE99A477D6A4986FB2216D8CF2CFD06F500AB@XMB-BGL-417.cisco.com> <07465C1D981ABC41A344374066AE1A2C38B006ADB8@TLVMBX01.nice.com> <35BCE99A477D6A4986FB2216D8CF2CFD06F502A0@XMB-BGL-417.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD06F502A0@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] Comment on metadata-02 - Media Stream X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 12:53:13 -0000 I am ok with below. Let's move forward. Thank you for the explanation. Leon -----Original Message----- From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com]=20 Sent: Monday, July 11, 2011 1:56 PM To: Leon Portman; Parthasarathi R (partr); Elwell, John; siprec@ietf.org Subject: RE: [siprec] Comment on metadata-02 - Media Stream Hi Leon, Please see inline > -----Original Message----- > From: Leon Portman [mailto:Leon.Portman@nice.com] > Sent: Monday, July 11, 2011 4:19 PM > To: Ram Mohan R (rmohanr); Parthasarathi R (partr); Elwell, John;=20 > siprec@ietf.org > Subject: RE: [siprec] Comment on metadata-02 - Media Stream >=20 > Ram Hi >=20 > My concern is not technical implementation but logical meaning. > Metadata XML represents CS: participants, states, medias. It is very=20 > confusing (at least for me) that media is about recording session and=20 > not communication session. However If everybody ok with that, let's go=20 > forward with the current approach. One reason why I want to avoid explicitly saying MS block logically represe= nts media of CS is the media of RS can be different from CS [ possibly due = to SRC acting as endpoint and doing transcoding e.t.c]. In such cases it wi= ll be confusing to say MS block represents CS media.=20 Current proposed text is " A Media Stream block represents a single RTP session between an SRC and a= n SRS. Note that, because of possible mixing at the SRC, a Media Stream blo= ck does not necessarily represent a single RTP session between CS participa= nts. MS block helps to link participants ( of CS) to its associated Media S= treams ( in RS), the properties of which will be carried in RS SDP"" I feel the above text conveys sufficient meaning that the MS block represen= ts media of the participants (who are part of CS) If the text I proposed below is confusing, Please suggest some more edits t= o make it more clear. Regards, Ram >=20 > Leon > -----Original Message----- > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > Sent: Monday, July 11, 2011 7:00 AM > To: Leon Portman; Parthasarathi R (partr); Elwell, John;=20 > siprec@ietf.org > Subject: RE: [siprec] Comment on metadata-02 - Media Stream >=20 > Hi Leon, >=20 > 1) For the use case where SRC offers a set of streams (say audio and > video) but SRS does chose to record only part of them (say audio only), > the SRC may still continue to send updates for that m-line ( with port=20 > =3D0). > 2) For the use case SRC may not offer all the media types ( of CS) as=20 > it may not have capability to record, the SRC can still send the=20 > initial offer with port 0 in the m=3Dline. >=20 > I remember this was something for which there was no concerns from any=20 > one. In case you see some issues with this approach, Please let us know > the same. > Please refer to one of the mail threads for an earlier discussion on=20 > this topic http://www.ietf.org/mail-=20 > archive/web/siprec/current/msg01304.html >=20 > I would not prefer MS block to represent CS media for just these cases=20 > as it would be duplication at XML level when we have agreed that MS=20 > block represents RS media for all other use-cases. >=20 > Regards, > Ram >=20 > > -----Original Message----- > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > Sent: Sunday, July 10, 2011 3:54 PM > > To: Parthasarathi R (partr); Ram Mohan R (rmohanr); Elwell, John;=20 > > siprec@ietf.org > > Subject: RE: [siprec] Comment on metadata-02 - Media Stream > > > > Ram Hi > > I agree that we can indicate it via RS SDP but I don't think it will > > be most elegant solution. > > What is from your point of view, is the main compelling reason for > MS > > block to represent RS media and not CS media? > > > > Regards > > > > Leon > > > > -----Original Message----- > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > Sent: Sunday, July 10, 2011 12:02 PM > > To: Leon Portman; Ram Mohan R (rmohanr); Elwell, John; > siprec@ietf.org > > Subject: RE: [siprec] Comment on metadata-02 - Media Stream > > > > Leon, > > > > As you mentioned, it is possible to indicate special case of "not=20 > > recorded" through RS SDP as port value containing 0 in the media > ("m=3D" > > line) level. Actual RTP session is NULL for those MS. In case you > feel > > that this definition has to be reworded, Pls suggest the text. > > > > Thanks > > Partha > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org > > > [mailto:siprec-bounces@ietf.org] On Behalf Of Leon Portman > > > Sent: Sunday, July 10, 2011 1:28 PM > > > To: Ram Mohan R (rmohanr); Elwell, John; siprec@ietf.org > > > Subject: Re: [siprec] Comment on metadata-02 - Media Stream > > > > > > Ram Hi > > > > > > But do we want to link participant to RS media or Participant media > > to > > > RS media? What will be the logic to reconstruct participant media=20 > > > sessions ( I am not talking about codecs and ports but types of the > > > media for example). Specially ones that are not recorded or > offered. > > I > > > remember that we had discussion to support it. > > > > > > Regards > > > > > > Leon > > > > > > -----Original Message----- > > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > > Sent: Friday, July 08, 2011 7:30 PM > > > To: Elwell, John; Leon Portman; siprec@ietf.org > > > Subject: RE: [siprec] Comment on metadata-02 - Media Stream > > > > > > So I would combine and have the text for MS block as: > > > > > > " A Media Stream block represents a single RTP session between an > SRC > > > and an SRS. Note that, because of possible mixing at the SRC, a > Media > > > Stream block does not necessarily represent a single RTP session=20 > > > between CS participants. MS block helps to link participants ( of > CS) > > > to its associated Media Streams ( in RS), the properties of which > > will > > > be carried in RS SDP" > > > > > > Please let me know if anyone has concerns otherwise I will > > incorporate > > > this text in the next version of draft. > > > > > > Regards, > > > Ram > > > > > > > -----Original Message----- > > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > Sent: Friday, July 08, 2011 6:02 PM > > > > To: Ram Mohan R (rmohanr); Leon Portman; siprec@ietf.org > > > > Subject: RE: [siprec] Comment on metadata-02 - Media Stream > > > > > > > > OK, sounds like a good compromise. > > > > > > > > John > > > > > > > > > -----Original Message----- > > > > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > > > > Sent: 08 July 2011 08:00 > > > > > To: Elwell, John; Leon Portman; siprec@ietf.org > > > > > Subject: RE: [siprec] Comment on metadata-02 - Media Stream > > > > > > > > > > John, > > > > > > > > > > I don't have any such issues with your definition. I think we > can > > > > > add " > > > > > MS block helps to link participants ( of CS) to its > > > associated Media > > > > > Streams ( in RS), the properties of which will be carried > > > in RS SDP" > > > > > to your definition. > > > > > > > > > > I would like to have this line as it clearly says the intention > > > > > /purpose of MS block. > > > > > > > > > > Regards, > > > > > Ram > > > > > > > > > > > -----Original Message----- > > > > > > From: Elwell, John [mailto:john.elwell@siemens- > enterprise.com] > > > > > > Sent: Friday, July 08, 2011 12:20 PM > > > > > > To: Ram Mohan R (rmohanr); Leon Portman; siprec@ietf.org > > > > > > Subject: RE: [siprec] Comment on metadata-02 - Media Stream > > > > > > > > > > > > Ram, > > > > > > > > > > > > In my opinion your proposed definition is too abstract > > > - I think a > > > > > > reader would have a hard time understanding what such an > object > > > > > > represents in the real world. Can you pinpoint your > > > objections to > > > > my > > > > > > proposal? > > > > > > > > > > > > Thanks, > > > > > > > > > > > > John > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > > > > > > Sent: 08 July 2011 05:59 > > > > > > > To: Leon Portman; Elwell, John; siprec@ietf.org > > > > > > > Subject: RE: [siprec] Comment on metadata-02 - Media Stream > > > > > > > > > > > > > > Hello John / Leon, > > > > > > > > > > > > > > Thanks for your comments on MS block in the metadata. I > agree > > > > that > > > > > > the > > > > > > > current text is little confusing. > > > > > > > It is because when we started off with the metadata draft > we > > > > > intended > > > > > > > that MS block represents properties of CS media. > > > > > > > > > > > > > > However after discussions we reached to a consensus that > > > > > MS does not > > > > > > > need to have CS media parameters. > > > > > > > > > > > > > > John's suggestion for definition is > > > > > > > > > > > > > > > Possibly a definition like: > > > > > > > > "A Media Stream block represents a single RTP > > > session between > > > > an > > > > > > SRC > > > > > > > > and an SRS. Note that, because of possible mixing at the > > > > > > > SRC, a Media > > > > > > > > Stream block does not necessarily represent a single RTP > > > > session > > > > > > > > between CS participants." > > > > > > > > > > > > > > My suggestion is > > > > > > > > > > > > > > "An MS block/class represents an entity which helps to link > > > > > > > participants ( of CS) to its associated Media Streams > > > ( in RS), > > > > > > > the > > > > > properties of > > > > > > > which will be carried in RS SDP". > > > > > > > > > > > > > > Please suggest if this text works fine. If not > refine/suggest > > > > > > > improvements. > > > > > > > > > > > > > > Regards, > > > > > > > Ram > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: siprec-bounces@ietf.org > > > > > [mailto:siprec-bounces@ietf.org] On > > > > > > > > Behalf Of Leon Portman > > > > > > > > Sent: Thursday, July 07, 2011 7:20 PM > > > > > > > > To: Elwell, John; siprec@ietf.org > > > > > > > > Subject: Re: [siprec] Comment on metadata-02 - Media > Stream > > > > > > > > > > > > > > > > Actually I was expecting (a) as well. And it should point > > to > > > > the > > > > > > > > relevant media lines in RS SDP. If two or more Media > > > > > > > Streams point to > > > > > > > > the same RS SDP m-line label, then we have mixing use > case > > > > > > > > > > > > > > > > So something like this: CS MS (1:1)- > XML MS -> > > > (N:1) -> RS > > > > MS > > > > > > > > > > > > > > > > Leon > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: siprec-bounces@ietf.org > > > > > [mailto:siprec-bounces@ietf.org] On > > > > > > > > Behalf Of Elwell, John > > > > > > > > Sent: Thursday, July 07, 2011 4:36 PM > > > > > > > > To: siprec@ietf.org > > > > > > > > Subject: [siprec] Comment on metadata-02 - Media Stream > > > > > > > > > > > > > > > > In section 6.5, Media Stream seems to be defined as > > follows: > > > > > > > > "A Media Stream block MUST have properties of media as > seen > > > > > > > by SRC and > > > > > > > > sent to SRS." > > > > > > > > Ignoring the possibly inappropriate RFC 2119 > > > language, I don't > > > > > > think > > > > > > > > this clearly defines whether: > > > > > > > > a) this represents a medium of the CS (i.e., > corresponding > > > > > > > to a media > > > > > > > > description in the CS SDP); or > > > > > > > > b) this represents a medium of the RS (i.e., > corresponding > > > > > > > to a media > > > > > > > > description in the RS SDP). > > > > > > > > > > > > > > > > Both of these are "seen by SRC". There need not be a 1:1 > > > > > > > relationship > > > > > > > > between the two, and hence we need to make it clear > > > which it > > > > > > > > represents. > > > > > > > > > > > > > > > > Although personally I had expected a), a couple of > > > threads in > > > > > > recent > > > > > > > > months have seemed to indicate b) is the general > consensus. > > > > > > > > > > > > > > > > Possibly a definition like: > > > > > > > > "A Media Stream block represents a single RTP > > > session between > > > > an > > > > > > SRC > > > > > > > > and an SRS. Note that, because of possible mixing at the > > > > > > > SRC, a Media > > > > > > > > Stream block does not necessarily represent a single RTP > > > > session > > > > > > > > between CS participants." > > > > > > > > > > > > > > > > However, if we accept this principle, I wonder what the > > > > > > > Start Time and > > > > > > > > End Time attributes mean. The start and end of an RS RTP > > > > session > > > > > > > > correspond to the relevant offer-answer exchanges, so > they > > > > don't > > > > > > > really > > > > > > > > need to be in XML. So I suspect I still haven't drilled > > > > > > > down into the > > > > > > > > real meaning of MS sufficiently. > > > > > > > > > > > > > > > > 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 Mon Jul 11 06:35: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 DDF5C21F8BA0 for ; Mon, 11 Jul 2011 06:35:37 -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 ALIqS9KWcRnC for ; Mon, 11 Jul 2011 06:35:37 -0700 (PDT) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfa.amsl.com (Postfix) with SMTP id A608C21F8B97 for ; Mon, 11 Jul 2011 06:35:36 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1310391323!41330122!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 3787 invoked from network); 11 Jul 2011 13:35:23 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-6.tower-27.messagelabs.com with SMTP; 11 Jul 2011 13:35:23 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id C7F7E1EB8402; Mon, 11 Jul 2011 15:35:34 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Mon, 11 Jul 2011 15:35:23 +0200 From: "Elwell, John" To: "Ram Mohan R (rmohanr)" , "siprec@ietf.org" Date: Mon, 11 Jul 2011 15:35:21 +0200 Thread-Topic: [siprec] What does Start / Stop time attributes signify for Media Stream block ? [ was RE: Comment on metadata-02 - Media Stream ] Thread-Index: Acw8qtezJdNopWF7RZqONH6e5tBRLgA3uo+QAJEggLA= Message-ID: References: <35BCE99A477D6A4986FB2216D8CF2CFD06F4FF83@XMB-BGL-417.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD06F4FF83@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] What does Start / Stop time attributes signify for Media Stream block ? [ was RE: Comment on metadata-02 - Media Stream ] X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 13:35:38 -0000 =20 > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Ram Mohan R (rmohanr) > Sent: 08 July 2011 17:25 > To: siprec@ietf.org > Subject: [siprec] What does Start / Stop time attributes=20 > signify for Media Stream block ? [ was RE: Comment on=20 > metadata-02 - Media Stream ] >=20 > Hello John, >=20 > Regarding your other question on Start/Stop time attribute in MS block >=20 > The definition as per the current draft is: > Start Time - Represents Media Start time at SRC. > End Time - Represents Media End time at SRC. >=20 > We had a long discussion couple of months back on the Start/Stop time > attribute and what it means. It was a long thread with title=20 > " [siprec] > start/stop times & the metamodel". I just went through the=20 > thread again > to refresh my memory. It looks we *did not* reach to a *concrete* > conclusion even though there were some general agreements. >=20 > Refer to parts of mail thread here > http://www.ietf.org/mail-archive/web/siprec/current/msg01850.html > http://www.ietf.org/mail-archive/web/siprec/current/msg01814.html >=20 > To summarize these are some of the salient points we discussed at that > time: > - the start time of a media stream is the time (according to=20 > the CS) of > the first participant to a new media stream, and the stop time as the > time that the last participant leaves the media stream. [JRE] Phrased this way, it sounds like an MS object represents a CS media s= tream, but I thought from recent discussions you were saying an MS object r= epresents an RS Media Stream (as described in RS SDP). So consider the case of persistent recording. The RS SDP m-line starts when= persistent recording starts (e.g., start of RS) and finishes when persiste= nt recording stops (e.g., end of RS). So if the MS object represents an RS = Media Stream, this implies the MS object's start time corresponds to the st= art of persistent recording and its end time corresponds to the end of pers= istent recording. They have nothing to do with when participants join or le= ave. As soon as you tie it to when the first participant joins / the last p= articipant ends, it seems to me the MS object must relate to the CS media s= tream. John (as individual) > - There were discussions around how SRC derives this time (is it based > on wall clock time of SRC e.t.c) > - There was also discussions on what is the significance of start/stop > time w.r.t different RTP models (translator, endpoint) and how SRS may > want to use it for synchronization and playback >=20 > Now would be a good time to re-start the discussion again so=20 > that we can > conclude at least in IETF 81. >=20 > Regards, > Ram >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Elwell, John > > Sent: Thursday, July 07, 2011 7:06 PM > > To: siprec@ietf.org > > Subject: [siprec] Comment on metadata-02 - Media Stream > >=20 > > In section 6.5, Media Stream seems to be defined as follows: > > "A Media Stream block MUST have properties of media as seen=20 > by SRC and > > sent to SRS." > > Ignoring the possibly inappropriate RFC 2119 language, I don't think > > this clearly defines whether: > > a) this represents a medium of the CS (i.e., corresponding=20 > to a media > > description in the CS SDP); or > > b) this represents a medium of the RS (i.e., corresponding=20 > to a media > > description in the RS SDP). > >=20 > > Both of these are "seen by SRC". There need not be a 1:1=20 > relationship > > between the two, and hence we need to make it clear which it > > represents. > >=20 > > Although personally I had expected a), a couple of threads in recent > > months have seemed to indicate b) is the general consensus. > >=20 > > Possibly a definition like: > > "A Media Stream block represents a single RTP session between an SRC > > and an SRS. Note that, because of possible mixing at the=20 > SRC, a Media > > Stream block does not necessarily represent a single RTP session > > between CS participants." > >=20 > > However, if we accept this principle, I wonder what the=20 > Start Time and > > End Time attributes mean. The start and end of an RS RTP session > > correspond to the relevant offer-answer exchanges, so they don't > really > > need to be in XML. So I suspect I still haven't drilled=20 > down into the > > real meaning of MS sufficiently. > >=20 > > John (as individual) > >=20 > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > = From pkyzivat@alum.mit.edu Mon Jul 11 10:20: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 9025711E8125 for ; Mon, 11 Jul 2011 10:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.151, 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 gRJM8DdXUwd9 for ; Mon, 11 Jul 2011 10:20:18 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by ietfa.amsl.com (Postfix) with ESMTP id D76E311E8123 for ; Mon, 11 Jul 2011 10:20:16 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta12.westchester.pa.mail.comcast.net with comcast id 6hL71h0020EZKEL5ChLH9P; Mon, 11 Jul 2011 17:20:17 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta01.westchester.pa.mail.comcast.net with comcast id 6hLG1h00A0tdiYw3MhLG88; Mon, 11 Jul 2011 17:20:16 +0000 Message-ID: <4E1B30CD.9020008@alum.mit.edu> Date: Mon, 11 Jul 2011 13:20:13 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "siprec@ietf.org" References: <20110709161529.3715.64641.idtracker@ietfa.amsl.com> In-Reply-To: <20110709161529.3715.64641.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] I-D Action: draft-ietf-siprec-metadata-03.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, 11 Jul 2011 17:20:18 -0000 This superficial change just acknowledges that I'm no longer working for Cisco. I will continue to be involved independently while I decide what to do next. I expect to continue to be involved in one capacity or another. Thanks, Paul On 7/9/11 12:15 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP Recording Working Group of the IETF. > > Title : Session Initiation Protocol (SIP) Recording Metadata > Author(s) : Ram Mohan Ravindranath > Parthasarathi Ravindran > Paul Kyzivat > Filename : draft-ietf-siprec-metadata-03.txt > Pages : 34 > Date : 2011-07-09 > > Session recording is a critical requirement in many communications > environments such as call centers and financial trading. In some of > these environments, all calls must be recorded for regulatory, > compliance, and consumer protection reasons. Recording of a session > is typically performed by sending a copy of a media stream to a > recording device. This document describes the metadata model as > viewed by Session Recording Server(SRS) and the Recording metadata > format. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-siprec-metadata-03.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-metadata-03.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 Henry.Lum@alcatel-lucent.com Mon Jul 11 14:12: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 E06CE11E820F for ; Mon, 11 Jul 2011 14:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.358 X-Spam-Level: X-Spam-Status: No, score=-6.358 tagged_above=-999 required=5 tests=[AWL=0.240, 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 tT725gFMlNFo for ; Mon, 11 Jul 2011 14:12:34 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id D0A1311E8193 for ; Mon, 11 Jul 2011 14:12:33 -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 p6BLCW0F012488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 11 Jul 2011 16:12:32 -0500 (CDT) Received: from relay-out1.dc.genesyslab.com (relay-out1.dc.genesyslab.com [172.22.68.187]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p6BLCUC4024347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 11 Jul 2011 16:12: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 p6BLCT3E007452; Mon, 11 Jul 2011 14:12:29 -0700 (PDT) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.93]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 11 Jul 2011 14:12:29 -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_01CC400F.3D6D1AAA" Date: Mon, 11 Jul 2011 14:12:29 -0700 Message-ID: <059AF07365DC474393A19A3AF187DF7407480790@NAHALD.us.int.genesyslab.com> In-Reply-To: <07465C1D981ABC41A344374066AE1A2C38AFE9BBAB@TLVMBX01.nice.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Caller preference information in Metadata Thread-Index: Acw8nlS7CXumifrDQ9SGZ9au5tuPnQADYI7gAABYULAAAHB/MADYDkIg References: <07465C1D981ABC41A344374066AE1A2C38AFE9BB8A@TLVMBX01.nice.com> <07465C1D981ABC41A344374066AE1A2C38AFE9BBAB@TLVMBX01.nice.com> From: "Henry Lum" To: "Leon Portman" , "Parthasarathi R (partr)" , X-OriginalArrivalTime: 11 Jul 2011 21:12:29.0236 (UTC) FILETIME=[3DCBDF40:01CC400F] 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] Caller preference information in 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, 11 Jul 2011 21:12:35 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC400F.3D6D1AAA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1, it would be useful to relay this information to SRS. =20 From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Leon Portman Sent: Thursday, July 07, 2011 10:06 AM To: Parthasarathi R (partr); siprec@ietf.org Subject: Re: [siprec] Caller preference information in Metadata =20 It is important distinction (talking to IVR vs person). We should have a way to relay this info to SRS =20 Leon =20 From: Parthasarathi R (partr) [mailto:partr@cisco.com]=20 Sent: Thursday, July 07, 2011 5:05 PM To: Leon Portman; siprec@ietf.org Subject: RE: Caller preference information in Metadata =20 Leon, =20 I agree with you that it is not stored currently. I asked this question because there was an earlier discussion wherein participant has to be identified as normal user or media server. Paul, Ram and myself discussed internally and thought that it would be better to have generic caller preference rather than specific single "automata" parameter. I forget to continue the mail thread in SIPREC alias, so initiated after a long time.=20 =20 This attribute shall be added as an optional which helps for better interop in case future application uses this attribute. =20 In case everyone feels that this attribute will never be used, I'm fine with it. =20 Thanks Partha =20 ________________________________ From: Leon Portman [mailto:Leon.Portman@nice.com]=20 Sent: Thursday, July 07, 2011 7:15 PM To: Parthasarathi R (partr); siprec@ietf.org Subject: RE: Caller preference information in Metadata Partha Hi =20 Today we are not receive and store this information. Is it widely accepted?=20 =20 Leon =20 From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi R (partr) Sent: Thursday, July 07, 2011 3:07 PM To: siprec@ietf.org Subject: [siprec] Caller preference information in Metadata =20 Hi all, =20 Caller preference (RFC 3841) information about CS is possible to be passed in extension data of participant. The caller preference like "automata" shall be passed in SIPREC metadata itself in case folks are interested. Please let me know whether "caller preference" attribute shall be added under participant block. =20 Thanks Partha =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_01CC400F.3D6D1AAA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1, it would be useful to relay this information to SRS.

 

From: siprec-boun= ces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Leon Portman
Sent: Thursday, July 07, 2011 10:06 AM
To: Parthasarathi R (partr); siprec@ietf.org
Subject: Re: [siprec] Caller preference information in Metadata

 

It is important distinction (talking to IVR vs person). We= should have a way to relay this info to SRS

 

Leon

 

From: Parthasarat= hi R (partr) [mailto:partr@cisco.com]
Sent: Thursday, July 07, 2011 5:05 PM
To: Leon Portman; siprec@ietf.org
Subject: RE: Caller preference information in Metadata<= /span>

 

Leon,

 

I agree with you that it is not stored currently. I asked thi= s question because there was an earlier discussion wherein participant has = to be identified as normal user or media server. Paul, Ram and myself= discussed internally and thought that it would be better to have generic = caller preference rather than specific single "automata" parameter.&nb= sp;I forget to continue the mail thread in SIPREC alias, so initiated after a = long time.

 

This attribute shall be added as an optional which helps for = better interop in case future application uses this attribute.=

 

In case everyone feels that this attribute will never be used= , I'm fine with it.

 

Thanks

Partha

 

From: Leon Portman [mailto:Leon.Portman@nice.= com]
Sent: Thursday, July 07, 2011 7:15 PM
To: Parthasarathi R (partr); si= prec@ietf.org
Subject: RE: Caller preference information in Metadata=

Partha Hi

 

Today we are not receive and store  this information.= Is it widely accepted?

 

Leon

 

From: siprec-bounces@ietf.org [mailto:siprec-bounces@i= etf.org] On Behalf Of Parthasarathi R (partr)
Sent: Thursday, July 07, 2011 3:07 PM
To: siprec@ietf.org
Subject: [siprec] Caller preference information in Metadata

 

Hi all,

 

Caller preference (RFC 3841) information about CS is possible to be passed in extension data of participant. The caller preference like "automata&= quot; shall be passed in SIPREC metadata itself in case folks are interested. P= lease let me know whether "caller preference" attribute shall be adde= d under participant block.

 

Thanks

Partha

 


CONFIDENTIALITY NOTICE: This e-mai= l and any files attached may contain confidential and proprietary informa= tion of Alcatel-Lucent and/or its affiliated entities. Access by the inte= nded recipient only is authorized. Any liability arising from any party a= cting, or refraining from acting, on any information contained in this e-= mail is hereby excluded. If you are not the intended recipient, please no= tify the sender immediately, destroy the original transmission and its at= tachments and do not disclose the contents to any other person, use it fo= r 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 a= ffiliated entities. ------_=_NextPart_001_01CC400F.3D6D1AAA-- From pkyzivat@alum.mit.edu Tue Jul 12 09: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 1BF5121F8CF9 for ; Tue, 12 Jul 2011 09:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, 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 YT9lqzPeGowu for ; Tue, 12 Jul 2011 09:35:33 -0700 (PDT) Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [76.96.27.228]) by ietfa.amsl.com (Postfix) with ESMTP id A468721F8DC1 for ; Tue, 12 Jul 2011 09:35:33 -0700 (PDT) Received: from omta09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by qmta15.emeryville.ca.mail.comcast.net with comcast id 74Yy1h00A0S2fkCAF4bW8v; Tue, 12 Jul 2011 16:35:30 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta09.emeryville.ca.mail.comcast.net with comcast id 74bU1h00U0tdiYw8V4bUjo; Tue, 12 Jul 2011 16:35:29 +0000 Message-ID: <4E1C77D1.2040008@alum.mit.edu> Date: Tue, 12 Jul 2011 12:35:29 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: siprec@ietf.org References: <07465C1D981ABC41A344374066AE1A2C38AFE9BB8A@TLVMBX01.nice.com> In-Reply-To: <07465C1D981ABC41A344374066AE1A2C38AFE9BB8A@TLVMBX01.nice.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] Caller preference information in 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: Tue, 12 Jul 2011 16:35:34 -0000 On 7/7/11 9:44 AM, Leon Portman wrote: > Partha Hi > > Today we are not receive and store this information. Is it widely accepted? As I noted earlier, there is a difference between callee-capability info (rfc3840) and caller-preference info (rfc3841), though they are often talked about as one thing. Its not evident to me that caller preference info is very relevant. It could influence what UAS ends up in a call, but that isn't so relevant to recording. The callee caps stuff goes two places: in registered contacts, and in contacts used to establish dialogs. Again, the registered contacts probably aren't of interest, and aren't available in any case. The callee caps in dialog contacts can be significant. For instance, the isFocus capability/tag can be quite interesting. I think we ought to make them available. Thanks, Paul > Leon > > *From:*siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] *On > Behalf Of *Parthasarathi R (partr) > *Sent:* Thursday, July 07, 2011 3:07 PM > *To:* siprec@ietf.org > *Subject:* [siprec] Caller preference information in Metadata > > Hi all, > > Caller preference (RFC 3841) information about CS is possible to be > passed in extension data of participant. The caller preference like > "automata" shall be passed in SIPREC metadata itself in case folks are > interested. Please let me know whether "caller preference" attribute > shall be added under participant block. > > Thanks > > Partha > > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From partr@cisco.com Tue Jul 12 10:22: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 28EC121F8BB6 for ; Tue, 12 Jul 2011 10:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.32 X-Spam-Level: X-Spam-Status: No, score=-10.32 tagged_above=-999 required=5 tests=[AWL=0.279, 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 nA-F2PDuB5HA for ; Tue, 12 Jul 2011 10:22:32 -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 F078721F8BFF for ; Tue, 12 Jul 2011 10:22:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=2658; q=dns/txt; s=iport; t=1310491352; x=1311700952; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=q/uh/RtoSDrxe/5dk7Nzk8OS7IBnNCz5SzTAeQj7KY0=; b=jgFW/uy53s/peYAkNJQvch0HtaUAT1rjPiz7M/jjQyvl2QzYb7xSikqt 5nz0LJfrqlG6OrbzN0Xa+Xx8HWxw+sn0pXVEtWbTzwHXZptgURx6GgN6R r6QGFCmN8HcF6szaX+kwYoprluC09YrCSR8rf9oNRJtlY0l6ikzE1Vq+M 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAALuBHE5Io8US/2dsb2JhbABTEJdljzx3rHGeE4VbXwSHT5AViww/ X-IronPort-AV: E=Sophos;i="4.65,521,1304294400"; d="scan'208";a="101670320" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-1.cisco.com with ESMTP; 12 Jul 2011 17:22:30 +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 p6CHMTV3001851; Tue, 12 Jul 2011 17:22:29 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Jul 2011 22:52:29 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Jul 2011 22:52:24 +0530 Message-ID: In-Reply-To: <4E1C77D1.2040008@alum.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Caller preference information in Metadata Thread-Index: AcxAsb4IWpSp2H57QQqeSRS9oO0YBgABUfEA References: <07465C1D981ABC41A344374066AE1A2C38AFE9BB8A@TLVMBX01.nice.com> <4E1C77D1.2040008@alum.mit.edu> From: "Parthasarathi R (partr)" To: "Paul Kyzivat" , X-OriginalArrivalTime: 12 Jul 2011 17:22:29.0689 (UTC) FILETIME=[4709DA90:01CC40B8] Subject: Re: [siprec] Caller preference information in 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: Tue, 12 Jul 2011 17:22:36 -0000 Paul, I'm not very sure whether we need both callee capability and caller preference or callee capability will serve the purpose. The reason for my doubt is that Caller participant information may end up as "automata" in contact header which has to be passed across to from SRC to SRS and caller "automata" information to SRS is considered as callee capability or caller preference.=20 Thanks Partha =20 > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Tuesday, July 12, 2011 10:05 PM > To: siprec@ietf.org > Subject: Re: [siprec] Caller preference information in Metadata >=20 > On 7/7/11 9:44 AM, Leon Portman wrote: > > Partha Hi > > > > Today we are not receive and store this information. Is it=20 > widely accepted? >=20 > As I noted earlier, there is a difference between=20 > callee-capability info > (rfc3840) and caller-preference info (rfc3841), though they=20 > are often talked about as one thing. >=20 > Its not evident to me that caller preference info is very=20 > relevant. It could influence what UAS ends up in a call, but=20 > that isn't so relevant to recording. >=20 > The callee caps stuff goes two places: in registered=20 > contacts, and in contacts used to establish dialogs. Again,=20 > the registered contacts probably aren't of interest, and=20 > aren't available in any case. >=20 > The callee caps in dialog contacts can be significant. For=20 > instance, the isFocus capability/tag can be quite=20 > interesting. I think we ought to make them available. >=20 > Thanks, > Paul >=20 > > Leon > > > > *From:*siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] *On=20 > > Behalf Of *Parthasarathi R (partr) > > *Sent:* Thursday, July 07, 2011 3:07 PM > > *To:* siprec@ietf.org > > *Subject:* [siprec] Caller preference information in Metadata > > > > Hi all, > > > > Caller preference (RFC 3841) information about CS is possible to be=20 > > passed in extension data of participant. The caller preference like=20 > > "automata" shall be passed in SIPREC metadata itself in=20 > case folks are=20 > > interested. Please let me know whether "caller preference"=20 > attribute=20 > > shall be added under participant block. > > > > Thanks > > > > Partha > > > > > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec >=20 From pkyzivat@alum.mit.edu Tue Jul 12 10:47: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 9D17721F8E02 for ; Tue, 12 Jul 2011 10:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 bJ-ecYodaEJq for ; Tue, 12 Jul 2011 10:47:45 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by ietfa.amsl.com (Postfix) with ESMTP id 7527E21F8D7E for ; Tue, 12 Jul 2011 10:47:45 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta09.westchester.pa.mail.comcast.net with comcast id 75Lz1h0051uE5Es595nmbL; Tue, 12 Jul 2011 17:47:46 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta16.westchester.pa.mail.comcast.net with comcast id 75nl1h0080tdiYw3c5nlcV; Tue, 12 Jul 2011 17:47:45 +0000 Message-ID: <4E1C88BF.9000001@alum.mit.edu> Date: Tue, 12 Jul 2011 13:47:43 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "Parthasarathi R (partr)" References: <07465C1D981ABC41A344374066AE1A2C38AFE9BB8A@TLVMBX01.nice.com> <4E1C77D1.2040008@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: siprec@ietf.org Subject: Re: [siprec] Caller preference information in 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: Tue, 12 Jul 2011 17:47:49 -0000 On 7/12/11 1:22 PM, Parthasarathi R (partr) wrote: > Paul, > > I'm not very sure whether we need both callee capability and caller > preference or callee capability will serve the purpose. The reason for > my doubt is that Caller participant information may end up as "automata" > in contact header which has to be passed across to from SRC to SRS and > caller "automata" information to SRS is considered as callee capability > or caller preference. Its a capability. The preferences are selection "expressions" applied to capabilities to compute which contact to prefer. Thanks, Paul > Thanks > Partha > >> -----Original Message----- >> From: siprec-bounces@ietf.org >> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: Tuesday, July 12, 2011 10:05 PM >> To: siprec@ietf.org >> Subject: Re: [siprec] Caller preference information in Metadata >> >> On 7/7/11 9:44 AM, Leon Portman wrote: >>> Partha Hi >>> >>> Today we are not receive and store this information. Is it >> widely accepted? >> >> As I noted earlier, there is a difference between >> callee-capability info >> (rfc3840) and caller-preference info (rfc3841), though they >> are often talked about as one thing. >> >> Its not evident to me that caller preference info is very >> relevant. It could influence what UAS ends up in a call, but >> that isn't so relevant to recording. >> >> The callee caps stuff goes two places: in registered >> contacts, and in contacts used to establish dialogs. Again, >> the registered contacts probably aren't of interest, and >> aren't available in any case. >> >> The callee caps in dialog contacts can be significant. For >> instance, the isFocus capability/tag can be quite >> interesting. I think we ought to make them available. >> >> Thanks, >> Paul >> >>> Leon >>> >>> *From:*siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] *On >>> Behalf Of *Parthasarathi R (partr) >>> *Sent:* Thursday, July 07, 2011 3:07 PM >>> *To:* siprec@ietf.org >>> *Subject:* [siprec] Caller preference information in Metadata >>> >>> Hi all, >>> >>> Caller preference (RFC 3841) information about CS is possible to be >>> passed in extension data of participant. The caller preference like >>> "automata" shall be passed in SIPREC metadata itself in >> case folks are >>> interested. Please let me know whether "caller preference" >> attribute >>> shall be added under participant block. >>> >>> Thanks >>> >>> Partha >>> >>> >>> >>> _______________________________________________ >>> siprec mailing list >>> siprec@ietf.org >>> https://www.ietf.org/mailman/listinfo/siprec >> >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >> > From partr@cisco.com Tue Jul 12 22:37: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 18F0821F8BF2 for ; Tue, 12 Jul 2011 22:37:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.338 X-Spam-Level: X-Spam-Status: No, score=-10.338 tagged_above=-999 required=5 tests=[AWL=0.261, 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 7HD3nXO4PRVI for ; Tue, 12 Jul 2011 22:37:48 -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 E43E421F8AC3 for ; Tue, 12 Jul 2011 22:37:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=3805; q=dns/txt; s=iport; t=1310535468; x=1311745068; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=+51EYQK6KsfqUwfmngbKn+jsbI7iK9+2xECBmnwwN30=; b=LULxSdYoiGr/U3ZaIOup9D9qn+A4CA9hc8+t0e247AjyMZhfhkx2ohPb QDgoCE8pP5bO12I/k5wN7WxDqWDde8Gwp5UMh1053cTpT79ffZP9BIsqb I5fryux7+cp7yaICACvva3eLlcL/CJHxD7hCOj1FNvetl1y3Dng8TxG9w E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvMAAP4tHU5Io8UR/2dsb2JhbABTEJdqjz53rVmeFoVbXwSHT5Aaiw0/ X-IronPort-AV: E=Sophos;i="4.65,523,1304294400"; d="scan'208";a="42572302" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-2.cisco.com with ESMTP; 13 Jul 2011 05:37:43 +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 p6D5bgsr003447; Wed, 13 Jul 2011 05:37:42 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Jul 2011 11:07: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: Wed, 13 Jul 2011 11:07:37 +0530 Message-ID: In-Reply-To: <4E1C88BF.9000001@alum.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Caller preference information in Metadata Thread-Index: AcxAu9NZFbjUU9lLSyuUgTI1rRpgfgAYeRFQ References: <07465C1D981ABC41A344374066AE1A2C38AFE9BB8A@TLVMBX01.nice.com> <4E1C77D1.2040008@alum.mit.edu> <4E1C88BF.9000001@alum.mit.edu> From: "Parthasarathi R (partr)" To: "Paul Kyzivat" X-OriginalArrivalTime: 13 Jul 2011 05:37:43.0064 (UTC) FILETIME=[FCA8B180:01CC411E] Cc: siprec@ietf.org Subject: Re: [siprec] Caller preference information in 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, 13 Jul 2011 05:37:49 -0000 Paul, I agree that participant capability (RFC 3840) has to passed across in metadata XML. Please let me know whether adding element within element will serve the purpose. The example metadata xml element structure is as follows: automata Thanks Partha=20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20 > Sent: Tuesday, July 12, 2011 11:18 PM > To: Parthasarathi R (partr) > Cc: siprec@ietf.org > Subject: Re: [siprec] Caller preference information in Metadata >=20 > On 7/12/11 1:22 PM, Parthasarathi R (partr) wrote: > > Paul, > > > > I'm not very sure whether we need both callee capability and caller=20 > > preference or callee capability will serve the purpose. The=20 > reason for=20 > > my doubt is that Caller participant information may end up=20 > as "automata" > > in contact header which has to be passed across to from SRC to SRS=20 > > and caller "automata" information to SRS is considered as callee=20 > > capability or caller preference. >=20 > Its a capability. >=20 > The preferences are selection "expressions" applied to=20 > capabilities to compute which contact to prefer. >=20 > Thanks, > Paul >=20 > > Thanks > > Partha > > > >> -----Original Message----- > >> From: siprec-bounces@ietf.org > >> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > >> Sent: Tuesday, July 12, 2011 10:05 PM > >> To: siprec@ietf.org > >> Subject: Re: [siprec] Caller preference information in Metadata > >> > >> On 7/7/11 9:44 AM, Leon Portman wrote: > >>> Partha Hi > >>> > >>> Today we are not receive and store this information. Is it > >> widely accepted? > >> > >> As I noted earlier, there is a difference between=20 > callee-capability=20 > >> info > >> (rfc3840) and caller-preference info (rfc3841), though=20 > they are often=20 > >> talked about as one thing. > >> > >> Its not evident to me that caller preference info is very=20 > relevant.=20 > >> It could influence what UAS ends up in a call, but that isn't so=20 > >> relevant to recording. > >> > >> The callee caps stuff goes two places: in registered=20 > contacts, and in=20 > >> contacts used to establish dialogs. Again, the registered contacts=20 > >> probably aren't of interest, and aren't available in any case. > >> > >> The callee caps in dialog contacts can be significant. For=20 > instance,=20 > >> the isFocus capability/tag can be quite interesting. I=20 > think we ought=20 > >> to make them available. > >> > >> Thanks, > >> Paul > >> > >>> Leon > >>> > >>> *From:*siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] *On=20 > >>> Behalf Of *Parthasarathi R (partr) > >>> *Sent:* Thursday, July 07, 2011 3:07 PM > >>> *To:* siprec@ietf.org > >>> *Subject:* [siprec] Caller preference information in Metadata > >>> > >>> Hi all, > >>> > >>> Caller preference (RFC 3841) information about CS is=20 > possible to be=20 > >>> passed in extension data of participant. The caller=20 > preference like=20 > >>> "automata" shall be passed in SIPREC metadata itself in > >> case folks are > >>> interested. Please let me know whether "caller preference" > >> attribute > >>> shall be added under participant block. > >>> > >>> 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 >=20 From rmohanr@cisco.com Wed Jul 13 00:06: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 6D13C21F8B21 for ; Wed, 13 Jul 2011 00:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.47 X-Spam-Level: X-Spam-Status: No, score=-10.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 Ru7rTEjtVmnZ for ; Wed, 13 Jul 2011 00:06:36 -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 9C8F221F8B1B for ; Wed, 13 Jul 2011 00:06:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=6373; q=dns/txt; s=iport; t=1310540795; x=1311750395; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=YmSF20Q6HQyRz2vkLJE7PMMiQkwSyx/jfY1Kr55sMxY=; b=f1xv7Gcc9efsq9ygS4inRpPsU6twOhNvSs9uuq+yw+im/aeBFIPiYNYh kagi/1ajj/rkVyjAwLZIn2Bp1yqwsCRV2CU/khdDnqOtbKZ7uYE5kgRXd 5bhrEDfMf0aA5zvpEiRRMLwRns+4YrXRsaVyi1JH6JgWfPWVUM3Tj0D9K k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvMAAP5CHU5Io8UQ/2dsb2JhbABGDZd7jz53rhSeIYMjgjhfBIdPkBqLTA X-IronPort-AV: E=Sophos;i="4.65,523,1304294400"; d="scan'208";a="42587253" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-2.cisco.com with ESMTP; 13 Jul 2011 07:06:32 +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 p6D76Wfx001758; Wed, 13 Jul 2011 07:06:32 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Jul 2011 12:36:32 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Jul 2011 12:36:29 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD07055159@XMB-BGL-417.cisco.com> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] What does Start / Stop time attributes signify for MediaStream block ? [ was RE: Comment on metadata-02 - Media Stream ] Thread-Index: Acw8qtezJdNopWF7RZqONH6e5tBRLgA3uo+QAJEggLAAVxIWgA== References: <35BCE99A477D6A4986FB2216D8CF2CFD06F4FF83@XMB-BGL-417.cisco.com> From: "Ram Mohan R (rmohanr)" To: "Elwell, John" , X-OriginalArrivalTime: 13 Jul 2011 07:06:32.0590 (UTC) FILETIME=[654DD2E0:01CC412B] Subject: Re: [siprec] What does Start / Stop time attributes signify for MediaStream block ? [ was RE: Comment on metadata-02 - Media Stream ] X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 07:06:40 -0000 Hi John, I still don't prefer to have the meaning or identity of MS block as "represents CS media streams" for the same reasons I mentioned to Leon in the other thread as it would create more confusion - http://www.ietf.org/mail-archive/web/siprec/current/msg02240.html Now regarding start/stop time for MS- We have agreed in the last interim meeting to have unique ID for MS. IOW same id shall be permitted to be used in two RS's to indicate it's a same MS. So start/end time shall be arrival of first participant and departure of last participant in case MS is mixed stream. In case MS is single stream, start/end time shall be arrival/departure of corresponding participant. So to summarize the start/stop time for a media-stream may be derived from Participant start/stop time itself. I don't see real need to have this attribute. I would like to hear from others if they see a need to have Start/Stop time attribute for MS block. Regards, Ram > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Monday, July 11, 2011 7:05 PM > To: Ram Mohan R (rmohanr); siprec@ietf.org > Subject: RE: [siprec] What does Start / Stop time attributes signify > for Media Stream block ? [ was RE: Comment on metadata-02 - Media > Stream ] >=20 >=20 >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf Of Ram Mohan R (rmohanr) > > Sent: 08 July 2011 17:25 > > To: siprec@ietf.org > > Subject: [siprec] What does Start / Stop time attributes > > signify for Media Stream block ? [ was RE: Comment on > > metadata-02 - Media Stream ] > > > > Hello John, > > > > Regarding your other question on Start/Stop time attribute in MS > block > > > > The definition as per the current draft is: > > Start Time - Represents Media Start time at SRC. > > End Time - Represents Media End time at SRC. > > > > We had a long discussion couple of months back on the Start/Stop time > > attribute and what it means. It was a long thread with title > > " [siprec] > > start/stop times & the metamodel". I just went through the > > thread again > > to refresh my memory. It looks we *did not* reach to a *concrete* > > conclusion even though there were some general agreements. > > > > Refer to parts of mail thread here > > http://www.ietf.org/mail-archive/web/siprec/current/msg01850.html > > http://www.ietf.org/mail-archive/web/siprec/current/msg01814.html > > > > To summarize these are some of the salient points we discussed at > that > > time: > > - the start time of a media stream is the time (according to > > the CS) of > > the first participant to a new media stream, and the stop time as the > > time that the last participant leaves the media stream. > [JRE] Phrased this way, it sounds like an MS object represents a CS > media stream, but I thought from recent discussions you were saying an > MS object represents an RS Media Stream (as described in RS SDP). > So consider the case of persistent recording. The RS SDP m-line starts > when persistent recording starts (e.g., start of RS) and finishes when > persistent recording stops (e.g., end of RS). So if the MS object > represents an RS Media Stream, this implies the MS object's start time > corresponds to the start of persistent recording and its end time > corresponds to the end of persistent recording. They have nothing to do > with when participants join or leave. As soon as you tie it to when the > first participant joins / the last participant ends, it seems to me the > MS object must relate to the CS media stream. >=20 > John (as individual) >=20 >=20 > > - There were discussions around how SRC derives this time (is it > based > > on wall clock time of SRC e.t.c) > > - There was also discussions on what is the significance of > start/stop > > time w.r.t different RTP models (translator, endpoint) and how SRS > may > > want to use it for synchronization and playback > > > > Now would be a good time to re-start the discussion again so > > that we can > > conclude at least in IETF 81. > > > > Regards, > > Ram > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > > Behalf Of Elwell, John > > > Sent: Thursday, July 07, 2011 7:06 PM > > > To: siprec@ietf.org > > > Subject: [siprec] Comment on metadata-02 - Media Stream > > > > > > In section 6.5, Media Stream seems to be defined as follows: > > > "A Media Stream block MUST have properties of media as seen > > by SRC and > > > sent to SRS." > > > Ignoring the possibly inappropriate RFC 2119 language, I don't > think > > > this clearly defines whether: > > > a) this represents a medium of the CS (i.e., corresponding > > to a media > > > description in the CS SDP); or > > > b) this represents a medium of the RS (i.e., corresponding > > to a media > > > description in the RS SDP). > > > > > > Both of these are "seen by SRC". There need not be a 1:1 > > relationship > > > between the two, and hence we need to make it clear which it > > > represents. > > > > > > Although personally I had expected a), a couple of threads in > recent > > > months have seemed to indicate b) is the general consensus. > > > > > > Possibly a definition like: > > > "A Media Stream block represents a single RTP session between an > SRC > > > and an SRS. Note that, because of possible mixing at the > > SRC, a Media > > > Stream block does not necessarily represent a single RTP session > > > between CS participants." > > > > > > However, if we accept this principle, I wonder what the > > Start Time and > > > End Time attributes mean. The start and end of an RS RTP session > > > correspond to the relevant offer-answer exchanges, so they don't > > really > > > need to be in XML. So I suspect I still haven't drilled > > down into the > > > real meaning of MS sufficiently. > > > > > > John (as individual) > > > > > > _______________________________________________ > > > siprec mailing list > > > siprec@ietf.org > > > https://www.ietf.org/mailman/listinfo/siprec > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > > From john.elwell@siemens-enterprise.com Wed Jul 13 01:15: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 709EA21F8B74 for ; Wed, 13 Jul 2011 01:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.45 X-Spam-Level: X-Spam-Status: No, score=-106.45 tagged_above=-999 required=5 tests=[AWL=0.149, 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 o-OmD+z031mo for ; Wed, 13 Jul 2011 01:15:13 -0700 (PDT) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfa.amsl.com (Postfix) with SMTP id 6144021F8B78 for ; Wed, 13 Jul 2011 01:15:13 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1310544898!40925217!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 31766 invoked from network); 13 Jul 2011 08:14:58 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-7.tower-27.messagelabs.com with SMTP; 13 Jul 2011 08:14:58 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id D66011EB83F4; Wed, 13 Jul 2011 10:15:11 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 13 Jul 2011 10:15:07 +0200 From: "Elwell, John" To: Paul Kyzivat , "siprec@ietf.org" Date: Wed, 13 Jul 2011 10:15:07 +0200 Thread-Topic: [siprec] Format options for unique IDs - INPUT REQUIRED Thread-Index: AcwyfE9X01jfFCBaQgqOYqcpdfoRWAOt+5Pw Message-ID: References: <4E04A13F.8090506@cisco.com> In-Reply-To: <4E04A13F.8090506@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] Format options for unique IDs - INPUT REQUIRED X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 08:15:14 -0000 Although it was in reply to me, I think this list of possibilities proposed= by Paul a few weeks ago should have attracted comment from the rest of the= group, but I don't recall seeing anything. Personally, C) looks attractive= , but I don't have a strong opinion. Would others please express opinions -= it is important to get some sort of closure on this. John =20 > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 24 June 2011 15:38 > To: siprec@ietf.org > Subject: [siprec] Format options for unique IDs >=20 >=20 >=20 > On 6/24/2011 5:58 AM, Elwell, John wrote: >=20 > > - Options for globally unique IDs, along with pros and cons=20 > (Partha to initiate) >=20 > I'm not Partha, but I'll comment. Some possibilities: >=20 > A) A generic URN, with added constraint that equality is > based only on lexical equivalence (as defined in rfc 2141) >=20 > B) UUID URN (rfc 4122) >=20 > C) UUID encoded more densely than the UUID URN > (e.g. radix64 of the binary uuid form defined in 4122) >=20 > Pros/cons of these: >=20 > A) Pro: very flexible for the SRC. It has many options for > how to create and encode IDs. >=20 > Pro: ease of generation, assuming the SRC chooses wisely. >=20 > Con: Difficult for the SRS. It must deal with variable > unbounded length ID. Doesn't easily fit in databases. >=20 > Con: Somewhat inefficient wire encoding: > there is minimum length of "URN:" plus NID (namespace identifier). >=20 > Pro/Con: Wire efficiency varies depending on SRC choices. > Could be very good or very bad, depending on what NID is chosen. >=20 > B) Pro: very flexible for the SRC. 4122 provides multiple ways of > generating the UUID. One of them (the name based one) would > allow generating a UUID from the same strings you might use > for (A), so its at least as flexible as (A). >=20 > Pro: easy of generation. Like (A), but then requires an SHA-1 > computation. So not as easy as (A). >=20 > Pro: Simple for SRS. The UUID can be easily extracted from > the URN and converted to a fixed length (16 bytes) binary value. > That value then can be stored in databases, compared, etc. >=20 > Con: Somewhat inefficient wire encoding. The urn encoding is > 45 bytes. >=20 > Pro: Flexible to future extension to other sorts of URNs > (e.g. (A)) due to the use of the URN syntax. >=20 > C) Pro: very flexible for the SRC. (Identical to (B)) >=20 > Pro: easy of generation. Virtually the same as (B). > (The final textual formatting is different from (B), but > similar (insignificant) computationally.) >=20 > Pro: Simple for SRS. Virtually the same as (B). > (The final textual formatting is different from (B), but > similar (insignificant) computationally.) >=20 > Pro: Efficient wire encoding. > (Radix 64 takes 22 bytes to represent the 16 binary bytes.) >=20 > For the metadata these would probably all be wrapped in XML in=20 > comparable ways, so none has an advantage over another in=20 > that respect. >=20 > Please feel free to propose other alternatives. >=20 > As a specific example, for the UUIDs, one could use the 4122 "name=20 > based" approach, where the "name" is just a binary integer counter. >=20 > Thanks, > Paul >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > = From rmohanr@cisco.com Wed Jul 13 03:03: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 77CBE11E807A for ; Wed, 13 Jul 2011 03:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.479 X-Spam-Level: X-Spam-Status: No, score=-6.479 tagged_above=-999 required=5 tests=[AWL=-3.880, 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 0SCm9GFqv0FP for ; Wed, 13 Jul 2011 03:03:08 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4FAD411E8072 for ; Wed, 13 Jul 2011 03:03:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=4783; q=dns/txt; s=iport; t=1310551388; x=1311760988; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=PsNTvBfqzy50fKnHARIzenznh25m5zcwrfGQzXLgxF4=; b=jsxeksWUiq4Xz0XXNm8+Pe2xhBzL0gwxUdZFX+kdr7iG0bjW1BvErMcS tae3kC3SI4ahOA9H9farzNX4HkdRaVxqWkRhVxZsbQBvYhoSt5nLYUqsv GoSTRF8nvXwJHvAGx8lJWCFnZXDlWCewITUAzz4CB9X3c+GvyW1+Gh7sj Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAADJtHU6rRDoH/2dsb2JhbABUEJdsjz53iHqlGp4chVtfBIdPkBqLDT8 X-IronPort-AV: E=Sophos;i="4.65,524,1304294400"; d="scan'208";a="2473619" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-9.cisco.com with ESMTP; 13 Jul 2011 10:02:56 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6DA20gg028506; Wed, 13 Jul 2011 10:02:55 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, 13 Jul 2011 15:32: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: Wed, 13 Jul 2011 15:32:15 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD07055203@XMB-BGL-417.cisco.com> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Caller preference information in Metadata Thread-Index: AcxAu9NZFbjUU9lLSyuUgTI1rRpgfgAYeRFQAAl7F1A= References: <07465C1D981ABC41A344374066AE1A2C38AFE9BB8A@TLVMBX01.nice.com><4E1C77D1.2040008@alum.mit.edu><4E1C88BF.9000001@alum.mit.edu> From: "Ram Mohan R (rmohanr)" To: "Parthasarathi R (partr)" , "Paul Kyzivat" X-OriginalArrivalTime: 13 Jul 2011 10:02:16.0879 (UTC) FILETIME=[F230A3F0:01CC4143] Cc: siprec@ietf.org Subject: Re: [siprec] Caller preference information in 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, 13 Jul 2011 10:03:12 -0000 Paul / Partha, Would it better to use "characteristic" as the XML element name instead of "capability". As per 3840 definition one difference between capability and characteristic is capability is something that can be negotiated where as characteristic cannot be. IMO since "automata" is a characteristic of a device it is better to have XML element as the "characteristic" Ram > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Parthasarathi R (partr) > Sent: Wednesday, July 13, 2011 11:08 AM > To: Paul Kyzivat > Cc: siprec@ietf.org > Subject: Re: [siprec] Caller preference information in Metadata >=20 > Paul, >=20 > I agree that participant capability (RFC 3840) has to passed across in > metadata XML. Please let me know whether adding element > within element will serve the purpose. The example > metadata xml element structure is as follows: >=20 > > automata > >=20 > Thanks > Partha >=20 > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > > Sent: Tuesday, July 12, 2011 11:18 PM > > To: Parthasarathi R (partr) > > Cc: siprec@ietf.org > > Subject: Re: [siprec] Caller preference information in Metadata > > > > On 7/12/11 1:22 PM, Parthasarathi R (partr) wrote: > > > Paul, > > > > > > I'm not very sure whether we need both callee capability and caller > > > preference or callee capability will serve the purpose. The > > reason for > > > my doubt is that Caller participant information may end up > > as "automata" > > > in contact header which has to be passed across to from SRC to SRS > > > and caller "automata" information to SRS is considered as callee > > > capability or caller preference. > > > > Its a capability. > > > > The preferences are selection "expressions" applied to > > capabilities to compute which contact to prefer. > > > > Thanks, > > Paul > > > > > Thanks > > > Partha > > > > > >> -----Original Message----- > > >> From: siprec-bounces@ietf.org > > >> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > > >> Sent: Tuesday, July 12, 2011 10:05 PM > > >> To: siprec@ietf.org > > >> Subject: Re: [siprec] Caller preference information in Metadata > > >> > > >> On 7/7/11 9:44 AM, Leon Portman wrote: > > >>> Partha Hi > > >>> > > >>> Today we are not receive and store this information. Is it > > >> widely accepted? > > >> > > >> As I noted earlier, there is a difference between > > callee-capability > > >> info > > >> (rfc3840) and caller-preference info (rfc3841), though > > they are often > > >> talked about as one thing. > > >> > > >> Its not evident to me that caller preference info is very > > relevant. > > >> It could influence what UAS ends up in a call, but that isn't so > > >> relevant to recording. > > >> > > >> The callee caps stuff goes two places: in registered > > contacts, and in > > >> contacts used to establish dialogs. Again, the registered contacts > > >> probably aren't of interest, and aren't available in any case. > > >> > > >> The callee caps in dialog contacts can be significant. For > > instance, > > >> the isFocus capability/tag can be quite interesting. I > > think we ought > > >> to make them available. > > >> > > >> Thanks, > > >> Paul > > >> > > >>> Leon > > >>> > > >>> *From:*siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] *On > > >>> Behalf Of *Parthasarathi R (partr) > > >>> *Sent:* Thursday, July 07, 2011 3:07 PM > > >>> *To:* siprec@ietf.org > > >>> *Subject:* [siprec] Caller preference information in Metadata > > >>> > > >>> Hi all, > > >>> > > >>> Caller preference (RFC 3841) information about CS is > > possible to be > > >>> passed in extension data of participant. The caller > > preference like > > >>> "automata" shall be passed in SIPREC metadata itself in > > >> case folks are > > >>> interested. Please let me know whether "caller preference" > > >> attribute > > >>> shall be added under participant block. > > >>> > > >>> Thanks > > >>> > > >>> Partha > > >>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> siprec mailing list > > >>> siprec@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/siprec > > >> > > >> _______________________________________________ > > >> siprec mailing list > > >> siprec@ietf.org > > >> https://www.ietf.org/mailman/listinfo/siprec > > >> > > > > > > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From pkyzivat@alum.mit.edu Wed Jul 13 05:58: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 1BB3721F8566 for ; Wed, 13 Jul 2011 05:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 vigOEWerszRI for ; Wed, 13 Jul 2011 05:58:00 -0700 (PDT) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by ietfa.amsl.com (Postfix) with ESMTP id 80D4421F853A for ; Wed, 13 Jul 2011 05:58:00 -0700 (PDT) Received: from omta05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by qmta01.emeryville.ca.mail.comcast.net with comcast id 7Qx01h0060vp7WLA1Qxxs7; Wed, 13 Jul 2011 12:57:57 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta05.emeryville.ca.mail.comcast.net with comcast id 7Qxz1h00G0tdiYw8RQxz42; Wed, 13 Jul 2011 12:58:00 +0000 Message-ID: <4E1D9654.5060805@alum.mit.edu> Date: Wed, 13 Jul 2011 08:57:56 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "Parthasarathi R (partr)" References: <07465C1D981ABC41A344374066AE1A2C38AFE9BB8A@TLVMBX01.nice.com> <4E1C77D1.2040008@alum.mit.edu> <4E1C88BF.9000001@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: siprec@ietf.org Subject: Re: [siprec] Caller preference information in 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, 13 Jul 2011 12:58:01 -0000 On 7/13/11 1:37 AM, Parthasarathi R (partr) wrote: > Paul, > > I agree that participant capability (RFC 3840) has to passed across in > metadata XML. Please let me know whether adding element > within element will serve the purpose. The example > metadata xml element structure is as follows: > > > automata > That would work. Then need to decide whether to pass the arguments "as is" from the sip, or re-encode them in some way. (When no value is given for the tag, do we include the default value? Preserve quoting?) I expect it will be necessary to match up characters used and quoting/escaping conventions in the sip syntax with those in xml and do some mapping. Thanks, Paul > Thanks > Partha > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: Tuesday, July 12, 2011 11:18 PM >> To: Parthasarathi R (partr) >> Cc: siprec@ietf.org >> Subject: Re: [siprec] Caller preference information in Metadata >> >> On 7/12/11 1:22 PM, Parthasarathi R (partr) wrote: >>> Paul, >>> >>> I'm not very sure whether we need both callee capability and caller >>> preference or callee capability will serve the purpose. The >> reason for >>> my doubt is that Caller participant information may end up >> as "automata" >>> in contact header which has to be passed across to from SRC to SRS >>> and caller "automata" information to SRS is considered as callee >>> capability or caller preference. >> >> Its a capability. >> >> The preferences are selection "expressions" applied to >> capabilities to compute which contact to prefer. >> >> Thanks, >> Paul >> >>> Thanks >>> Partha >>> >>>> -----Original Message----- >>>> From: siprec-bounces@ietf.org >>>> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat >>>> Sent: Tuesday, July 12, 2011 10:05 PM >>>> To: siprec@ietf.org >>>> Subject: Re: [siprec] Caller preference information in Metadata >>>> >>>> On 7/7/11 9:44 AM, Leon Portman wrote: >>>>> Partha Hi >>>>> >>>>> Today we are not receive and store this information. Is it >>>> widely accepted? >>>> >>>> As I noted earlier, there is a difference between >> callee-capability >>>> info >>>> (rfc3840) and caller-preference info (rfc3841), though >> they are often >>>> talked about as one thing. >>>> >>>> Its not evident to me that caller preference info is very >> relevant. >>>> It could influence what UAS ends up in a call, but that isn't so >>>> relevant to recording. >>>> >>>> The callee caps stuff goes two places: in registered >> contacts, and in >>>> contacts used to establish dialogs. Again, the registered contacts >>>> probably aren't of interest, and aren't available in any case. >>>> >>>> The callee caps in dialog contacts can be significant. For >> instance, >>>> the isFocus capability/tag can be quite interesting. I >> think we ought >>>> to make them available. >>>> >>>> Thanks, >>>> Paul >>>> >>>>> Leon >>>>> >>>>> *From:*siprec-bounces@ietf.org >> [mailto:siprec-bounces@ietf.org] *On >>>>> Behalf Of *Parthasarathi R (partr) >>>>> *Sent:* Thursday, July 07, 2011 3:07 PM >>>>> *To:* siprec@ietf.org >>>>> *Subject:* [siprec] Caller preference information in Metadata >>>>> >>>>> Hi all, >>>>> >>>>> Caller preference (RFC 3841) information about CS is >> possible to be >>>>> passed in extension data of participant. The caller >> preference like >>>>> "automata" shall be passed in SIPREC metadata itself in >>>> case folks are >>>>> interested. Please let me know whether "caller preference" >>>> attribute >>>>> shall be added under participant block. >>>>> >>>>> Thanks >>>>> >>>>> Partha >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> siprec mailing list >>>>> siprec@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/siprec >>>> >>>> _______________________________________________ >>>> siprec mailing list >>>> siprec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/siprec >>>> >>> >> >> > From pkyzivat@alum.mit.edu Wed Jul 13 06:17: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 987BA11E80CB for ; Wed, 13 Jul 2011 06:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071, 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 pBd7Xj-3IBP7 for ; Wed, 13 Jul 2011 06:17:30 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by ietfa.amsl.com (Postfix) with ESMTP id BC61E11E80C6 for ; Wed, 13 Jul 2011 06:17:29 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta08.westchester.pa.mail.comcast.net with comcast id 7QyX1h0091ZXKqc58RHTXc; Wed, 13 Jul 2011 13:17:27 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta21.westchester.pa.mail.comcast.net with comcast id 7RHS1h01R0tdiYw3hRHStz; Wed, 13 Jul 2011 13:17:27 +0000 Message-ID: <4E1D9AE5.4040809@alum.mit.edu> Date: Wed, 13 Jul 2011 09:17:25 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "Ram Mohan R (rmohanr)" References: <07465C1D981ABC41A344374066AE1A2C38AFE9BB8A@TLVMBX01.nice.com><4E1C77D1.2040008@alum.mit.edu><4E1C88BF.9000001@alum.mit.edu> <35BCE99A477D6A4986FB2216D8CF2CFD07055203@XMB-BGL-417.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD07055203@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] Caller preference information in 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, 13 Jul 2011 13:17:30 -0000 On 7/13/11 6:02 AM, Ram Mohan R (rmohanr) wrote: > Paul / Partha, > > Would it better to use "characteristic" as the XML element name instead > of "capability". As per 3840 definition one difference between > capability and characteristic is capability is something that can be > negotiated where as characteristic cannot be. > IMO since "automata" is a characteristic of a device it is better to > have XML element as the "characteristic" How about "feature-tag" ? Thanks, Paul > Ram > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Parthasarathi R (partr) >> Sent: Wednesday, July 13, 2011 11:08 AM >> To: Paul Kyzivat >> Cc: siprec@ietf.org >> Subject: Re: [siprec] Caller preference information in Metadata >> >> Paul, >> >> I agree that participant capability (RFC 3840) has to passed across in >> metadata XML. Please let me know whether adding element >> within element will serve the purpose. The example >> metadata xml element structure is as follows: >> >> >> automata >> >> >> Thanks >> Partha >> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>> Sent: Tuesday, July 12, 2011 11:18 PM >>> To: Parthasarathi R (partr) >>> Cc: siprec@ietf.org >>> Subject: Re: [siprec] Caller preference information in Metadata >>> >>> On 7/12/11 1:22 PM, Parthasarathi R (partr) wrote: >>>> Paul, >>>> >>>> I'm not very sure whether we need both callee capability and > caller >>>> preference or callee capability will serve the purpose. The >>> reason for >>>> my doubt is that Caller participant information may end up >>> as "automata" >>>> in contact header which has to be passed across to from SRC to > SRS >>>> and caller "automata" information to SRS is considered as callee >>>> capability or caller preference. >>> >>> Its a capability. >>> >>> The preferences are selection "expressions" applied to >>> capabilities to compute which contact to prefer. >>> >>> Thanks, >>> Paul >>> >>>> Thanks >>>> Partha >>>> >>>>> -----Original Message----- >>>>> From: siprec-bounces@ietf.org >>>>> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat >>>>> Sent: Tuesday, July 12, 2011 10:05 PM >>>>> To: siprec@ietf.org >>>>> Subject: Re: [siprec] Caller preference information in Metadata >>>>> >>>>> On 7/7/11 9:44 AM, Leon Portman wrote: >>>>>> Partha Hi >>>>>> >>>>>> Today we are not receive and store this information. Is it >>>>> widely accepted? >>>>> >>>>> As I noted earlier, there is a difference between >>> callee-capability >>>>> info >>>>> (rfc3840) and caller-preference info (rfc3841), though >>> they are often >>>>> talked about as one thing. >>>>> >>>>> Its not evident to me that caller preference info is very >>> relevant. >>>>> It could influence what UAS ends up in a call, but that isn't so >>>>> relevant to recording. >>>>> >>>>> The callee caps stuff goes two places: in registered >>> contacts, and in >>>>> contacts used to establish dialogs. Again, the registered > contacts >>>>> probably aren't of interest, and aren't available in any case. >>>>> >>>>> The callee caps in dialog contacts can be significant. For >>> instance, >>>>> the isFocus capability/tag can be quite interesting. I >>> think we ought >>>>> to make them available. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>>> Leon >>>>>> >>>>>> *From:*siprec-bounces@ietf.org >>> [mailto:siprec-bounces@ietf.org] *On >>>>>> Behalf Of *Parthasarathi R (partr) >>>>>> *Sent:* Thursday, July 07, 2011 3:07 PM >>>>>> *To:* siprec@ietf.org >>>>>> *Subject:* [siprec] Caller preference information in Metadata >>>>>> >>>>>> Hi all, >>>>>> >>>>>> Caller preference (RFC 3841) information about CS is >>> possible to be >>>>>> passed in extension data of participant. The caller >>> preference like >>>>>> "automata" shall be passed in SIPREC metadata itself in >>>>> case folks are >>>>>> interested. Please let me know whether "caller preference" >>>>> attribute >>>>>> shall be added under participant block. >>>>>> >>>>>> Thanks >>>>>> >>>>>> Partha >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> siprec mailing list >>>>>> siprec@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>> >>>>> _______________________________________________ >>>>> siprec mailing list >>>>> siprec@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>> >>>> >>> >>> >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec > From rmohanr@cisco.com Wed Jul 13 06:35: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 1D39A21F880C for ; Wed, 13 Jul 2011 06:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.236 X-Spam-Level: X-Spam-Status: No, score=-10.236 tagged_above=-999 required=5 tests=[AWL=0.363, 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 vj6ZFwf2UwOU for ; Wed, 13 Jul 2011 06:35: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 B596E21F8763 for ; Wed, 13 Jul 2011 06:35:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=5504; q=dns/txt; s=iport; t=1310564124; x=1311773724; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=naGEkCZJYpgpRgQXyoZ2KbSbLo62/pCFFpy4KzfsFag=; b=azMNr33TMmE//W6DeteTFKx+gVlnTF/JTX4pBhcJHrHnm8+iMkEtsbnP w/WAcp64vh7x04VF2ocLlhmrqX5rRwk0jobSrr+ZGAVqJ0qRq/EDQdgbX na/HCFYXHp6EsXY1dECDsenevX2NkQLXRlKGQjxSy3hXViKPKBvhGc3at s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAAGieHU5Io8UR/2dsb2JhbABTEJdujz53rimeJYVbXwSHT5Aaiw0/ X-IronPort-AV: E=Sophos;i="4.65,525,1304294400"; d="scan'208";a="101840450" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-1.cisco.com with ESMTP; 13 Jul 2011 13:35:19 +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 p6DDZI3a018535; Wed, 13 Jul 2011 13:35:18 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Jul 2011 19:05:18 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Jul 2011 19:05:17 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD070552B4@XMB-BGL-417.cisco.com> In-reply-to: <4E1D9AE5.4040809@alum.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Caller preference information in Metadata Thread-Index: AcxBXzvC6F+mf3yXTy6Rk67BJNSFEgAAmaKw References: <07465C1D981ABC41A344374066AE1A2C38AFE9BB8A@TLVMBX01.nice.com><4E1C77D1.2040008@alum.mit.edu><4E1C88BF.9000001@alum.mit.edu> <35BCE99A477D6A4986FB2216D8CF2CFD07055203@XMB-BGL-417.cisco.com> <4E1D9AE5.4040809@alum.mit.edu> From: "Ram Mohan R (rmohanr)" To: "Paul Kyzivat" , X-OriginalArrivalTime: 13 Jul 2011 13:35:18.0799 (UTC) FILETIME=[B4CED9F0:01CC4161] Subject: Re: [siprec] Caller preference information in 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, 13 Jul 2011 13:35:29 -0000 Hi Paul, feature-tag sounds fine to me Regards, Ram > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Wednesday, July 13, 2011 6:47 PM > To: Ram Mohan R (rmohanr) > Cc: Parthasarathi R (partr); siprec@ietf.org > Subject: Re: [siprec] Caller preference information in Metadata >=20 > On 7/13/11 6:02 AM, Ram Mohan R (rmohanr) wrote: > > Paul / Partha, > > > > Would it better to use "characteristic" as the XML element name > instead > > of "capability". As per 3840 definition one difference between > > capability and characteristic is capability is something that can be > > negotiated where as characteristic cannot be. > > IMO since "automata" is a characteristic of a device it is better to > > have XML element as the "characteristic" >=20 > How about "feature-tag" ? >=20 > Thanks, > Paul >=20 > > Ram > > > >> -----Original Message----- > >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >> Behalf Of Parthasarathi R (partr) > >> Sent: Wednesday, July 13, 2011 11:08 AM > >> To: Paul Kyzivat > >> Cc: siprec@ietf.org > >> Subject: Re: [siprec] Caller preference information in Metadata > >> > >> Paul, > >> > >> I agree that participant capability (RFC 3840) has to passed across > in > >> metadata XML. Please let me know whether adding element > >> within element will serve the purpose. The example > >> metadata xml element structure is as follows: > >> > >> > >> automata > >> > >> > >> Thanks > >> Partha > >> > >>> -----Original Message----- > >>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > >>> Sent: Tuesday, July 12, 2011 11:18 PM > >>> To: Parthasarathi R (partr) > >>> Cc: siprec@ietf.org > >>> Subject: Re: [siprec] Caller preference information in Metadata > >>> > >>> On 7/12/11 1:22 PM, Parthasarathi R (partr) wrote: > >>>> Paul, > >>>> > >>>> I'm not very sure whether we need both callee capability and > > caller > >>>> preference or callee capability will serve the purpose. The > >>> reason for > >>>> my doubt is that Caller participant information may end up > >>> as "automata" > >>>> in contact header which has to be passed across to from SRC to > > SRS > >>>> and caller "automata" information to SRS is considered as callee > >>>> capability or caller preference. > >>> > >>> Its a capability. > >>> > >>> The preferences are selection "expressions" applied to > >>> capabilities to compute which contact to prefer. > >>> > >>> Thanks, > >>> Paul > >>> > >>>> Thanks > >>>> Partha > >>>> > >>>>> -----Original Message----- > >>>>> From: siprec-bounces@ietf.org > >>>>> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > >>>>> Sent: Tuesday, July 12, 2011 10:05 PM > >>>>> To: siprec@ietf.org > >>>>> Subject: Re: [siprec] Caller preference information in Metadata > >>>>> > >>>>> On 7/7/11 9:44 AM, Leon Portman wrote: > >>>>>> Partha Hi > >>>>>> > >>>>>> Today we are not receive and store this information. Is it > >>>>> widely accepted? > >>>>> > >>>>> As I noted earlier, there is a difference between > >>> callee-capability > >>>>> info > >>>>> (rfc3840) and caller-preference info (rfc3841), though > >>> they are often > >>>>> talked about as one thing. > >>>>> > >>>>> Its not evident to me that caller preference info is very > >>> relevant. > >>>>> It could influence what UAS ends up in a call, but that isn't so > >>>>> relevant to recording. > >>>>> > >>>>> The callee caps stuff goes two places: in registered > >>> contacts, and in > >>>>> contacts used to establish dialogs. Again, the registered > > contacts > >>>>> probably aren't of interest, and aren't available in any case. > >>>>> > >>>>> The callee caps in dialog contacts can be significant. For > >>> instance, > >>>>> the isFocus capability/tag can be quite interesting. I > >>> think we ought > >>>>> to make them available. > >>>>> > >>>>> Thanks, > >>>>> Paul > >>>>> > >>>>>> Leon > >>>>>> > >>>>>> *From:*siprec-bounces@ietf.org > >>> [mailto:siprec-bounces@ietf.org] *On > >>>>>> Behalf Of *Parthasarathi R (partr) > >>>>>> *Sent:* Thursday, July 07, 2011 3:07 PM > >>>>>> *To:* siprec@ietf.org > >>>>>> *Subject:* [siprec] Caller preference information in Metadata > >>>>>> > >>>>>> Hi all, > >>>>>> > >>>>>> Caller preference (RFC 3841) information about CS is > >>> possible to be > >>>>>> passed in extension data of participant. The caller > >>> preference like > >>>>>> "automata" shall be passed in SIPREC metadata itself in > >>>>> case folks are > >>>>>> interested. Please let me know whether "caller preference" > >>>>> attribute > >>>>>> shall be added under participant block. > >>>>>> > >>>>>> Thanks > >>>>>> > >>>>>> Partha > >>>>>> > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> siprec mailing list > >>>>>> siprec@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/siprec > >>>>> > >>>>> _______________________________________________ > >>>>> siprec mailing list > >>>>> siprec@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/siprec > >>>>> > >>>> > >>> > >>> > >> _______________________________________________ > >> siprec mailing list > >> siprec@ietf.org > >> https://www.ietf.org/mailman/listinfo/siprec > > From eckelcu@cisco.com Wed Jul 13 12:53: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 B9BC211E8120 for ; Wed, 13 Jul 2011 12:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.912 X-Spam-Level: X-Spam-Status: No, score=-4.912 tagged_above=-999 required=5 tests=[AWL=-2.312, 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 u+eSrBiygf4J for ; Wed, 13 Jul 2011 12:53:09 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id D24D611E808C for ; Wed, 13 Jul 2011 12:53:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=4332; q=dns/txt; s=iport; t=1310586788; x=1311796388; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=BaueC8GmI0fjGhtRPUTwgiJRjll4lLTSKVDG6QHG1jE=; b=iGDvnS4uK1X27ZfO082DI4zNnHno/0u2tTiKD3Ja/AZfLv7JzNt/xggI cx+LzpBn9WZ+qy5l2gURbGwpMor4i/BK4hMsLfw6jRUGOMTElAdJvCz8k 8RsWXOVc+kXAfophs8YEXMM4lbeBz8w/ZrbCBNKnmvNqeh9YbNdlsB382 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAANL2HU6rRDoI/2dsb2JhbABTmAePOHetZ54shVtfBIdRkBiLZA X-IronPort-AV: E=Sophos;i="4.65,526,1304294400"; d="scan'208";a="2669361" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-2.cisco.com with ESMTP; 13 Jul 2011 19:53:08 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6DJr82a026433; Wed, 13 Jul 2011 19:53: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); Wed, 13 Jul 2011 12:53:07 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: D8zZ ETp7 EjL7 IY96 IigV Ip0m I0mb JIkM KACr Lloa Q3bM S12O T3z7 UQdu UT6h Wq2C; 2; agBvAGgAbgAuAGUAbAB3AGUAbABsAEAAcwBpAGUAbQBlAG4AcwAtAGUAbgB0AGUAcgBwAHIAaQBzAGUALgBjAG8AbQA7AHMAaQBwAHIAZQBjAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {0F3AE610-28AE-4FA0-8043-F3D7AB1D9A17}; ZQBjAGsAZQBsAGMAdQBAAGMAaQBzAGMAbwAuAGMAbwBtAA==; Wed, 13 Jul 2011 19:53:02 GMT; UgBFADoAIABbAHMAaQBwAHIAZQBjAF0AIABGAG8AcgBtAGEAdAAgAG8AcAB0AGkAbwBuAHMAIABmAG8AcgAgAHUAbgBpAHEAdQBlACAASQBEAHMAIAAtACAASQBOAFAAVQBUACAAUgBFAFEAVQBJAFIARQBEAA== MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {0F3AE610-28AE-4FA0-8043-F3D7AB1D9A17} Content-class: urn:content-classes:message Date: Wed, 13 Jul 2011 12:53:02 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [siprec] Format options for unique IDs - INPUT REQUIRED thread-index: AcwyfE9X01jfFCBaQgqOYqcpdfoRWAOt+5PwABhqYnA= References: <4E04A13F.8090506@cisco.com> From: "Charles Eckel (eckelcu)" To: "Elwell, John" , "Paul Kyzivat (pkyzivat)" , X-OriginalArrivalTime: 13 Jul 2011 19:53:07.0664 (UTC) FILETIME=[7C812500:01CC4196] Subject: Re: [siprec] Format options for unique IDs - INPUT REQUIRED X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 19:53:12 -0000 I was hoping there would be discussion around additional pros and cons of each approach. As that has not happened, and I do not have any of my own to propose, option C looks best to me as well. Cheers, Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > Sent: Wednesday, July 13, 2011 1:15 AM > To: Paul Kyzivat (pkyzivat); siprec@ietf.org > Subject: Re: [siprec] Format options for unique IDs - INPUT REQUIRED >=20 > Although it was in reply to me, I think this list of possibilities proposed by Paul a few weeks ago > should have attracted comment from the rest of the group, but I don't recall seeing anything. > Personally, C) looks attractive, but I don't have a strong opinion. Would others please express > opinions - it is important to get some sort of closure on this. >=20 > John >=20 >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > > Sent: 24 June 2011 15:38 > > To: siprec@ietf.org > > Subject: [siprec] Format options for unique IDs > > > > > > > > On 6/24/2011 5:58 AM, Elwell, John wrote: > > > > > - Options for globally unique IDs, along with pros and cons > > (Partha to initiate) > > > > I'm not Partha, but I'll comment. Some possibilities: > > > > A) A generic URN, with added constraint that equality is > > based only on lexical equivalence (as defined in rfc 2141) > > > > B) UUID URN (rfc 4122) > > > > C) UUID encoded more densely than the UUID URN > > (e.g. radix64 of the binary uuid form defined in 4122) > > > > Pros/cons of these: > > > > A) Pro: very flexible for the SRC. It has many options for > > how to create and encode IDs. > > > > Pro: ease of generation, assuming the SRC chooses wisely. > > > > Con: Difficult for the SRS. It must deal with variable > > unbounded length ID. Doesn't easily fit in databases. > > > > Con: Somewhat inefficient wire encoding: > > there is minimum length of "URN:" plus NID (namespace identifier). > > > > Pro/Con: Wire efficiency varies depending on SRC choices. > > Could be very good or very bad, depending on what NID is chosen. > > > > B) Pro: very flexible for the SRC. 4122 provides multiple ways of > > generating the UUID. One of them (the name based one) would > > allow generating a UUID from the same strings you might use > > for (A), so its at least as flexible as (A). > > > > Pro: easy of generation. Like (A), but then requires an SHA-1 > > computation. So not as easy as (A). > > > > Pro: Simple for SRS. The UUID can be easily extracted from > > the URN and converted to a fixed length (16 bytes) binary value. > > That value then can be stored in databases, compared, etc. > > > > Con: Somewhat inefficient wire encoding. The urn encoding is > > 45 bytes. > > > > Pro: Flexible to future extension to other sorts of URNs > > (e.g. (A)) due to the use of the URN syntax. > > > > C) Pro: very flexible for the SRC. (Identical to (B)) > > > > Pro: easy of generation. Virtually the same as (B). > > (The final textual formatting is different from (B), but > > similar (insignificant) computationally.) > > > > Pro: Simple for SRS. Virtually the same as (B). > > (The final textual formatting is different from (B), but > > similar (insignificant) computationally.) > > > > Pro: Efficient wire encoding. > > (Radix 64 takes 22 bytes to represent the 16 binary bytes.) > > > > For the metadata these would probably all be wrapped in XML in > > comparable ways, so none has an advantage over another in > > that respect. > > > > Please feel free to propose other alternatives. > > > > As a specific example, for the UUIDs, one could use the 4122 "name > > based" approach, where the "name" is just a binary integer counter. > > > > Thanks, > > Paul > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From pkyzivat@alum.mit.edu Wed Jul 13 13:39: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 023E711E8130 for ; Wed, 13 Jul 2011 13:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 DxxTSTY4x0Ma for ; Wed, 13 Jul 2011 13:38:57 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by ietfa.amsl.com (Postfix) with ESMTP id 8412911E814A for ; Wed, 13 Jul 2011 13:38:53 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta14.westchester.pa.mail.comcast.net with comcast id 7YYj1h0050QuhwU5EYetvb; Wed, 13 Jul 2011 20:38:53 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta02.westchester.pa.mail.comcast.net with comcast id 7Yer1h00Z0tdiYw3NYesSh; Wed, 13 Jul 2011 20:38:53 +0000 Message-ID: <4E1E0259.6070103@alum.mit.edu> Date: Wed, 13 Jul 2011 16:38:49 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: siprec@ietf.org References: <4E04A13F.8090506@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] Format options for unique IDs - INPUT REQUIRED X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 20:39:01 -0000 On 7/13/11 3:53 PM, Charles Eckel (eckelcu) wrote: > I was hoping there would be discussion around additional pros and cons > of each approach. As that has not happened, and I do not have any of my > own to propose, option C looks best to me as well. After writing them all out, I could find little to dislike about (C). One additional con for (C): its a unique format created just for siprec, rather than being some already recognized format. If we go that way, we will have to be careful to precisely specify the encoding. I found RFC4648, which gives rules for the encoding. And of course we must define the byte order for this - network byte order. Those with little-endian machines (e.g. x86) will have to be careful about the encoding. Does anybody know if a format such as this has already been defined in xml? Thanks, Paul > Cheers, > Charles > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Elwell, John >> Sent: Wednesday, July 13, 2011 1:15 AM >> To: Paul Kyzivat (pkyzivat); siprec@ietf.org >> Subject: Re: [siprec] Format options for unique IDs - INPUT REQUIRED >> >> Although it was in reply to me, I think this list of possibilities > proposed by Paul a few weeks ago >> should have attracted comment from the rest of the group, but I don't > recall seeing anything. >> Personally, C) looks attractive, but I don't have a strong opinion. > Would others please express >> opinions - it is important to get some sort of closure on this. >> >> John >> >> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org >>> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat >>> Sent: 24 June 2011 15:38 >>> To: siprec@ietf.org >>> Subject: [siprec] Format options for unique IDs >>> >>> >>> >>> On 6/24/2011 5:58 AM, Elwell, John wrote: >>> >>>> - Options for globally unique IDs, along with pros and cons >>> (Partha to initiate) >>> >>> I'm not Partha, but I'll comment. Some possibilities: >>> >>> A) A generic URN, with added constraint that equality is >>> based only on lexical equivalence (as defined in rfc 2141) >>> >>> B) UUID URN (rfc 4122) >>> >>> C) UUID encoded more densely than the UUID URN >>> (e.g. radix64 of the binary uuid form defined in 4122) >>> >>> Pros/cons of these: >>> >>> A) Pro: very flexible for the SRC. It has many options for >>> how to create and encode IDs. >>> >>> Pro: ease of generation, assuming the SRC chooses wisely. >>> >>> Con: Difficult for the SRS. It must deal with variable >>> unbounded length ID. Doesn't easily fit in databases. >>> >>> Con: Somewhat inefficient wire encoding: >>> there is minimum length of "URN:" plus NID (namespace > identifier). >>> >>> Pro/Con: Wire efficiency varies depending on SRC choices. >>> Could be very good or very bad, depending on what NID is chosen. >>> >>> B) Pro: very flexible for the SRC. 4122 provides multiple ways of >>> generating the UUID. One of them (the name based one) would >>> allow generating a UUID from the same strings you might use >>> for (A), so its at least as flexible as (A). >>> >>> Pro: easy of generation. Like (A), but then requires an SHA-1 >>> computation. So not as easy as (A). >>> >>> Pro: Simple for SRS. The UUID can be easily extracted from >>> the URN and converted to a fixed length (16 bytes) binary value. >>> That value then can be stored in databases, compared, etc. >>> >>> Con: Somewhat inefficient wire encoding. The urn encoding is >>> 45 bytes. >>> >>> Pro: Flexible to future extension to other sorts of URNs >>> (e.g. (A)) due to the use of the URN syntax. >>> >>> C) Pro: very flexible for the SRC. (Identical to (B)) >>> >>> Pro: easy of generation. Virtually the same as (B). >>> (The final textual formatting is different from (B), but >>> similar (insignificant) computationally.) >>> >>> Pro: Simple for SRS. Virtually the same as (B). >>> (The final textual formatting is different from (B), but >>> similar (insignificant) computationally.) >>> >>> Pro: Efficient wire encoding. >>> (Radix 64 takes 22 bytes to represent the 16 binary bytes.) >>> >>> For the metadata these would probably all be wrapped in XML in >>> comparable ways, so none has an advantage over another in >>> that respect. >>> >>> Please feel free to propose other alternatives. >>> >>> As a specific example, for the UUIDs, one could use the 4122 "name >>> based" approach, where the "name" is just a binary integer counter. >>> >>> Thanks, >>> Paul >>> >>> _______________________________________________ >>> siprec mailing list >>> siprec@ietf.org >>> https://www.ietf.org/mailman/listinfo/siprec >>> >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From rmohanr@cisco.com Wed Jul 13 23:55:21 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 00F1521F8577 for ; Wed, 13 Jul 2011 23:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.957 X-Spam-Level: X-Spam-Status: No, score=-9.957 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_53=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 exj90dJye5xq for ; Wed, 13 Jul 2011 23:55:17 -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 4F74021F8AF9 for ; Wed, 13 Jul 2011 23:55:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=16743; q=dns/txt; s=iport; t=1310626516; x=1311836116; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=4cxCVk+zfnsLbMkekRHe8UOQtsnN3myp8n7UD6rLpbA=; b=bUcNAlmVxJkLbcYhCqreMvC/kvhVTBGsBMC1v6HGTTFnb1d3MPYEorDf R76oxHCQHq/q3jllx5NwcmVRS2jdzh1BDqcFZc/APqHNDArbuujhZd5QE Jzr2LJFskKTz9W+eFekzpMVn26Gl1Yooyt6XpMzileLIrmq6qEDHd+jyY E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvkAADaSHk5Io8UQ/2dsb2JhbABTglOVP4cniBh3q1ieJIVbXwSHUZAci08 X-IronPort-AV: E=Sophos;i="4.65,527,1304294400"; d="scan'208,217";a="102012359" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-1.cisco.com with ESMTP; 14 Jul 2011 06:55:14 +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 p6E6sxBv005009; Thu, 14 Jul 2011 06:55:13 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Jul 2011 12:25:06 +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_01CC41F2.F647AC5E" Date: Thu, 14 Jul 2011 12:25:04 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD070554A1@XMB-BGL-417.cisco.com> In-reply-to: <07465C1D981ABC41A344374066AE1A2C38B006A896@TLVMBX01.nice.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] CSG start & stop time attribute requirement Thread-Index: Acw0kGxvAtp8hudRQFqbSwPv+BTXsQARfy2AAiwW7rAAU+aocADG9STQ References: <35BCE99A477D6A4986FB2216D8CF2CFD06D3323D@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD06F4FF7F@XMB-BGL-417.cisco.com> <07465C1D981ABC41A344374066AE1A2C38B006A896@TLVMBX01.nice.com> From: "Ram Mohan R (rmohanr)" To: "Leon Portman" , X-OriginalArrivalTime: 14 Jul 2011 06:55:06.0188 (UTC) FILETIME=[F696F0C0:01CC41F2] Subject: Re: [siprec] CSG start & stop time attribute requirement X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 06:55:21 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC41F2.F647AC5E Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi All, =20 I have not seen any one object to having Start/Stop times in CS-Group element of model. Let me know if anyone has concerns otherwise we will go ahead and add the same in next version of draft. =20 Regards, Ram =20 From: Leon Portman [mailto:Leon.Portman@nice.com]=20 Sent: Sunday, July 10, 2011 1:23 PM To: Ram Mohan R (rmohanr); siprec@ietf.org Subject: RE: [siprec] CSG start & stop time attribute requirement =20 I am ok =20 Leon =20 From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Ram Mohan R (rmohanr) Sent: Friday, July 08, 2011 6:51 PM To: siprec@ietf.org Subject: Re: [siprec] CSG start & stop time attribute requirement =20 I have not heard back any comments on this. Can people let us know your thoughts on having Start/Stop time attribute for CSG block ? =20 Regards, Ram From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Ram Mohan R (rmohanr) Sent: Monday, June 27, 2011 8:33 PM To: Parthasarathi R (partr); siprec@ietf.org Subject: Re: [siprec] CSG start & stop time attribute requirement =20 To add more to what Partha has mentioned another use case is when multiple RSs are used for recording a CSG it is easy to determine start/ Stop time when explicitly indicated in CSG. So I would prefer to have Start/ Stop time explicitly indicated in CS-Group and which would indicate when a Group Starts/ End. =20 Ram =20 From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi R (partr) Sent: Monday, June 27, 2011 11:37 AM To: siprec@ietf.org Subject: [siprec] CSG start & stop time attribute requirement =20 Hi all, =20 As per interim meeting, there is a need to explain the reason for having start/stop time in CSG group. Two reasons for having this attribute: =20 1) BYE will serve the purpose in case CSG is within single RS or ending at the end of some RS. In case CSG is terminated in the middle of RS session (persistent session), there is a need of an attribute. As it is middle of the RS, it is better to have the exact time. =20 2) In case partial-update of metadata format, there is an need of XML element to indicate the termination of CSG ("group") element. It shall be achieved by "stop-time" element within CSG. =20 Thanks Partha =20 Note: Topic - Metadata model(Ram Mohan) draft-ietf-siprec-metadata-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-ietf-siprec-metadata/ =20 Slides: http://trac.tools.ietf.org/wg/siprec/trac/attachment/wiki/WikiStart/SIPR EC%20Metamodel%20-%20Virtual%20Interim-23Jun_2011.pptx =20 Side 5: On the issue of whether a CSG element needs a start/stop time, Ram explained that the information could be derived from the start/stop times of the CSs that form part of that group (although he was concerned about the complications of overlapping CSs), or could be explicitly indicated for the group. Leon and John thought that implicit should be sufficient. Partha tried to express a point concerning termination of a CSG, but this needs to be raised on the list. ------_=_NextPart_001_01CC41F2.F647AC5E Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi All,

 

I have not seen any one object to having Start/Stop times in CS-Group = element of model. Let me know if anyone has concerns otherwise we will = go ahead and add the same in next version of = draft.

 

Regards,

Ram

 

From:= = Leon Portman [mailto:Leon.Portman@nice.com]
Sent: Sunday, = July 10, 2011 1:23 PM
To: Ram Mohan R (rmohanr); = siprec@ietf.org
Subject: RE: [siprec] CSG start & stop = time attribute requirement

 

I am ok

 

Leon

 

From:= = siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of = Ram Mohan R (rmohanr)
Sent: Friday, July 08, 2011 6:51 = PM
To: siprec@ietf.org
Subject: Re: [siprec] CSG = start & stop time attribute = requirement

 

I have not heard back any comments on this. Can people let us know = your thoughts on having Start/Stop time attribute for CSG block = ?

 

Regards,

Ram

From:= = siprec-bounces@ietf.org = [mailto:siprec-bounces@i= etf.org] On Behalf Of Ram Mohan R (rmohanr)
Sent: = Monday, June 27, 2011 8:33 PM
To: Parthasarathi R (partr); siprec@ietf.org
Subject: = Re: [siprec] CSG start & stop time attribute = requirement

 

To add more to what Partha has mentioned another use case is when = multiple RSs are used for recording a CSG it is easy to determine start/ = Stop time when explicitly indicated in CSG.

So I would prefer to have Start/ Stop time explicitly indicated in = CS-Group and which would indicate when a Group Starts/ = End.

 

Ram

 

From:= = siprec-bounces@ietf.org = [mailto:siprec-bounces@i= etf.org] On Behalf Of Parthasarathi R (partr)
Sent: = Monday, June 27, 2011 11:37 AM
To: siprec@ietf.org
Subject: = [siprec] CSG start & stop time attribute = requirement

 

Hi = all,

 

As per = interim meeting, there is a need to explain the reason for having = start/stop time in CSG group. Two reasons for having this = attribute:

 

1) BYE will = serve the purpose in case CSG is within single RS or ending at the end = of some RS. In case CSG is terminated in the middle of RS session = (persistent session), there is a need of an attribute.  As it is = middle of the RS, it is better to have the exact = time.

 

2) In case = partial-update of metadata format, there is an need of XML element to = indicate the termination of CSG ("group") element. It = shall be achieved by "stop-time" element within = CSG.

 

Thanks=

Partha=

 

Note:<= o:p>

Topic - = Metadata model(Ram Mohan)

draft-ietf-si= prec-metadata-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<= /p>

Draft: = https://datatracker.ietf.org/doc/draft-ietf-siprec-metadata/

Slides: = http://trac.tools.ietf.org/wg/siprec/trac/attachment/wiki/WikiS= tart/SIPREC%20Metamodel%20-%20Virtual%20Interim-23Jun_2011.pptx

Side 5: On = the issue of whether a CSG element needs a start/stop time, Ram = explained that the information could be derived from the start/stop = times of the CSs that form part of that group (although he was concerned = about the complications of overlapping CSs), or could be explicitly = indicated for the group. Leon and John thought that implicit should be = sufficient. Partha tried to express a point concerning termination of a = CSG, but this needs to be raised on the = list.

------_=_NextPart_001_01CC41F2.F647AC5E-- From john.elwell@siemens-enterprise.com Thu Jul 14 00:07: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 1113921F87A8 for ; Thu, 14 Jul 2011 00:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.455 X-Spam-Level: X-Spam-Status: No, score=-106.455 tagged_above=-999 required=5 tests=[AWL=0.144, 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 cZ3b1gLbumja for ; Thu, 14 Jul 2011 00:07:09 -0700 (PDT) Received: from mail21.messagelabs.com (mail21.messagelabs.com [85.158.143.35]) by ietfa.amsl.com (Postfix) with SMTP id 17A3721F87A4 for ; Thu, 14 Jul 2011 00:07:08 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-9.tower-21.messagelabs.com!1310627192!42650345!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 18381 invoked from network); 14 Jul 2011 07:06:32 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-9.tower-21.messagelabs.com with SMTP; 14 Jul 2011 07:06:32 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 407271EB83EE; Thu, 14 Jul 2011 09:07:05 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 14 Jul 2011 09:07:05 +0200 From: "Elwell, John" To: Paul Kyzivat , "siprec@ietf.org" Date: Thu, 14 Jul 2011 09:07:03 +0200 Thread-Topic: [siprec] Format options for unique IDs - INPUT REQUIRED Thread-Index: AcwyfE9X01jfFCBaQgqOYqcpdfoRWAOt+5Pw Message-ID: References: <4E04A13F.8090506@cisco.com> In-Reply-To: <4E04A13F.8090506@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] Format options for unique IDs - INPUT REQUIRED X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 07:07:10 -0000 Resending with Paul's new address ################################# Although it was in reply to me, I think this list of possibilities proposed= by Paul a few weeks ago should have attracted comment from the rest of the= group, but I don't recall seeing anything. Personally, C) looks attractive= , but I don't have a strong opinion. Would others please express opinions -= it is important to get some sort of closure on this. John =20 > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 24 June 2011 15:38 > To: siprec@ietf.org > Subject: [siprec] Format options for unique IDs >=20 >=20 >=20 > On 6/24/2011 5:58 AM, Elwell, John wrote: >=20 > > - Options for globally unique IDs, along with pros and cons=20 > (Partha to initiate) >=20 > I'm not Partha, but I'll comment. Some possibilities: >=20 > A) A generic URN, with added constraint that equality is > based only on lexical equivalence (as defined in rfc 2141) >=20 > B) UUID URN (rfc 4122) >=20 > C) UUID encoded more densely than the UUID URN > (e.g. radix64 of the binary uuid form defined in 4122) >=20 > Pros/cons of these: >=20 > A) Pro: very flexible for the SRC. It has many options for > how to create and encode IDs. >=20 > Pro: ease of generation, assuming the SRC chooses wisely. >=20 > Con: Difficult for the SRS. It must deal with variable > unbounded length ID. Doesn't easily fit in databases. >=20 > Con: Somewhat inefficient wire encoding: > there is minimum length of "URN:" plus NID (namespace identifier). >=20 > Pro/Con: Wire efficiency varies depending on SRC choices. > Could be very good or very bad, depending on what NID is chosen. >=20 > B) Pro: very flexible for the SRC. 4122 provides multiple ways of > generating the UUID. One of them (the name based one) would > allow generating a UUID from the same strings you might use > for (A), so its at least as flexible as (A). >=20 > Pro: easy of generation. Like (A), but then requires an SHA-1 > computation. So not as easy as (A). >=20 > Pro: Simple for SRS. The UUID can be easily extracted from > the URN and converted to a fixed length (16 bytes) binary value. > That value then can be stored in databases, compared, etc. >=20 > Con: Somewhat inefficient wire encoding. The urn encoding is > 45 bytes. >=20 > Pro: Flexible to future extension to other sorts of URNs > (e.g. (A)) due to the use of the URN syntax. >=20 > C) Pro: very flexible for the SRC. (Identical to (B)) >=20 > Pro: easy of generation. Virtually the same as (B). > (The final textual formatting is different from (B), but > similar (insignificant) computationally.) >=20 > Pro: Simple for SRS. Virtually the same as (B). > (The final textual formatting is different from (B), but > similar (insignificant) computationally.) >=20 > Pro: Efficient wire encoding. > (Radix 64 takes 22 bytes to represent the 16 binary bytes.) >=20 > For the metadata these would probably all be wrapped in XML in=20 > comparable ways, so none has an advantage over another in=20 > that respect. >=20 > Please feel free to propose other alternatives. >=20 > As a specific example, for the UUIDs, one could use the 4122 "name=20 > based" approach, where the "name" is just a binary integer counter. >=20 > Thanks, > Paul >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > = From john.elwell@siemens-enterprise.com Thu Jul 14 00:55: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 174BF21F876D for ; Thu, 14 Jul 2011 00:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.46 X-Spam-Level: X-Spam-Status: No, score=-106.46 tagged_above=-999 required=5 tests=[AWL=0.139, 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 Kkdm0qtjU9br for ; Thu, 14 Jul 2011 00:55:41 -0700 (PDT) Received: from mail182.messagelabs.com (mail182.messagelabs.com [85.158.139.83]) by ietfa.amsl.com (Postfix) with SMTP id 83AF821F8534 for ; Thu, 14 Jul 2011 00:55:21 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-10.tower-182.messagelabs.com!1310630119!11230459!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 6717 invoked from network); 14 Jul 2011 07:55:19 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-10.tower-182.messagelabs.com with SMTP; 14 Jul 2011 07:55:19 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 79CAA1EB83F3 for ; Thu, 14 Jul 2011 09:55:19 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 14 Jul 2011 09:55:19 +0200 From: "Elwell, John" To: "siprec@ietf.org" Date: Thu, 14 Jul 2011 09:55:18 +0200 Thread-Topic: Agenda for Quebec Thread-Index: AcxB+1/MD/UaLBluSAiP5bHujZZiZA== 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] Agenda for Quebec X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 07:55:42 -0000 We have a 2 hour slot on Thursday afternoon. A provisional agenda has been = uploaded, with most of the time going to the metadata and protocol document= s. Any changes? In particular: - Do we need the architecture slot? - Do we need a slot specifically to discuss Charles's RTP proposals? John= From john.elwell@siemens-enterprise.com Thu Jul 14 02:00: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 33A4921F8837 for ; Thu, 14 Jul 2011 02:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.864 X-Spam-Level: X-Spam-Status: No, score=-105.864 tagged_above=-999 required=5 tests=[AWL=-0.465, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, J_CHICKENPOX_74=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 sL9o1HanoMgi for ; Thu, 14 Jul 2011 02:00:08 -0700 (PDT) Received: from mail21.messagelabs.com (mail21.messagelabs.com [85.158.143.35]) by ietfa.amsl.com (Postfix) with SMTP id F3A2B21F87D9 for ; Thu, 14 Jul 2011 02:00:07 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-10.tower-21.messagelabs.com!1310633996!47083009!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 31187 invoked from network); 14 Jul 2011 08:59:56 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-10.tower-21.messagelabs.com with SMTP; 14 Jul 2011 08:59:56 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 6076E23F03EF for ; Thu, 14 Jul 2011 11:00:06 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 14 Jul 2011 10:59:52 +0200 From: "Elwell, John" To: "siprec@ietf.org" Date: Thu, 14 Jul 2011 10:59:51 +0200 Thread-Topic: Review of metadata-03 Thread-Index: AcxCBGRNA+vWWzKOQdKee6BfMA3hew== 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] Review of metadata-03 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 09:00:10 -0000 I have reviewed metadata-03 up to and including section 6 and have the foll= owing comments (as individual): 1. In general, we are much too liberal with normative language. I have high= lighted in later comments some particular places where we use it inappropri= ately. In particular, we should not use it for things that are more a matte= r for the protocol document. Also, since this document is defining the meta= data model and its XML representation, I think we can just use simple prese= nt tense, rather than normative statements, to state what the model or its = XML representation is. This applies in many places, but I have avoided repe= ating my comments in all places. 2. In general, we should avoid saying too much about the protocol or about = conveyance of a metadata XML document, but should restrict ourselves, as fa= r as possible, to the model and the XML document format. Again, specific co= mments touch on this. 3. On terminology, I think it might be more helpful to restrict the term "e= lement" to cases where we are talking about XML elements, and use some othe= r term (e.g., object, class) when talking about components of the model. Th= en we could say, for example, that a 'stream' XML element represents a 'Med= ia Stream' object or an object of class 'Media Stream'. 4. Related to this, I think we should stick to a single convention, either: - use the same name for the model object and for the corresponding XML elem= ent (we do this for "Participant", for example, at present); or - use different names (we do this for "Media Stream" and "stream", for exam= ple, at present). 5. Section 3: "Metadata element: A metadata element represent one block/class of metadata model." This says what it represents, not what it is. Is it an XML element or what?= Also, all definitions should be in the form of a dictionary definition, no= t a sentence. 6. Terms "Metadata attributes" and "XML attributes are defined (section 3) = but not used. 7. "Metadata Composition" is defined (section 3) but used only in the title= of 6.6.1, which could perhaps be changed to something that doesn't need de= fining. In fact a later comment questions the need for 6.6.1. 8. Section 3: "Metadata associations represents the associations between different Metadata elements in the model. It uses UML notation." Defining Metadata Associations in terms of associations is not very helpful= , and I can't find the term used anywhere. 9. Section 4 and elsewhere: I don't think Extension data should be shown as a separate block. Rather li= ke start-time and stop-time, it is just a property of other blocks. In fact= , I would go so far as to say that extension data should not be in the mode= l - it is an XML technique that allows an extended model to be accommodated= in future, but the model itself (being abstract) does not need such an ext= ensibility mechanism. 10. Section 4: "The metadata MUST be conveyed within the Recording Session Dialog." I think this statement is outside scope of this document - more a protocol = matter. 11. Section 4: "Note that the metadata model captures changes that occur over the duration of the recording session." I don't believe it captures changes. I think the model allows the capture o= f a snapshot of a recording's metadata at a given instant in time. Metadata= changes to reflect changes in what is being recorded. 12. Section 4: "then the SRC MUST convey a change of participant and the properties of the new media stream to the SRS." The "MUST convey" statement seems more like a protocol matter. All we can s= ay is that the model changes and there is a need for the SRC to convey the = change in the model to the SRS. 13. Section 4: "Some of the metadata is not required to be conveyed explicitly from the SRC to the SRS, if it can be obtained contextually by the SRS. For instance, the timing of RS block changes(like Start / Stop time) may not be explicitly conveyed from the SRC to the SRS (The Date header in RS dialog SIP message MAY provide the timing, but it is optional). In such cases the time a change occurred may be assumed to be the same as the time when notification of the change is received by the SRS." This is starting to talk about conveyance, rather than the model itself. I = am not sure it belongs in this section. Also we shouldn't make normative st= atements ("MAY") on protocol issues. Furthermore, the statement about the t= ime of change being the time the notification is received is not necessaril= y valid. For example, send notification with a change, this is lost, a litt= le later the SRS asks for a snapshot, the snapshot is sent and the SRS obse= rves the change - however, the time is wrong. 14. Section 5: "The media related details of metadata MUST be passed across using session description protocol (SDP) [RFC4566]. SDP attributes describes about different media formats like audio, video." We should not be making normative statements. We should express in terms li= ke: "Some data from the metadata model is assumed to be made available to t= he SRS through SDP, and therefore this data is not represented in the XML d= ocument format specified in this document. 15. Section 5: "MUST be passed across" I don't think a normative statement about passing across is appropriate to = this document. I think it is sufficient here to say "are represented". 16. Section 5: "The linkage between application/rs-metadata+xml XML schema and metadata SDP is done using the SDP label attribute (a=3Dlabel:xxx) referenced in [RFC4574]." I think this is trying to say something like: "The SDP label attribute [RFC4574] provides an identifier by which a metada= ta XML document can refer to a specific media description in the SDP sent f= rom the SRC to the SRS." 17. Section 5: "Metadata is passed across in Recording Session(RS) incrementally whenever there is a change in CS." I don't think we should be talking about passing across - we should limit o= urselves to talking about the format. I think this should say something lik= e: "The XML document format can be used to represent either the complete metad= ata or a partial update to the metadata. The latter includes only elements = that have changed compared to the previously reported metadata." 18. Section 5.1: "which will be embedded as a message body" Out of scope - delete. 19. Section 5.1: "Recording object is a XML document." There seems to be confusion between this statement and the opening of the p= revious paragraph ("Recording Metadata document is an XML document"). Also = it is unclear what "recording object" is. 20. Section 5.1.2: "dataMode element shows whether the XML document is complete document or partial update. The default value is complete." Any particular reason why this is an element rather than an attribute? I do= n't have a strong opinion either way - just curious, because it seems like = the sort of thing that might typically be an attribute. 21. Section 6.1: "This element is represented by a SIP RS dialog and hence there is no need for this element to be reflected in metadata XML" Would it be more accurate or more helpful to say that the Recording Session= object is represented by recording XML element? That in turn relies on the= SIP/SDP session with which the XML document is associated to provide some = of the attributes of the Recording Session element. Also I think, for consi= stency, this statement should be in a new sub-section 6.1.3, since it conce= rns representation, not modelling. 22. Section 6.1.1: "A Recording Session element MAY have attributes like:" I don't think RFC 2= 119 language is appropriate. We are defining the model - we are not giving = permission for somebody to define the model. We should simply state (presen= t tense) the attributes that apply. If any are optional, we could state tha= t it is optional (rather than "MAY"), or we could say that it can have zero= instances. Also, the word "like" leaves the list open ended, which is cert= ainly unsatisfactory for a normative statement. But even if we change the l= anguage to informative, I think we need to be more precise. 23. Section 6.1.1: "Start and End time value MUST be derived from" This is not a testable requirement - how do you test that something has bee= n derived, unless there is a requirement to do more with the derived inform= ation? I think "are derivable" would suffice. Also, I think this would be m= ore appropriate for 6.1.3. 23. Section 6.1.1: "Start/End time MAY be set to the time at which SRS receives" Again I don't think RFC2119 language is appropriate. This is not a protocol= document. Could say "are derivable from...". Again it would be applicable= to 6.1.3. 23. Section 6.1.2: "Also the allowance of zero instances is to accommodate persistent recording, where there may be none." It seems this sentence is more applicable to the next bullet (concerning CS= ) than to the CSG bullet. 24. Section 6.1.2: "Each CS Group MUST be associated with one or more Recording Sessions [Here each RS can be setup by the potentially different SRCs." This bullet doesn't fit below the introductory text (which is talking about= what an RS must have). In fact this information is repeated in 6.2.2 , whi= ch seems a more appropriate place. 25. Section 6.2: "A Communication Session Group provides association or linking of Communication Sessions." I think we need to say a little more (informatively) about how grouping mig= ht be used. 26. Section 6.2.1: "SRC (or MAY be SRS) MUST ensure the uniqueness of Unique-ID in case multiple SRC interacts with the same SRS." How do I interpret this normative language? I think we need to say that the= SRC is responsible for assigning Unique-ID values that are unique. 27. Section 6.2.2: "o There can be one or more Recording Session elements per Communication Session Group. o Each Communication Session Group MUST be associated with one or more RS [Here each RS can be setup by the potentially different SRCs]" What is the difference between these two bullets? 28. Section 6.2.2: "Each CS MAY be associated to zero or one CS-Group" Would this fit better in 6.3.2? 28. Section 6.2.3: "Group element is an optional element" Do we need to say "optional". We already know from 6.1.2 that an RS has zer= o or more associated CSGs - isn't that sufficient? 29. Section 6.2.3: "Each group element has unique URN UUID attribute which helps to uniquely identify CSG." Why does it only help - why doesn't uniquely identify? 30. Section 6.3.1: "The communication session MAY contain a Call Termination Reason" This conflicts with the "MUST" in the sentence introducing the bullets. 31. Section 6.3.1: "Attributes like Retention (represent the value/duration for which Media streams of the CS needs to be retained), Force Deletion, Access" These look like named attributes, which they are not. Are we trying to say = something like: "This document does not specify attributes relating to what should happen t= o a recording of a CS after it has been delivered to the SRS, e.g., how lon= g to retain the recording, what access controls to apply. The SRS is assume= d to behave in accordance with policy. The ability for the SRC to influence= this policy is outside the scope of this document." Also, should such a st= atement occur up front, e.g., in section 4? 32. Section 6.3.1: "However if there are implementations where SRC has enough information, this could be sent as Extension Data attached to CS" Extension data is an XML concept, so should be covered in 6.3.3. 33. Section 6.3.2: "CS to have atleast two or more participants" Are there any corner cases where there might be fewer than two? 34. Section 6.3.2: "o Participant MUST be associated with one or more CS's. This may even includes participants who are not directly 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. Another use case is if one UA in CS works in 3pcc mode to acquire an MoH media stream, this might be reflected as unique source for media stream without having a reported signaling relationship to it. In all these cases if SRC can learn enough information about the Participant, they MUST be associated with CS." All this is very confusing. I think what it is saying is that the SRC might= not have direct signalling relationships with all participants in a CS, bu= t should nevertheless create a Participant object for each participant that= it knows about, e.g., participants visible as a result of the conference e= vent package [RFC4575]. I failed to understand the bit about MoH, so that t= oo would need rewording if retained. 35. Section 6.3.2: "o The model also allows participants in CS that are not participants in the media. An example is the identity of a 3pcc controller that has initiated a CS to two or more participants of the CS. Another example is the identity of a conference focus. Of course a focus is probably in the media, but since it may only be there as a mixer, it may not report itself as a participant in any of the media streams." It is unclear why these cases would need to be Participants. However, I agr= ee that where nothing is known about what is beyond a conference focus or B= 2BUA, the conference focus or B2BUA itself should probably be identified (i= f possible). 36. Section 6.3.2: "o A stream can be associated with 1 or more CS. An example is multicast MoH stream which might be associated with many CSs." I don't find this a convincing example. Does the SRC know for certain that = the two streams are both the same MoH, and if so whether they are synchroni= zed or not (if that matters)? 37. Section 6.3.2 (same bullet): "Also if we were to consider a B2BUA to have a separate CS on each "side" then they might share a stream.(Though more likely this would be treated as a single CS.)" Again, this is a possibility, but why would a B2BUA want to do this - it se= ems to complicate the metadata unnecessarily? 38. Section 6.3.3: "Each communication session(CS) has one session element" I would suggest changing "has" to "is represented by". 39. Section 6.3.3: "Reason element MAY be included to indicate the reason for termination." In order to tie it more clearly to the model, I would suggest changing "to = indicate the reason for termination" to "to represent the Termination Reaso= n attribute". 40. Section 6.4.1: "AoR list - Has list of AoRs." Should we use a more generic name, rather than AOR? For example, "Identifie= r", since it need not necessarily be a SIP AOR, but could, for example, be = a TEL URI, or even a JID if the CS is not a SIP session? 41. Concerning the same bullet, in the schema, this has maxOccurs=3D1, so i= t doesn't seem to be a list, just a single AOR. I think a single identifier= might be sufficient. 42. Section 6.4.1: "o Name - This attribute represents Participant name(SIP display name) or DN number ( in case it is known)" Assuming "DN number" means "directory number", or telephone number, why is = this part of the name attribute, rather than the previous attribute? For ex= ample, I have available a tel: URI from P-Asserted-Identity - why would I t= reat that as name rather than identifier? 43. Section 6.4.1: "Other attributes [ like Participant Role, Participant type ] MAY be carried as part of extension data to Participant from SRC to SRS." Again this seems to be a statement about XML, so more relevant to 6.4.3 (if= we need to say anything at all). 44. Section 6.4.3: "Participant element provides information regarding the specific participant involved in the recording" I think this should say something like: "A participant element represents a= Participant object." 45. Section 6.4.3: ""receive" element" I think this should be ""recv" element". 46. Section 6.4.3: "and by default all participant will receive the stream" I can't figure out how this works. If I omit a "recv" element for a particu= lar Participant, it seems to mean that the Participant is receiving by defa= ult. So how do I indicate that a Participant is NOT receiving a stream? 47. Section 6.4.3: "URN UUID of participant *MUST* used in the scope of CSG " What does this mean? 48. Section 6.4.3: "and no new URN UUID has to be created for the same element (participant, stream) between different CS in the same CSG." Concerning the mention of "stream", why are we talking about stream in the = section on participant? 49. Section 6.4.3: "careful usage of URN UUID to original AoR" What does this mean? 50. Section 6.5: "Different instances of Media Stream block would be created whenever there is a change in media (e.g. dir change like pause/resume and/or codec change and/or participant change." It is unclear to me why this would be so. None of the things mentioned here= are attributes of Media Stream, so why would a new block be created if any= of these change? 51. Section 6.5.1: The schema also has mode element, which presumably must have a correspondin= g attribute in the model, yet I don't see it in this section. 52. Section 6.5.2: "Label attribute is used ..." I think we need to say that this corresponds to Media Stream Reference abov= e. 53. Section 6.5.2: "The media mode helps " Is this the "mode" element? 54: "6.6.1. Composition" Why do we need this section? We don't have a "composition" section for "sta= rt-time", for example, this being another example of an element type that c= an appear in different parent elements. John From partr@cisco.com Thu Jul 14 02:00: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 6678121F8AC9 for ; Thu, 14 Jul 2011 02:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.055 X-Spam-Level: X-Spam-Status: No, score=-10.055 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599, J_CHICKENPOX_43=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 ut2ozBgP3sIx for ; Thu, 14 Jul 2011 02:00: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 DA26121F87D9 for ; Thu, 14 Jul 2011 02:00:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=6480; q=dns/txt; s=iport; t=1310634016; x=1311843616; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=4Pcu8dXMOVkUd8GTmIDCi5ErEWFu4giIch+34NdaATE=; b=YLEqHaYNKCt1w/C5lWQSy7uWQ3u6/6kBzGAdS59dNnH24R9bajM6re+L E9ep9kR8+lZW0jnHUmarhy/3iFZ+lSoxOeGTWkbH6hEVsldWqsNtIW2P0 uzoHXE5icNiaIfv5GLo7iBdJvHbtMhHjpQoJ8JmzwjywWZMZmaRMy66uq 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvgAABqvHk5Io8UT/2dsb2JhbABTEJgCjz53q3qeJYVbXwSHUZAcixA/ X-IronPort-AV: E=Sophos;i="4.65,528,1304294400"; d="scan'208";a="102059699" Received: from bgl-core-4.cisco.com ([72.163.197.19]) by ams-iport-1.cisco.com with ESMTP; 14 Jul 2011 09:00:11 +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 p6E90BGI002255; Thu, 14 Jul 2011 09:00: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); Thu, 14 Jul 2011 14:30: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: Thu, 14 Jul 2011 14:30:09 +0530 Message-ID: In-Reply-To: <4E1E0259.6070103@alum.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Format options for unique IDs - INPUT REQUIRED Thread-Index: AcxBnQVM7PH45QkRQo+GhzAuCE9S9QAZnPPg References: <4E04A13F.8090506@cisco.com> <4E1E0259.6070103@alum.mit.edu> From: "Parthasarathi R (partr)" To: "Paul Kyzivat" , X-OriginalArrivalTime: 14 Jul 2011 09:00:11.0632 (UTC) FILETIME=[702ECF00:01CC4204] Cc: "Peter Saint-Andre \(psaintan\)" Subject: Re: [siprec] Format options for unique IDs - INPUT REQUIRED X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 09:00:17 -0000 Paul, I'm fine with Option (C) which is a network optimization for URN UUID(RFC 4122). Including Peter & Joe in this mail thread who initially proposed URN UUID to see any other downside in radix64 format unique-id from XML perspective apart from the need for defining network byte order which you have mentioned below. XML readability will be missing in case radix64 is used because of the encoding format but I really don't know whether it matters. Thanks Partha =20 > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Thursday, July 14, 2011 2:09 AM > To: siprec@ietf.org > Subject: Re: [siprec] Format options for unique IDs - INPUT REQUIRED >=20 > On 7/13/11 3:53 PM, Charles Eckel (eckelcu) wrote: > > I was hoping there would be discussion around additional=20 > pros and cons=20 > > of each approach. As that has not happened, and I do not=20 > have any of=20 > > my own to propose, option C looks best to me as well. >=20 > After writing them all out, I could find little to dislike about (C). >=20 > One additional con for (C): its a unique format created just=20 > for siprec, rather than being some already recognized format. >=20 > If we go that way, we will have to be careful to precisely=20 > specify the encoding. I found RFC4648, which gives rules for=20 > the encoding. And of course we must define the byte order for=20 > this - network byte order.=20 > Those with little-endian machines (e.g. x86) will have to be=20 > careful about the encoding. >=20 > Does anybody know if a format such as this has already been=20 > defined in xml? >=20 > Thanks, > Paul >=20 > > Cheers, > > Charles > > > >> -----Original Message----- > >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Elwell, John > >> Sent: Wednesday, July 13, 2011 1:15 AM > >> To: Paul Kyzivat (pkyzivat); siprec@ietf.org > >> Subject: Re: [siprec] Format options for unique IDs -=20 > INPUT REQUIRED > >> > >> Although it was in reply to me, I think this list of possibilities > > proposed by Paul a few weeks ago > >> should have attracted comment from the rest of the group,=20 > but I don't > > recall seeing anything. > >> Personally, C) looks attractive, but I don't have a strong opinion. > > Would others please express > >> opinions - it is important to get some sort of closure on this. > >> > >> John > >> > >> > >>> -----Original Message----- > >>> From: siprec-bounces@ietf.org > >>> [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > >>> Sent: 24 June 2011 15:38 > >>> To: siprec@ietf.org > >>> Subject: [siprec] Format options for unique IDs > >>> > >>> > >>> > >>> On 6/24/2011 5:58 AM, Elwell, John wrote: > >>> > >>>> - Options for globally unique IDs, along with pros and cons > >>> (Partha to initiate) > >>> > >>> I'm not Partha, but I'll comment. Some possibilities: > >>> > >>> A) A generic URN, with added constraint that equality is > >>> based only on lexical equivalence (as defined in rfc 2141) > >>> > >>> B) UUID URN (rfc 4122) > >>> > >>> C) UUID encoded more densely than the UUID URN > >>> (e.g. radix64 of the binary uuid form defined in 4122) > >>> > >>> Pros/cons of these: > >>> > >>> A) Pro: very flexible for the SRC. It has many options for > >>> how to create and encode IDs. > >>> > >>> Pro: ease of generation, assuming the SRC chooses wisely. > >>> > >>> Con: Difficult for the SRS. It must deal with variable > >>> unbounded length ID. Doesn't easily fit in databases. > >>> > >>> Con: Somewhat inefficient wire encoding: > >>> there is minimum length of "URN:" plus NID (namespace > > identifier). > >>> > >>> Pro/Con: Wire efficiency varies depending on SRC choices. > >>> Could be very good or very bad, depending on what=20 > NID is chosen. > >>> > >>> B) Pro: very flexible for the SRC. 4122 provides multiple ways of > >>> generating the UUID. One of them (the name based one) would > >>> allow generating a UUID from the same strings you might use > >>> for (A), so its at least as flexible as (A). > >>> > >>> Pro: easy of generation. Like (A), but then requires an SHA-1 > >>> computation. So not as easy as (A). > >>> > >>> Pro: Simple for SRS. The UUID can be easily extracted from > >>> the URN and converted to a fixed length (16 bytes)=20 > binary value. > >>> That value then can be stored in databases, compared, etc. > >>> > >>> Con: Somewhat inefficient wire encoding. The urn encoding is > >>> 45 bytes. > >>> > >>> Pro: Flexible to future extension to other sorts of URNs > >>> (e.g. (A)) due to the use of the URN syntax. > >>> > >>> C) Pro: very flexible for the SRC. (Identical to (B)) > >>> > >>> Pro: easy of generation. Virtually the same as (B). > >>> (The final textual formatting is different from (B), but > >>> similar (insignificant) computationally.) > >>> > >>> Pro: Simple for SRS. Virtually the same as (B). > >>> (The final textual formatting is different from (B), but > >>> similar (insignificant) computationally.) > >>> > >>> Pro: Efficient wire encoding. > >>> (Radix 64 takes 22 bytes to represent the 16 binary bytes.) > >>> > >>> For the metadata these would probably all be wrapped in XML in=20 > >>> comparable ways, so none has an advantage over another in that=20 > >>> respect. > >>> > >>> Please feel free to propose other alternatives. > >>> > >>> As a specific example, for the UUIDs, one could use the=20 > 4122 "name=20 > >>> based" approach, where the "name" is just a binary=20 > integer counter. > >>> > >>> 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 > > >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec >=20 From john.elwell@siemens-enterprise.com Thu Jul 14 06:19: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 F067921F8834 for ; Thu, 14 Jul 2011 06:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.45 X-Spam-Level: X-Spam-Status: No, score=-106.45 tagged_above=-999 required=5 tests=[AWL=0.149, 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 uTF3e4JUyGzO for ; Thu, 14 Jul 2011 06:19:39 -0700 (PDT) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfa.amsl.com (Postfix) with SMTP id 1458D21F881C for ; Thu, 14 Jul 2011 06:19:38 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1310649563!32338317!3 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 7549 invoked from network); 14 Jul 2011 13:19:24 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-3.tower-27.messagelabs.com with SMTP; 14 Jul 2011 13:19:24 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id B148123F03E2 for ; Thu, 14 Jul 2011 15:19:37 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 14 Jul 2011 15:19:37 +0200 From: "Elwell, John" To: "siprec@ietf.org" Date: Thu, 14 Jul 2011 15:19:36 +0200 Thread-Topic: Handling of element deletions Thread-Index: AcxCKK1FpF+BmkSGRsWdGChuZMhDuw== 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] Handling of element deletions X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 13:19:40 -0000 One thing that is not clear to me in the metadata draft is how to use parti= al updates to show deletion of an element, e.g., when a participant leaves = a conference. Can somebody explain? John= From john.elwell@siemens-enterprise.com Thu Jul 14 06:20: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 A06E121F899F for ; Thu, 14 Jul 2011 06:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.454 X-Spam-Level: X-Spam-Status: No, score=-106.454 tagged_above=-999 required=5 tests=[AWL=0.145, 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 gLHOS+uehq6j for ; Thu, 14 Jul 2011 06:20:34 -0700 (PDT) Received: from mail216.messagelabs.com (mail216.messagelabs.com [85.158.143.99]) by ietfa.amsl.com (Postfix) with SMTP id 5FDC421F881C for ; Thu, 14 Jul 2011 06:20:34 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-8.tower-216.messagelabs.com!1310649624!10287274!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 31252 invoked from network); 14 Jul 2011 13:20:24 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-8.tower-216.messagelabs.com with SMTP; 14 Jul 2011 13:20:24 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 8094C23F03E2 for ; Thu, 14 Jul 2011 15:20:24 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 14 Jul 2011 15:20:24 +0200 From: "Elwell, John" To: "siprec@ietf.org" Date: Thu, 14 Jul 2011 15:20:22 +0200 Thread-Topic: Handling of end times Thread-Index: AcxCKMkYNBVA480TRsW/CJfNZYKasA== 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] Handling of end times X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 13:20:35 -0000 One thing that is not clear to me in the metadata draft is the handling of = stop times. For example, suppose there is a CS being recorded with a number of particip= ants and a number of media streams. During recording the XML document will = show these various objects as XML elements with start times and no stop tim= es. What happens when the CS ends? Possibilities include: 1. Updating the XML to show removal of the elements concerned. But in this = case there is no opportunity to show stop times for any of the elements. 2. Updating the XML to add stop times to the various elements. But in this = case the elements concerned remain in existence, even though the objects th= ey are modelling have disappeared. 3. Do 2 followed almost immediately by 1. Any opinions? John= From rmohanr@cisco.com Thu Jul 14 07:59: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 1ED6B21F8B2C for ; Thu, 14 Jul 2011 07:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.26 X-Spam-Level: X-Spam-Status: No, score=-10.26 tagged_above=-999 required=5 tests=[AWL=0.339, 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 gVeSx7OYFd2L for ; Thu, 14 Jul 2011 07:59:08 -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 ED63421F8B20 for ; Thu, 14 Jul 2011 07:59:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=4801; q=dns/txt; s=iport; t=1310655548; x=1311865148; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=EiBH2hJDL2utPKpVzvnJx5uIiNsvIrZIRwuZIWdp3lE=; b=Z/N1XQDZSQ77PBoz3XxjUG8UWq69sbjrfcul9JxqbTYZE3aNHsIFSSvS GEI0ZC8/LSdEgM3S0jbavupEVTMTX4svEwYfpdSc/pD8iE15uzc4kGfmB R7lwGbjgbmrywfmSqDNYUcdpm39DonMKFvnbaPVLQ6MMt+fn9jBXDUdLE M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuIAAM0DH05Io8UR/2dsb2JhbABTmBKPQXeIeqN0nh6FW18Eh1GQHItQ X-IronPort-AV: E=Sophos;i="4.65,529,1304294400"; d="scan'208";a="102184117" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-1.cisco.com with ESMTP; 14 Jul 2011 14:59:06 +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 p6EEx5X7009390; Thu, 14 Jul 2011 14:59:05 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Jul 2011 20:29:05 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Jul 2011 20:29:04 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD0705563A@XMB-BGL-417.cisco.com> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Review of metadata-03 Thread-Index: AcxCBGRNA+vWWzKOQdKee6BfMA3hewAAfLcg References: From: "Ram Mohan R (rmohanr)" To: "Elwell, John" , X-OriginalArrivalTime: 14 Jul 2011 14:59:05.0815 (UTC) FILETIME=[938E5E70:01CC4236] Subject: Re: [siprec] Review of metadata-03 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 14:59:09 -0000 Hi John, Thanks a lot for your elaborate review and comments. I will respond to your comments in sets (to avoid large mail-threads). Here are answers (inline) to few comments (First 6). > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Elwell, John > Sent: Thursday, July 14, 2011 2:30 PM > To: siprec@ietf.org > Subject: [siprec] Review of metadata-03 >=20 > I have reviewed metadata-03 up to and including section 6 and have the > following comments (as individual): >=20 > 1. In general, we are much too liberal with normative language. I have > highlighted in later comments some particular places where we use it > inappropriately. In particular, we should not use it for things that > are more a matter for the protocol document. Also, since this document > is defining the metadata model and its XML representation, I think we > can just use simple present tense, rather than normative statements, to > state what the model or its XML representation is. This applies in many > places, but I have avoided repeating my comments in all places. I agree for the text related to the model we can remove the normative statements. IMO at least for the XML schema portions we need to have normative statements as this document is a proposed standard. Please let us know If I am missing something. > 2. In general, we should avoid saying too much about the protocol or > about conveyance of a metadata XML document, but should restrict > ourselves, as far as possible, to the model and the XML document > format. Again, specific comments touch on this. We have already removed some of the sections to delivery (like examples). I will look at your specific comments to see if anything else needs to be moved >=20 > 3. On terminology, I think it might be more helpful to restrict the > term "element" to cases where we are talking about XML elements, and > use some other term (e.g., object, class) when talking about components > of the model. Then we could say, for example, that a 'stream' XML > element represents a 'Media Stream' object or an object of class 'Media > Stream'. The model uses UML notation/terminology where as Schema uses XML terminology. I will go over the draft again and correct where ever required. >=20 > 4. Related to this, I think we should stick to a single convention, > either: > - use the same name for the model object and for the corresponding XML > element (we do this for "Participant", for example, at present); or > - use different names (we do this for "Media Stream" and "stream", for > example, at present). We have used the names "stream", "session" in XML schema to keep the number of characters to minimum and still convey meaning. The metadata element names has long names like "Communication Session". To show the mapping we have defined the XML element equivalent to a metadata element within the same section. Is this not clear enough ? Or Do you still prefer same names across model & format ? >=20 > 5. Section 3: > "Metadata element: A metadata element represent one block/class of > metadata model." > This says what it represents, not what it is. Is it an XML element or > what? Also, all definitions should be in the form of a dictionary > definition, not a sentence. Let me try to suggest a better list of definitions. Please suggest corrections. Metadata model: The metadata model is a UML class diagram and has a collection of classes. Metadata model class diagram show the classes, their interrelationships (which includes association, composition). Metadata element or Metadata block: Each class in the metadata UML class diagram is called as metadata element/block in this document. The metadata model has a collection of metadata elements. Examples include Recording Session element/block, Participant element/block e.t.c. Each metadata element has an upper part that holds the name of the class (Examples - Recording Session, Communication Session Group, Communication Session) and the bottom part that contains the attributes of the class (Examples- Start Time, End Time). >=20 > 6. Terms "Metadata attributes" and "XML attributes are defined (section > 3) but not used. >=20 The intent here to describe what "attribute" means. We have sections for each element that talks about attributes of each class. Is it ok if I put the definition as below. Or is the above definition of Metadata element sufficient to cover attributes also ? attributes: attribute represents attributes of a Metadata element or metadata block. The attributes are represented at the bottom part of a metadata element. Examples include Start Time, End Time e.t.c. Regards, Ram From rmohanr@cisco.com Thu Jul 14 08:36: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 28DB321F8640 for ; Thu, 14 Jul 2011 08:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.278 X-Spam-Level: X-Spam-Status: No, score=-10.278 tagged_above=-999 required=5 tests=[AWL=0.321, 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 F+VcUnGN6R2r for ; Thu, 14 Jul 2011 08:36: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 B683921F8505 for ; Thu, 14 Jul 2011 08:36:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=1408; q=dns/txt; s=iport; t=1310657776; x=1311867376; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=F4T4qqnL7YiT0W6WJnRSPMNn5+vwa1ktkGu5bhCF4+U=; b=KiJwrsmP5vB6xzxlQIzKi9bWCDNueU/iMV+1QTfN6brW2LYy9CkQE1Gc 3pr59SoRWGCZdOgEpiQqEDVnCx4CCrtlmRBPIskvlT0/4l4FyaO+WJZdf P+5DqhB0ToBhue+PpA9rZNtTRAyuSIMBBO7nQ2s1FDN4+NRygUswe3Aln U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuIAABIMH05Io8UT/2dsb2JhbABTmBSPQXesZJ4hhVtfBIdRkByLUA X-IronPort-AV: E=Sophos;i="4.65,529,1304294400"; d="scan'208";a="102198547" Received: from bgl-core-4.cisco.com ([72.163.197.19]) by ams-iport-1.cisco.com with ESMTP; 14 Jul 2011 15:36:14 +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 p6EFaEsg031578; Thu, 14 Jul 2011 15:36:14 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Jul 2011 21:06:14 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Jul 2011 21:06:12 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD07055655@XMB-BGL-417.cisco.com> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Handling of element deletions Thread-Index: AcxCKK1FpF+BmkSGRsWdGChuZMhDuwAElipQ References: From: "Ram Mohan R (rmohanr)" To: "Elwell, John" , X-OriginalArrivalTime: 14 Jul 2011 15:36:14.0308 (UTC) FILETIME=[C3D76A40:01CC423B] Subject: Re: [siprec] Handling of element deletions X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 15:36:42 -0000 Hi John, Currently "stop-time" attribute in the XML schema is used to indicate the end/deletion of an element. For example, in a conference if a participant leaves/drops, a metadata with "stop-time" for that "participant" element will be sent from SRC to SRS. e.g. sip:rmohanr@blr.cisco.com 2011-07-14T23:41:07Z =20 That is one of the reasons why we have start-time /stop-time for each of the XML elements in the schema. Regards, Ram > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Elwell, John > Sent: Thursday, July 14, 2011 6:50 PM > To: siprec@ietf.org > Subject: [siprec] Handling of element deletions >=20 > One thing that is not clear to me in the metadata draft is how to use > partial updates to show deletion of an element, e.g., when a > participant leaves a conference. Can somebody explain? >=20 > John > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From john.elwell@siemens-enterprise.com Thu Jul 14 08:41:02 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70C9721F8AFE for ; Thu, 14 Jul 2011 08:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.459 X-Spam-Level: X-Spam-Status: No, score=-106.459 tagged_above=-999 required=5 tests=[AWL=0.140, 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 jy0UnaV3ub1q for ; Thu, 14 Jul 2011 08:41:01 -0700 (PDT) Received: from mail174.messagelabs.com (mail174.messagelabs.com [85.158.138.51]) by ietfa.amsl.com (Postfix) with SMTP id 69CDA21F8B06 for ; Thu, 14 Jul 2011 08:40:47 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-2.tower-174.messagelabs.com!1310658045!24780286!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 9832 invoked from network); 14 Jul 2011 15:40:45 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-2.tower-174.messagelabs.com with SMTP; 14 Jul 2011 15:40:45 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id D5E011EB83EE; Thu, 14 Jul 2011 17:40:45 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 14 Jul 2011 17:40:45 +0200 From: "Elwell, John" To: "Ram Mohan R (rmohanr)" , "siprec@ietf.org" Date: Thu, 14 Jul 2011 17:40:44 +0200 Thread-Topic: [siprec] Review of metadata-03 Thread-Index: AcxCBGRNA+vWWzKOQdKee6BfMA3hewAAfLcgAAxxEDA= Message-ID: References: <35BCE99A477D6A4986FB2216D8CF2CFD0705563A@XMB-BGL-417.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD0705563A@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] Review of metadata-03 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 15:41:02 -0000 Ram, Thanks for responding quickly on these. See my further remarks below:=20 > -----Original Message----- > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com]=20 > Sent: 14 July 2011 15:59 > To: Elwell, John; siprec@ietf.org > Subject: RE: [siprec] Review of metadata-03 >=20 > Hi John, >=20 > Thanks a lot for your elaborate review and comments. I will respond to > your comments in sets (to avoid large mail-threads). > Here are answers (inline) to few comments (First 6). >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Elwell, John > > Sent: Thursday, July 14, 2011 2:30 PM > > To: siprec@ietf.org > > Subject: [siprec] Review of metadata-03 > >=20 > > I have reviewed metadata-03 up to and including section 6=20 > and have the > > following comments (as individual): > >=20 > > 1. In general, we are much too liberal with normative=20 > language. I have > > highlighted in later comments some particular places where we use it > > inappropriately. In particular, we should not use it for things that > > are more a matter for the protocol document. Also, since=20 > this document > > is defining the metadata model and its XML representation,=20 > I think we > > can just use simple present tense, rather than normative statements, > to > > state what the model or its XML representation is. This applies in > many > > places, but I have avoided repeating my comments in all places. >=20 >=20 > I agree for the text related to the model we can remove the normative > statements. > IMO at least for the XML schema portions we need to have normative > statements as this document is a proposed standard. Please let us know > If I am missing something. [JRE] Of course, the schema itself does not contain prose, so cannot contai= n normative statements. But normative statements might be appropriate in so= me places, e.g., XML documents MUST use this schema. >=20 > > 2. In general, we should avoid saying too much about the protocol or > > about conveyance of a metadata XML document, but should restrict > > ourselves, as far as possible, to the model and the XML document > > format. Again, specific comments touch on this. >=20 > We have already removed some of the sections to delivery (like > examples). I will look at your specific comments to see if=20 > anything else > needs to be moved >=20 > >=20 > > 3. On terminology, I think it might be more helpful to restrict the > > term "element" to cases where we are talking about XML elements, and > > use some other term (e.g., object, class) when talking about > components > > of the model. Then we could say, for example, that a 'stream' XML > > element represents a 'Media Stream' object or an object of class > 'Media > > Stream'. > The model uses UML notation/terminology where as Schema uses XML > terminology. I will go over the draft again and correct where ever > required. [JRE] The main thing is consistency and avoiding ambiguity. It would be bet= ter to avoid using the term "element" for both things, if at all possible. = Otherwise we will need somewhat clumsy constructs such as "XML element X re= presents an instance of UML element Y". Also, I don't know if we need a reference to UML or whether that is already= used in RFCs without the need for a reference. >=20 > >=20 > > 4. Related to this, I think we should stick to a single convention, > > either: > > - use the same name for the model object and for the=20 > corresponding XML > > element (we do this for "Participant", for example, at present); or > > - use different names (we do this for "Media Stream" and=20 > "stream", for > > example, at present). >=20 > We have used the names "stream", "session" in XML schema to keep the > number of characters to minimum and still convey meaning. The metadata > element names has long names like "Communication Session". To show the > mapping we have defined the XML element equivalent to a=20 > metadata element > within the same section. Is this not clear enough ? Or Do you still > prefer same names across model & format ? [JRE] I said either always use the same name for both or always use differe= nt names for both. I agree that XML names should not be too long and also t= hat UML names should clearly describe what they mean (and therefore may be = longer), so perhaps always making them different is the better choice. That= would involve finding a solution for "participant", where there isn't an o= bvious longer form or shorter form (except perhaps "party"). I don't mind t= oo much if you ignore this comments - I just thought it would be a nice-to-= have. >=20 > >=20 > > 5. Section 3: > > "Metadata element: A metadata element represent one block/class of > > metadata model." > > This says what it represents, not what it is. Is it an XML=20 > element or > > what? Also, all definitions should be in the form of a dictionary > > definition, not a sentence. >=20 > Let me try to suggest a better list of definitions. Please suggest > corrections. >=20 > Metadata model: The metadata model is a UML class diagram and has a > collection of classes. Metadata model class diagram show the classes, > their interrelationships (which includes association, composition). [JRE] First, it should be worded as a dictionary definition, not as sentenc= es. Secondly, the first sentence doesn't seem sufficiently complete to me a= nd the second sentence says nothing more than what a UML class diagram is, = i.e., it is not specific to a metadata model. So how about: "Metadata model: An abstract representation of metadata using a UML class d= iagram." >=20 > Metadata element or Metadata block: Each class in the=20 > metadata UML class > diagram is called as metadata element/block in this document. The > metadata model has a collection of metadata elements.=20 [JRE] Why do we need two terms for the same thing? (metadata element and me= tadata block)? The term "block" has the advantage of avoiding a clash with = XML elements. But what is the difference between a "block" and a "class" -= excuse my weakness on UML. > Examples include > Recording Session element/block, Participant element/block e.t.c.=20 [JRE] If we need to give examples as part of a definition, the definition i= s weak. > Each > metadata element has an upper part that holds the name of the class [JRE] This should not be part of the definition - it describes structure. H= owever, if you are trying to describe how to interpret a diagram, as oppose= d to producing a definition, this type of information may be fine. > (Examples - Recording Session, Communication Session Group, > Communication Session) and the bottom part that contains the=20 > attributes > of the class (Examples- Start Time, End Time). >=20 > >=20 > > 6. Terms "Metadata attributes" and "XML attributes are defined > (section > > 3) but not used. > >=20 >=20 > The intent here to describe what "attribute" means. We have=20 > sections for > each element that talks about attributes of each class. Is it ok if I > put the definition as below. Or is the above definition of Metadata > element sufficient to cover attributes also ? [JRE] One issue is that in XML, the term attribute has a specific meaning. = It would be good not to use "attribute" for the model, to avoid clash with = XML, but I fear that may be unavoidable. I don't recall exactly what its me= aning is in UML. If we use it as in UML, we should not need to redefine it. >=20 > attributes: attribute represents attributes of a Metadata element or > metadata block.=20 [JRE] If we eliminate "metadata element" to avoid having two terms for the = same thing, this definition would reduce to "attribute represents attribute= s of a Metadata block", which tells me very little (and also conflicts with= XML attribute). > The attributes are represented at the bottom part of a > metadata element. Examples include Start Time, End Time e.t.c. [JRE] This is telling me how to interpret a diagram - it should not be part= of a definition. John (as individual) >=20 > Regards, > Ram > = From rmohanr@cisco.com Thu Jul 14 08:41: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 CCE8F21F8B6E for ; Thu, 14 Jul 2011 08:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.294 X-Spam-Level: X-Spam-Status: No, score=-10.294 tagged_above=-999 required=5 tests=[AWL=0.305, 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 5dJnIp10S3Bn for ; Thu, 14 Jul 2011 08:41: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 6546721F8B77 for ; Thu, 14 Jul 2011 08:40:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=1400; q=dns/txt; s=iport; t=1310658053; x=1311867653; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=+BxOjBSKAo0srzeBJ9fipCu0J/b5Q77DPyhu+mIYxUY=; b=OW3T54uapapuNSNSHRmJY/g7kJ5CQxyO1XjxlhgUWVvV951ZB1UYKQKt gD35+6Zs6PJbCIyFvLzg28eVhOmH8AzPaed9uSCBP1F6h8rBCpMtaE5gW 1vzM6lM35+SQ7ofTaD7LnMD4f/jbcJcDDl9NTwhGm9A4o5AYmjddnkyd3 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAAFYNH05Io8UQ/2dsb2JhbABTmBSPQXeIeqNuniKFW18Eh1GQHItQ X-IronPort-AV: E=Sophos;i="4.65,529,1304294400"; d="scan'208";a="102199908" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-1.cisco.com with ESMTP; 14 Jul 2011 15:40:51 +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 p6EFepxh023325; Thu, 14 Jul 2011 15:40:51 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Jul 2011 21:10:51 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Jul 2011 21:10:49 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD07055662@XMB-BGL-417.cisco.com> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Handling of end times Thread-Index: AcxCKMkYNBVA480TRsW/CJfNZYKasAAEyoNg References: From: "Ram Mohan R (rmohanr)" To: "Elwell, John" , X-OriginalArrivalTime: 14 Jul 2011 15:40:51.0079 (UTC) FILETIME=[68CF5170:01CC423C] Subject: Re: [siprec] Handling of end times X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 15:41:05 -0000 Hi John, Please see inline > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Elwell, John > Sent: Thursday, July 14, 2011 6:50 PM > To: siprec@ietf.org > Subject: [siprec] Handling of end times >=20 > One thing that is not clear to me in the metadata draft is the handling > of stop times. >=20 > For example, suppose there is a CS being recorded with a number of > participants and a number of media streams. During recording the XML > document will show these various objects as XML elements with start > times and no stop times. What happens when the CS ends? Possibilities > include: >=20 > 1. Updating the XML to show removal of the elements concerned. But in > this case there is no opportunity to show stop times for any of the > elements. >=20 > 2. Updating the XML to add stop times to the various elements. But in > this case the elements concerned remain in existence, even though the > objects they are modelling have disappeared. If CS has ended an updated XML schema with stop-time attribute added shall be sent for each of the deleted element. Regards, Ram >=20 > 3. Do 2 followed almost immediately by 1. >=20 > Any opinions? >=20 > John > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From john.elwell@siemens-enterprise.com Thu Jul 14 08:46: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 26B3321F85F9 for ; Thu, 14 Jul 2011 08:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.463 X-Spam-Level: X-Spam-Status: No, score=-106.463 tagged_above=-999 required=5 tests=[AWL=0.136, 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 KX-7eq+Vx7vZ for ; Thu, 14 Jul 2011 08:46:38 -0700 (PDT) Received: from mail21.messagelabs.com (mail21.messagelabs.com [85.158.143.35]) by ietfa.amsl.com (Postfix) with SMTP id 64B9E21F8686 for ; Thu, 14 Jul 2011 08:45:52 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1310658325!53279111!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 9369 invoked from network); 14 Jul 2011 15:45:25 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-4.tower-21.messagelabs.com with SMTP; 14 Jul 2011 15:45:25 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id D64AF1EB83ED; Thu, 14 Jul 2011 17:45:50 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 14 Jul 2011 17:45:50 +0200 From: "Elwell, John" To: "Ram Mohan R (rmohanr)" , "siprec@ietf.org" Date: Thu, 14 Jul 2011 17:45:48 +0200 Thread-Topic: [siprec] Handling of element deletions Thread-Index: AcxCKK1FpF+BmkSGRsWdGChuZMhDuwAElipQAABdCbA= Message-ID: References: <35BCE99A477D6A4986FB2216D8CF2CFD07055655@XMB-BGL-417.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD07055655@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] Handling of element deletions X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 15:46:39 -0000 Ram, So you are saying that that if the SRS receives an XML document showing an = element with a stop time, it can implicitly consider that element deleted? = The deletion would never be explicitly shown until the next time a complete= snapshot is sent? If this is a common understanding of the WG, I would suggest it merits some= explanation in the draft. John > -----Original Message----- > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com]=20 > Sent: 14 July 2011 16:36 > To: Elwell, John; siprec@ietf.org > Subject: RE: [siprec] Handling of element deletions >=20 > Hi John, >=20 > Currently "stop-time" attribute in the XML schema is used to indicate > the end/deletion of an element. > For example, in a conference if a participant leaves/drops, a metadata > with "stop-time" for that "participant" element will be sent=20 > from SRC to > SRS. >=20 > e.g. >=20 > > > id=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > session=3D"urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> > sip:rmohanr@blr.cisco.com > 2011-07-14T23:41:07Z > > =20 >=20 > That is one of the reasons why we have start-time /stop-time=20 > for each of > the XML elements in the schema. >=20 > Regards, > Ram >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Elwell, John > > Sent: Thursday, July 14, 2011 6:50 PM > > To: siprec@ietf.org > > Subject: [siprec] Handling of element deletions > >=20 > > One thing that is not clear to me in the metadata draft is=20 > how to use > > partial updates to show deletion of an element, e.g., when a > > participant leaves a conference. Can somebody explain? > >=20 > > John > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > = From rmohanr@cisco.com Thu Jul 14 09:02: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 72AE421F88B2 for ; Thu, 14 Jul 2011 09:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.308 X-Spam-Level: X-Spam-Status: No, score=-10.308 tagged_above=-999 required=5 tests=[AWL=0.291, 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 3E6iNK7zix2d for ; Thu, 14 Jul 2011 09:02:37 -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 6FA6F21F8A6F for ; Thu, 14 Jul 2011 09:02:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=3372; q=dns/txt; s=iport; t=1310659357; x=1311868957; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=yLQiAYJwg0jGxBTe7tRfC1dbsvIiSilBNTOCAdYlrAc=; b=W6JKHryqRV2JTnsIMeQFyUbMjMG3JmogxJgN3FTVKhIut16ACgy/JASW NHARgLJPqoamkA0mkwN9oJjpeLzD+PfRv1ew5ZrIWDBmYysuCDZALfB1M M8Fu8l8D/yS1hBoLIDZ0Ay1nOYsEfD0fusBH/G5GN3sneypFWB9Fc2Ecs E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAAOQRH05Io8UR/2dsb2JhbABTmBSPQXetAZ4khVtfBIdRkByLUA X-IronPort-AV: E=Sophos;i="4.65,529,1304294400"; d="scan'208";a="102206598" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-1.cisco.com with ESMTP; 14 Jul 2011 16:02:35 +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 p6EG2ZdG018779; Thu, 14 Jul 2011 16:02:35 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Jul 2011 21:32:35 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Jul 2011 21:32:34 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD07055670@XMB-BGL-417.cisco.com> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Handling of element deletions Thread-Index: AcxCKK1FpF+BmkSGRsWdGChuZMhDuwAElipQAABdCbAAAGyp4A== References: <35BCE99A477D6A4986FB2216D8CF2CFD07055655@XMB-BGL-417.cisco.com> From: "Ram Mohan R (rmohanr)" To: "Elwell, John" , X-OriginalArrivalTime: 14 Jul 2011 16:02:35.0265 (UTC) FILETIME=[722A4F10:01CC423F] Subject: Re: [siprec] Handling of element deletions X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 16:02:38 -0000 John, SRS can consider stop-time and mark an element has ended. It need not wait for the next snapshot from SRC to find out that an element is deleted. Examples of how start-time / end-time may be calculated - For RS element start-time /stop-time will be implicitly inferred by SRS from the time at which SIP dialog is setup /disconnected - For a group element (CS-Group) start-time is when CS-Group is started, stop-time is when CS-group ends - For a session element (CS ) start-time is when the CS is setup, stop-time is when CS ends - For a participant start-time is the time at which he joins the conference, stop-time is when he leaves conference. - If we have an MS element ( having a unique id), the start/stop time of the MS can be derived from the time of arrival of first participant, time of departure of last participant. Assume here that the MS is mixed stream. Regards, Ram > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Thursday, July 14, 2011 9:16 PM > To: Ram Mohan R (rmohanr); siprec@ietf.org > Subject: RE: [siprec] Handling of element deletions >=20 > Ram, >=20 > So you are saying that that if the SRS receives an XML document showing > an element with a stop time, it can implicitly consider that element > deleted? The deletion would never be explicitly shown until the next > time a complete snapshot is sent? >=20 > If this is a common understanding of the WG, I would suggest it merits > some explanation in the draft. >=20 > John >=20 > > -----Original Message----- > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > Sent: 14 July 2011 16:36 > > To: Elwell, John; siprec@ietf.org > > Subject: RE: [siprec] Handling of element deletions > > > > Hi John, > > > > Currently "stop-time" attribute in the XML schema is used to indicate > > the end/deletion of an element. > > For example, in a conference if a participant leaves/drops, a > metadata > > with "stop-time" for that "participant" element will be sent > > from SRC to > > SRS. > > > > e.g. > > > > > > > > > id=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > > = session=3D"urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> > > sip:rmohanr@blr.cisco.com > > 2011-07-14T23:41:07Z > > > > > > > > That is one of the reasons why we have start-time /stop-time > > for each of > > the XML elements in the schema. > > > > Regards, > > Ram > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > > Behalf Of Elwell, John > > > Sent: Thursday, July 14, 2011 6:50 PM > > > To: siprec@ietf.org > > > Subject: [siprec] Handling of element deletions > > > > > > One thing that is not clear to me in the metadata draft is > > how to use > > > partial updates to show deletion of an element, e.g., when a > > > participant leaves a conference. Can somebody explain? > > > > > > John > > > _______________________________________________ > > > siprec mailing list > > > siprec@ietf.org > > > https://www.ietf.org/mailman/listinfo/siprec > > From john.elwell@siemens-enterprise.com Thu Jul 14 09:40: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 EECC621F8D33 for ; Thu, 14 Jul 2011 09:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.466 X-Spam-Level: X-Spam-Status: No, score=-106.466 tagged_above=-999 required=5 tests=[AWL=0.133, 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 EPcKpMaoUBOG for ; Thu, 14 Jul 2011 09:40:12 -0700 (PDT) Received: from mail182.messagelabs.com (mail182.messagelabs.com [85.158.139.83]) by ietfa.amsl.com (Postfix) with SMTP id D790321F8D30 for ; Thu, 14 Jul 2011 09:40:11 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1310661610!11283964!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 28066 invoked from network); 14 Jul 2011 16:40:10 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-11.tower-182.messagelabs.com with SMTP; 14 Jul 2011 16:40:10 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 389BB1EB83D3; Thu, 14 Jul 2011 18:40:10 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 14 Jul 2011 18:40:10 +0200 From: "Elwell, John" To: "Ram Mohan R (rmohanr)" , "siprec@ietf.org" Date: Thu, 14 Jul 2011 18:40:08 +0200 Thread-Topic: [siprec] Handling of element deletions Thread-Index: AcxCKK1FpF+BmkSGRsWdGChuZMhDuwAElipQAABdCbAAAGyp4AABYSjA Message-ID: References: <35BCE99A477D6A4986FB2216D8CF2CFD07055655@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD07055670@XMB-BGL-417.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD07055670@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] Handling of element deletions X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 16:40:13 -0000 =20 > -----Original Message----- > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com]=20 > Sent: 14 July 2011 17:03 > To: Elwell, John; siprec@ietf.org > Subject: RE: [siprec] Handling of element deletions >=20 > John, > SRS can consider stop-time and mark an element has ended. It need not > wait for the next snapshot from SRC to find out that an element is > deleted. [JRE] Yes, that is what I understood from your previous message. >=20 > Examples of how start-time / end-time may be calculated >=20 > - For RS element start-time /stop-time will be implicitly inferred by > SRS from the time at which SIP dialog is setup /disconnected > - For a group element (CS-Group) start-time is when CS-Group is > started, stop-time is when CS-group ends > - For a session element (CS ) start-time is when the CS is setup, > stop-time is when CS ends > - For a participant start-time is the time at which he joins the > conference, stop-time is when he leaves conference. [JRE] Yes, so you are saying here that the SRC could send a complete snapsh= ot of metadata with a CSG, CS or participant removed, and implicitly the st= op time for that entity would be the time of receipt of the snapshot. Alter= natively it can indicate it implicitly by sending an update of the element = with a stop time included. > - If we have an MS element ( having a unique id), the=20 > start/stop time of > the MS can be derived from the time of arrival of first participant, > time of departure of last participant. Assume here that the=20 > MS is mixed > stream. [JRE] This concerns me. It seems to say that if both/all participants tempo= rarily stop their involvement in a media stream (e.g., because of hold), th= at MS implicitly ceases and a new MS has to be created it they rejoin the s= tream? I had not appreciated that - is it what people really want? John (as individual) >=20 > Regards, > Ram > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Thursday, July 14, 2011 9:16 PM > > To: Ram Mohan R (rmohanr); siprec@ietf.org > > Subject: RE: [siprec] Handling of element deletions > >=20 > > Ram, > >=20 > > So you are saying that that if the SRS receives an XML document > showing > > an element with a stop time, it can implicitly consider that element > > deleted? The deletion would never be explicitly shown until the next > > time a complete snapshot is sent? > >=20 > > If this is a common understanding of the WG, I would=20 > suggest it merits > > some explanation in the draft. > >=20 > > John > >=20 > > > -----Original Message----- > > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > > Sent: 14 July 2011 16:36 > > > To: Elwell, John; siprec@ietf.org > > > Subject: RE: [siprec] Handling of element deletions > > > > > > Hi John, > > > > > > Currently "stop-time" attribute in the XML schema is used to > indicate > > > the end/deletion of an element. > > > For example, in a conference if a participant leaves/drops, a > > metadata > > > with "stop-time" for that "participant" element will be sent > > > from SRC to > > > SRS. > > > > > > e.g. > > > > > > > > > > > > > > id=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > > > =20 > session=3D"urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> > > > sip:rmohanr@blr.cisco.com > > > 2011-07-14T23:41:07Z > > > > > > > > > > > > That is one of the reasons why we have start-time /stop-time > > > for each of > > > the XML elements in the schema. > > > > > > Regards, > > > Ram > > > > > > > -----Original Message----- > > > > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On > > > > Behalf Of Elwell, John > > > > Sent: Thursday, July 14, 2011 6:50 PM > > > > To: siprec@ietf.org > > > > Subject: [siprec] Handling of element deletions > > > > > > > > One thing that is not clear to me in the metadata draft is > > > how to use > > > > partial updates to show deletion of an element, e.g., when a > > > > participant leaves a conference. Can somebody explain? > > > > > > > > John > > > > _______________________________________________ > > > > siprec mailing list > > > > siprec@ietf.org > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > = From rmohanr@cisco.com Thu Jul 14 09:54:06 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C35B521F8CD9 for ; Thu, 14 Jul 2011 09:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.322 X-Spam-Level: X-Spam-Status: No, score=-10.322 tagged_above=-999 required=5 tests=[AWL=0.277, 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 7f4SmuA6VszZ for ; Thu, 14 Jul 2011 09:54: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 3D90B21F8CD8 for ; Thu, 14 Jul 2011 09:54:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=5488; q=dns/txt; s=iport; t=1310662442; x=1311872042; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=nc6yiwsgau1XBROYYSa4LhU7L6k45OCz4slM+/Q0LD4=; b=EgiG/ExVHmtwuHRF8One9uEl4gVLeLLPQRSda9hHnOtVvceZ1b0tXlVl RMeJesEV1+v/XAYTasXVOdkb0mqz99gFasaLxFosdPbMxTZzqPTMSKb8+ qwDCdE8vgyu9fib+xz7eciz9GDApJ3pMOlyH3KjwSDC7HLxz8SLWb8k09 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAAMAeH05Io8UT/2dsb2JhbABTmBSPQXeIeqNXniOFW18Eh1GQHItQ X-IronPort-AV: E=Sophos;i="4.65,529,1304294400"; d="scan'208";a="102219837" Received: from bgl-core-4.cisco.com ([72.163.197.19]) by ams-iport-1.cisco.com with ESMTP; 14 Jul 2011 16:53:40 +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 p6EGrdQB010116; Thu, 14 Jul 2011 16:53:39 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Jul 2011 22:23:39 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Jul 2011 22:23:37 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD07055696@XMB-BGL-417.cisco.com> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Handling of element deletions Thread-Index: AcxCKK1FpF+BmkSGRsWdGChuZMhDuwAElipQAABdCbAAAGyp4AABYSjAAABmooA= References: <35BCE99A477D6A4986FB2216D8CF2CFD07055655@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD07055670@XMB-BGL-417.cisco.com> From: "Ram Mohan R (rmohanr)" To: "Elwell, John" , X-OriginalArrivalTime: 14 Jul 2011 16:53:39.0481 (UTC) FILETIME=[94949090:01CC4246] Subject: Re: [siprec] Handling of element deletions X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 16:54:07 -0000 Hi John, Please see inline > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Thursday, July 14, 2011 10:10 PM > To: Ram Mohan R (rmohanr); siprec@ietf.org > Subject: RE: [siprec] Handling of element deletions >=20 >=20 >=20 > > -----Original Message----- > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > Sent: 14 July 2011 17:03 > > To: Elwell, John; siprec@ietf.org > > Subject: RE: [siprec] Handling of element deletions > > > > John, > > SRS can consider stop-time and mark an element has ended. It need not > > wait for the next snapshot from SRC to find out that an element is > > deleted. > [JRE] Yes, that is what I understood from your previous message. >=20 > > > > Examples of how start-time / end-time may be calculated > > > > - For RS element start-time /stop-time will be implicitly inferred by > > SRS from the time at which SIP dialog is setup /disconnected > > - For a group element (CS-Group) start-time is when CS-Group is > > started, stop-time is when CS-group ends > > - For a session element (CS ) start-time is when the CS is setup, > > stop-time is when CS ends > > - For a participant start-time is the time at which he joins the > > conference, stop-time is when he leaves conference. > [JRE] Yes, so you are saying here that the SRC could send a complete > snapshot of metadata with a CSG, CS or participant removed, and > implicitly the stop time for that entity would be the time of receipt > of the snapshot. Alternatively it can indicate it implicitly by sending > an update of the element with a stop time included. Correct. >=20 > > - If we have an MS element ( having a unique id), the > > start/stop time of > > the MS can be derived from the time of arrival of first participant, > > time of departure of last participant. Assume here that the > > MS is mixed > > stream. > [JRE] This concerns me. It seems to say that if both/all participants > temporarily stop their involvement in a media stream (e.g., because of > hold), that MS implicitly ceases and a new MS has to be created it they > rejoin the stream? I had not appreciated that - is it what people > really want? I had given this example assuming MS is same across different CSs. I just re-collected that we agreed in the last interim meeting to have MS scope within a CS and have unique ID to take care of future cases. In case of hold/resume, if its within a CS the same MS will be continued. So in case of new CS, the old MS element has to be stopped by sending stop-time. A new MS will be created for the new CS. Thanks, Ram >=20 > John (as individual) >=20 >=20 > > > > Regards, > > Ram > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > Sent: Thursday, July 14, 2011 9:16 PM > > > To: Ram Mohan R (rmohanr); siprec@ietf.org > > > Subject: RE: [siprec] Handling of element deletions > > > > > > Ram, > > > > > > So you are saying that that if the SRS receives an XML document > > showing > > > an element with a stop time, it can implicitly consider that > element > > > deleted? The deletion would never be explicitly shown until the > next > > > time a complete snapshot is sent? > > > > > > If this is a common understanding of the WG, I would > > suggest it merits > > > some explanation in the draft. > > > > > > John > > > > > > > -----Original Message----- > > > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > > > Sent: 14 July 2011 16:36 > > > > To: Elwell, John; siprec@ietf.org > > > > Subject: RE: [siprec] Handling of element deletions > > > > > > > > Hi John, > > > > > > > > Currently "stop-time" attribute in the XML schema is used to > > indicate > > > > the end/deletion of an element. > > > > For example, in a conference if a participant leaves/drops, a > > > metadata > > > > with "stop-time" for that "participant" element will be sent > > > > from SRC to > > > > SRS. > > > > > > > > e.g. > > > > > > > > > > > > > > > > > > > id=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > > > > > > session=3D"urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> > > > > sip:rmohanr@blr.cisco.com > > > > 2011-07-14T23:41:07Z > > > > > > > > > > > > > > > > That is one of the reasons why we have start-time /stop-time > > > > for each of > > > > the XML elements in the schema. > > > > > > > > Regards, > > > > Ram > > > > > > > > > -----Original Message----- > > > > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On > > > > > Behalf Of Elwell, John > > > > > Sent: Thursday, July 14, 2011 6:50 PM > > > > > To: siprec@ietf.org > > > > > Subject: [siprec] Handling of element deletions > > > > > > > > > > One thing that is not clear to me in the metadata draft is > > > > how to use > > > > > partial updates to show deletion of an element, e.g., when a > > > > > participant leaves a conference. Can somebody explain? > > > > > > > > > > John > > > > > _______________________________________________ > > > > > siprec mailing list > > > > > siprec@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > From MBaj@acmepacket.com Thu Jul 14 14:06: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 8112221F853B for ; Thu, 14 Jul 2011 14:06:52 -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 lFBzgdYBc8Kt for ; Thu, 14 Jul 2011 14:06:48 -0700 (PDT) Received: from ETMail2.acmepacket.com (etmail2.acmepacket.com [216.41.24.9]) by ietfa.amsl.com (Postfix) with ESMTP id 84C0111E80D4 for ; Thu, 14 Jul 2011 14:06:44 -0700 (PDT) Received: from MAIL2.acmepacket.com (10.0.0.22) by ETMail2.acmepacket.com (216.41.24.9) with Microsoft SMTP Server (TLS) id 8.1.240.5; Thu, 14 Jul 2011 17:06:38 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.84]) by Mail2.acmepacket.com ([169.254.2.224]) with mapi id 14.01.0270.001; Thu, 14 Jul 2011 17:06:32 -0400 From: Michael Baj To: "Ram Mohan R (rmohanr)" , "Elwell, John" , "siprec@ietf.org" Thread-Topic: [siprec] Handling of element deletions Thread-Index: AcxCKK1FpF+BmkSGRsWdGChuZMhDuwAElipQAABdCbAAAGyp4AABYSjAAABmooAABLqdYA== Date: Thu, 14 Jul 2011 21:06:26 +0000 Message-ID: <3E13DD20C9785C40ADE71497B580671F013FB3@Mail1.acmepacket.com> References: <35BCE99A477D6A4986FB2216D8CF2CFD07055655@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD07055670@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD07055696@XMB-BGL-417.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD07055696@XMB-BGL-417.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.21.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Subject: Re: [siprec] Handling of element deletions X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 21:06:52 -0000 Hi, >From portman-siprec-protocol section 5.4, it states that: "For all basic metadata information such as communication session, particip= ants, call identifiers and direction, they can be included in the initial I= NVITE request sent by the SRC. Metadata can be included as content in the = INVITE or UPDATE request." Have you considered sending the final metadata update in the BYE terminatin= g the recording dialog, or is the SRS to presume that all metadata items st= op when the recording session stops? Otherwise an UPDATE with stop times f= or all metadata items would be required to be sent prior to the BYE. Thanks, Mike -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Ram Mohan R (rmohanr) Sent: Thursday, July 14, 2011 12:54 PM To: Elwell, John; siprec@ietf.org Subject: Re: [siprec] Handling of element deletions Hi John, Please see inline > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Thursday, July 14, 2011 10:10 PM > To: Ram Mohan R (rmohanr); siprec@ietf.org > Subject: RE: [siprec] Handling of element deletions >=20 >=20 >=20 > > -----Original Message----- > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > Sent: 14 July 2011 17:03 > > To: Elwell, John; siprec@ietf.org > > Subject: RE: [siprec] Handling of element deletions > > > > John, > > SRS can consider stop-time and mark an element has ended. It need not > > wait for the next snapshot from SRC to find out that an element is > > deleted. > [JRE] Yes, that is what I understood from your previous message. >=20 > > > > Examples of how start-time / end-time may be calculated > > > > - For RS element start-time /stop-time will be implicitly inferred by > > SRS from the time at which SIP dialog is setup /disconnected > > - For a group element (CS-Group) start-time is when CS-Group is > > started, stop-time is when CS-group ends > > - For a session element (CS ) start-time is when the CS is setup, > > stop-time is when CS ends > > - For a participant start-time is the time at which he joins the > > conference, stop-time is when he leaves conference. > [JRE] Yes, so you are saying here that the SRC could send a complete > snapshot of metadata with a CSG, CS or participant removed, and > implicitly the stop time for that entity would be the time of receipt > of the snapshot. Alternatively it can indicate it implicitly by sending > an update of the element with a stop time included. Correct. >=20 > > - If we have an MS element ( having a unique id), the > > start/stop time of > > the MS can be derived from the time of arrival of first participant, > > time of departure of last participant. Assume here that the > > MS is mixed > > stream. > [JRE] This concerns me. It seems to say that if both/all participants > temporarily stop their involvement in a media stream (e.g., because of > hold), that MS implicitly ceases and a new MS has to be created it they > rejoin the stream? I had not appreciated that - is it what people > really want? I had given this example assuming MS is same across different CSs. I just re-collected that we agreed in the last interim meeting to have MS scope within a CS and have unique ID to take care of future cases. In case of hold/resume, if its within a CS the same MS will be continued. So in case of new CS, the old MS element has to be stopped by sending stop-time. A new MS will be created for the new CS. Thanks, Ram >=20 > John (as individual) >=20 >=20 > > > > Regards, > > Ram > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > Sent: Thursday, July 14, 2011 9:16 PM > > > To: Ram Mohan R (rmohanr); siprec@ietf.org > > > Subject: RE: [siprec] Handling of element deletions > > > > > > Ram, > > > > > > So you are saying that that if the SRS receives an XML document > > showing > > > an element with a stop time, it can implicitly consider that > element > > > deleted? The deletion would never be explicitly shown until the > next > > > time a complete snapshot is sent? > > > > > > If this is a common understanding of the WG, I would > > suggest it merits > > > some explanation in the draft. > > > > > > John > > > > > > > -----Original Message----- > > > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > > > Sent: 14 July 2011 16:36 > > > > To: Elwell, John; siprec@ietf.org > > > > Subject: RE: [siprec] Handling of element deletions > > > > > > > > Hi John, > > > > > > > > Currently "stop-time" attribute in the XML schema is used to > > indicate > > > > the end/deletion of an element. > > > > For example, in a conference if a participant leaves/drops, a > > > metadata > > > > with "stop-time" for that "participant" element will be sent > > > > from SRC to > > > > SRS. > > > > > > > > e.g. > > > > > > > > > > > > > > > > > > > id=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > > > > > > session=3D"urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> > > > > sip:rmohanr@blr.cisco.com > > > > 2011-07-14T23:41:07Z > > > > > > > > > > > > > > > > That is one of the reasons why we have start-time /stop-time > > > > for each of > > > > the XML elements in the schema. > > > > > > > > Regards, > > > > Ram > > > > > > > > > -----Original Message----- > > > > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On > > > > > Behalf Of Elwell, John > > > > > Sent: Thursday, July 14, 2011 6:50 PM > > > > > To: siprec@ietf.org > > > > > Subject: [siprec] Handling of element deletions > > > > > > > > > > One thing that is not clear to me in the metadata draft is > > > > how to use > > > > > partial updates to show deletion of an element, e.g., when a > > > > > participant leaves a conference. Can somebody explain? > > > > > > > > > > John > > > > > _______________________________________________ > > > > > siprec mailing list > > > > > siprec@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From rmohanr@cisco.com Thu Jul 14 21:54: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 03F9A21F867A for ; Thu, 14 Jul 2011 21:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.334 X-Spam-Level: X-Spam-Status: No, score=-10.334 tagged_above=-999 required=5 tests=[AWL=0.265, 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 tBhprBil1RGB for ; Thu, 14 Jul 2011 21:54:44 -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 66F4A21F8679 for ; Thu, 14 Jul 2011 21:54:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=7297; q=dns/txt; s=iport; t=1310705683; x=1311915283; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=FkHYva95B0li3x8q/cm5DLGxUom3a4Jb4Lb1QAIRKoM=; b=bNrIs+GXJxgHFRfbFeLRF+PP7Sb2QWyO+9jUpslw3QneindfbVsxNlGl YP5yaRoBNnTAfrvfL9x6qxswStZsdILkcCe4wgFP73MqUy3gm1B/TPfGc b0ZN9rptKmKqxtwnqbI+ooakzE4yPJZ1LcXBN4MP6e3mL+Vz1MEL//+hZ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvoAAI/HH05Io8UT/2dsb2JhbABUmCKPO3eIeqUInheFW18Eh1KQHotR X-IronPort-AV: E=Sophos;i="4.65,533,1304294400"; d="scan'208";a="102362596" Received: from bgl-core-4.cisco.com ([72.163.197.19]) by ams-iport-1.cisco.com with ESMTP; 15 Jul 2011 04:54:41 +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 p6F4se5I028254; Fri, 15 Jul 2011 04:54:40 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 15 Jul 2011 10:24:40 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 15 Jul 2011 10:24:39 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD0705579F@XMB-BGL-417.cisco.com> In-reply-to: <3E13DD20C9785C40ADE71497B580671F013FB3@Mail1.acmepacket.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Handling of element deletions Thread-Index: AcxCKK1FpF+BmkSGRsWdGChuZMhDuwAElipQAABdCbAAAGyp4AABYSjAAABmooAABLqdYAAUm+mQ References: <35BCE99A477D6A4986FB2216D8CF2CFD07055655@XMB-BGL-417.cisco.com><35BCE99A477D6A4986FB2216D8CF2CFD07055670@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD07055696@XMB-BGL-417.cisco.com> <3E13DD20C9785C40ADE71497B580671F013FB3@Mail1.acmepacket.com> From: "Ram Mohan R (rmohanr)" To: "Michael Baj" , "Elwell, John" , X-OriginalArrivalTime: 15 Jul 2011 04:54:40.0782 (UTC) FILETIME=[4E533AE0:01CC42AB] Subject: Re: [siprec] Handling of element deletions X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 04:54:45 -0000 Hello Michael, Please see inline > -----Original Message----- > From: Michael Baj [mailto:MBaj@acmepacket.com] > Sent: Friday, July 15, 2011 2:36 AM > To: Ram Mohan R (rmohanr); Elwell, John; siprec@ietf.org > Subject: RE: [siprec] Handling of element deletions >=20 > Hi, >=20 > From portman-siprec-protocol section 5.4, it states that: >=20 > "For all basic metadata information such as communication session, > participants, call identifiers and direction, they can be included in > the initial INVITE request sent by the SRC. Metadata can be included > as content in the INVITE or UPDATE request." >=20 > Have you considered sending the final metadata update in the BYE > terminating the recording dialog, or is the SRS to presume that all > metadata items stop when the recording session stops? Otherwise an > UPDATE with stop times for all metadata items would be required to be > sent prior to the BYE. Yes BYE also will carry Metadata. We need to update the protocol draft to reflect this . Thanks, Ram >=20 > Thanks, > Mike >=20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Ram Mohan R (rmohanr) > Sent: Thursday, July 14, 2011 12:54 PM > To: Elwell, John; siprec@ietf.org > Subject: Re: [siprec] Handling of element deletions >=20 > Hi John, >=20 > Please see inline >=20 > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Thursday, July 14, 2011 10:10 PM > > To: Ram Mohan R (rmohanr); siprec@ietf.org > > Subject: RE: [siprec] Handling of element deletions > > > > > > > > > -----Original Message----- > > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > > Sent: 14 July 2011 17:03 > > > To: Elwell, John; siprec@ietf.org > > > Subject: RE: [siprec] Handling of element deletions > > > > > > John, > > > SRS can consider stop-time and mark an element has ended. It need > not > > > wait for the next snapshot from SRC to find out that an element is > > > deleted. > > [JRE] Yes, that is what I understood from your previous message. > > > > > > > > Examples of how start-time / end-time may be calculated > > > > > > - For RS element start-time /stop-time will be implicitly inferred > by > > > SRS from the time at which SIP dialog is setup /disconnected > > > - For a group element (CS-Group) start-time is when CS-Group is > > > started, stop-time is when CS-group ends > > > - For a session element (CS ) start-time is when the CS is setup, > > > stop-time is when CS ends > > > - For a participant start-time is the time at which he joins the > > > conference, stop-time is when he leaves conference. > > [JRE] Yes, so you are saying here that the SRC could send a complete > > snapshot of metadata with a CSG, CS or participant removed, and > > implicitly the stop time for that entity would be the time of receipt > > of the snapshot. Alternatively it can indicate it implicitly by > sending > > an update of the element with a stop time included. >=20 > Correct. >=20 > > > > > - If we have an MS element ( having a unique id), the > > > start/stop time of > > > the MS can be derived from the time of arrival of first > participant, > > > time of departure of last participant. Assume here that the > > > MS is mixed > > > stream. > > [JRE] This concerns me. It seems to say that if both/all participants > > temporarily stop their involvement in a media stream (e.g., because > of > > hold), that MS implicitly ceases and a new MS has to be created it > they > > rejoin the stream? I had not appreciated that - is it what people > > really want? >=20 > I had given this example assuming MS is same across different CSs. I > just re-collected that we agreed in the last interim meeting to have MS > scope within a CS and have unique ID to take care of future cases. In > case of hold/resume, if its within a CS the same MS will be continued. > So in case of new CS, the old MS element has to be stopped by sending > stop-time. A new MS will be created for the new CS. >=20 > Thanks, > Ram >=20 > > > > John (as individual) > > > > > > > > > > Regards, > > > Ram > > > > -----Original Message----- > > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > Sent: Thursday, July 14, 2011 9:16 PM > > > > To: Ram Mohan R (rmohanr); siprec@ietf.org > > > > Subject: RE: [siprec] Handling of element deletions > > > > > > > > Ram, > > > > > > > > So you are saying that that if the SRS receives an XML document > > > showing > > > > an element with a stop time, it can implicitly consider that > > element > > > > deleted? The deletion would never be explicitly shown until the > > next > > > > time a complete snapshot is sent? > > > > > > > > If this is a common understanding of the WG, I would > > > suggest it merits > > > > some explanation in the draft. > > > > > > > > John > > > > > > > > > -----Original Message----- > > > > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > > > > Sent: 14 July 2011 16:36 > > > > > To: Elwell, John; siprec@ietf.org > > > > > Subject: RE: [siprec] Handling of element deletions > > > > > > > > > > Hi John, > > > > > > > > > > Currently "stop-time" attribute in the XML schema is used to > > > indicate > > > > > the end/deletion of an element. > > > > > For example, in a conference if a participant leaves/drops, a > > > > metadata > > > > > with "stop-time" for that "participant" element will be sent > > > > > from SRC to > > > > > SRS. > > > > > > > > > > e.g. > > > > > > > > > > > > > > > > > > > > > > > > = id=3D"urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3" > > > > > > > > session=3D"urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> > > > > > sip:rmohanr@blr.cisco.com > > > > > 2011-07-14T23:41:07Z > > > > > > > > > > > > > > > > > > > > That is one of the reasons why we have start-time /stop-time > > > > > for each of > > > > > the XML elements in the schema. > > > > > > > > > > Regards, > > > > > Ram > > > > > > > > > > > -----Original Message----- > > > > > > From: siprec-bounces@ietf.org > > > [mailto:siprec-bounces@ietf.org] On > > > > > > Behalf Of Elwell, John > > > > > > Sent: Thursday, July 14, 2011 6:50 PM > > > > > > To: siprec@ietf.org > > > > > > Subject: [siprec] Handling of element deletions > > > > > > > > > > > > One thing that is not clear to me in the metadata draft is > > > > > how to use > > > > > > partial updates to show deletion of an element, e.g., when a > > > > > > participant leaves a conference. Can somebody explain? > > > > > > > > > > > > John > > > > > > _______________________________________________ > > > > > > siprec mailing list > > > > > > siprec@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From pkyzivat@alum.mit.edu Fri Jul 15 06:53: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 B625421F863F for ; Fri, 15 Jul 2011 06:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 T8mwL9HeNcFg for ; Fri, 15 Jul 2011 06:53:33 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by ietfa.amsl.com (Postfix) with ESMTP id 36DBF21F85FE for ; Fri, 15 Jul 2011 06:53:33 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta03.westchester.pa.mail.comcast.net with comcast id 8DfP1h0041vXlb853DtZMk; Fri, 15 Jul 2011 13:53:33 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta17.westchester.pa.mail.comcast.net with comcast id 8DtY1h00G0tdiYw3dDtYi2; Fri, 15 Jul 2011 13:53:33 +0000 Message-ID: <4E20465A.4090104@alum.mit.edu> Date: Fri, 15 Jul 2011 09:53:30 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: siprec@ietf.org References: <35BCE99A477D6A4986FB2216D8CF2CFD07055655@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD07055670@XMB-BGL-417.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] Handling of element deletions X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 13:53:33 -0000 On 7/14/11 12:40 PM, Elwell, John wrote: >> - If we have an MS element ( having a unique id), the >> start/stop time of >> the MS can be derived from the time of arrival of first participant, >> time of departure of last participant. Assume here that the >> MS is mixed >> stream. > [JRE] This concerns me. It seems to say that if both/all participants temporarily stop their involvement in a media stream (e.g., because of hold), that MS implicitly ceases and a new MS has to be created it they rejoin the stream? I had not appreciated that - is it what people really want? Why is this concerning? What would it mean to have an MS with no participants? Note that hold doesn't necessarily mean participants leave the media stream. (Typically the receiver is still there as a participant, and there is *some* sender.) But if they all do leave it, what else makes sense? Also note that there could still be an actual RS media stream in place, but not associated with any MS metadata. Thanks, Paul From Henry.Lum@alcatel-lucent.com Fri Jul 15 08:12: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 13C9121F8622 for ; Fri, 15 Jul 2011 08:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.398 X-Spam-Level: X-Spam-Status: No, score=-6.398 tagged_above=-999 required=5 tests=[AWL=0.200, 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 IAucDdgon1kc for ; Fri, 15 Jul 2011 08:12:32 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 0D5EB21F862E for ; Fri, 15 Jul 2011 08:12:31 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p6FFBbml020330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 15 Jul 2011 10:11:38 -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 p6FFBaNY017297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 15 Jul 2011 10:11:37 -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 p6FFBZ7m000808 for ; Fri, 15 Jul 2011 08:11:35 -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, 15 Jul 2011 08:11:35 -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_01CC4301.7CB971E6" Date: Fri, 15 Jul 2011 08:11:32 -0700 Message-ID: <059AF07365DC474393A19A3AF187DF74075211C2@NAHALD.us.int.genesyslab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: what to put in the message header to indicate metadata snapshot request Thread-Index: AcxDAXs5+KzATc9uTXKC9cmn/NCNPQ== From: "Henry Lum" To: X-OriginalArrivalTime: 15 Jul 2011 15:11:35.0711 (UTC) FILETIME=[7CF12AF0:01CC4301] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: [siprec] what to put in the message header to indicate metadata snapshot request X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 15:12:34 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC4301.7CB971E6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 In the latest protocol draft revision (05) I proposed a mechanism to request for metadata snapshot request. This is outlined in section 5.5. I want to get some comments on whether the proposed mechanism is sufficient. =20 Thanks 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_01CC4301.7CB971E6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

In the latest protocol draft revision (05) I propose= d a mechanism to request for metadata snapshot request. This is outlined in s= ection 5.5. I want to get some comments on whether the proposed mechanism is suf= ficient.

 

Thanks

Henry

 


CONFIDENTIALITY NOTICE: This e-mai= l and any files attached may contain confidential and proprietary informa= tion of Alcatel-Lucent and/or its affiliated entities. Access by the inte= nded recipient only is authorized. Any liability arising from any party a= cting, or refraining from acting, on any information contained in this e-= mail is hereby excluded. If you are not the intended recipient, please no= tify the sender immediately, destroy the original transmission and its at= tachments and do not disclose the contents to any other person, use it fo= r 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 a= ffiliated entities. ------_=_NextPart_001_01CC4301.7CB971E6-- From Henry.Lum@alcatel-lucent.com Fri Jul 15 08:18:50 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B74321F8725 for ; Fri, 15 Jul 2011 08:18:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.127 X-Spam-Level: X-Spam-Status: No, score=-6.127 tagged_above=-999 required=5 tests=[AWL=-0.128, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, 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 11z2Pxsk8CVC for ; Fri, 15 Jul 2011 08:18:49 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 1605A21F8749 for ; Fri, 15 Jul 2011 08:18:48 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p6FFIkQX009608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 15 Jul 2011 10:18:47 -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 p6FFIj8I032641 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 15 Jul 2011 10:18:46 -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 p6FFIiBl010604; Fri, 15 Jul 2011 08:18:44 -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, 15 Jul 2011 08:18: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: Fri, 15 Jul 2011 08:18:42 -0700 Message-ID: <059AF07365DC474393A19A3AF187DF74075211CA@NAHALD.us.int.genesyslab.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: record-aware options tag Thread-Index: Acw6XRpvumjRleP6QM2icyxTy5+tFQAxb5igAfe08pA= References: <059AF07365DC474393A19A3AF187DF740747F9B8@NAHALD.us.int.genesyslab.com> From: "Henry Lum" To: "Elwell, John" , X-OriginalArrivalTime: 15 Jul 2011 15:18:44.0536 (UTC) FILETIME=[7C8AAB80:01CC4302] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: Re: [siprec] record-aware options tag X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 15:18:50 -0000 I added some text in the latest protocol draft (05) in section 6.2 about how to handle record awareness for automatons: "Some user agents that are automatons (eg. IVR, media server, PSTN gateway) may not have an user interface to render recording indication. When such user agent indicates recording awareness, these UA may render recording indication through other means, such as passing an inband tone on the PSTN gateway, putting the recording indication in a log file, or raising an application event in a VoiceXML dialog. These user agents may also choose not to indicate recording awareness, thereby relying on whatever mechansim an SRC chooses to indicate recording, such as playing a tone inband" There is also some normative text on the obligation of an SRC if no recording awareness has been indicated. "When a UA has not indicated that it is recording aware, an SRC must provide recording indications, where SRC is required to do so based on policies, through other means such as playing a tone inband." Would the above text be sufficient? Regards, Henry > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Tuesday, July 05, 2011 11:01 AM > To: Henry Lum; siprec@ietf.org > Subject: RE: record-aware options tag >=20 > My interpretation of what the meeting wanted was text along the > following lines. >=20 > "A UA that has indicated recording awareness by including the record- > aware option tag in a transmitted Supported header field MUST provide > at its user interface an indication whether recording is on or off for > a given medium based on the most recently received a=3Drecord SDP > attribute for that medium." >=20 > I am not sure whether this is sufficient or whether we need to say > more. For example, an automaton (such as a media server) would not have > a user interface. A UA that is a conference focus might need to pass it > on somehow to other participants. A UA that is a PSTN gateway would > need to play a tone or announcement. Of course, a UA can avoid such an > obligation by not sending this option tag in Supported, thereby relying > on the SRC to do the necessary (e.g., play a tone or announcement in > the case of audio). >=20 > In addition, we would need some normative statement for an SRC. Clearly > it would be obliged to take action if the UA has not indicated > recording awareness. >=20 > John (as individual) >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf Of Henry Lum > > Sent: 04 July 2011 16:15 > > To: siprec@ietf.org > > Subject: [siprec] record-aware options tag > > > > Following up on an issue from the interim meeting about the > > obligations for recording aware UA. I think it would be > > sufficient to require that a recording aware UA to indicate > > two things: 1) that it is recording-aware by adding the > > record-aware options tag in the Supported header; 2) provide > > recording indications with the a=3Drecord SDP attribute. Some > > types of UA such as PSTN gateways may have local policies to > > provide recording indications through other means such as > > inband tones/announcements, but they are in addition to the > > a=3Drecord SDP attribute. > > > > > > > > Would such text be sufficient? > > > > > > > > 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 pkyzivat@alum.mit.edu Fri Jul 15 08:41: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 40B9721F8784 for ; Fri, 15 Jul 2011 08:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYZy3-tN051E for ; Fri, 15 Jul 2011 08:41:13 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by ietfa.amsl.com (Postfix) with ESMTP id 53B5921F8514 for ; Fri, 15 Jul 2011 08:40:55 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta08.westchester.pa.mail.comcast.net with comcast id 8FgD1h0060xGWP858FgvAK; Fri, 15 Jul 2011 15:40:55 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta12.westchester.pa.mail.comcast.net with comcast id 8Fgt1h02D0tdiYw3YFgu77; Fri, 15 Jul 2011 15:40:55 +0000 Message-ID: <4E205F83.1080100@alum.mit.edu> Date: Fri, 15 Jul 2011 11:40:51 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: siprec@ietf.org References: <059AF07365DC474393A19A3AF187DF740747F9B8@NAHALD.us.int.genesyslab.com> <059AF07365DC474393A19A3AF187DF74075211CA@NAHALD.us.int.genesyslab.com> In-Reply-To: <059AF07365DC474393A19A3AF187DF74075211CA@NAHALD.us.int.genesyslab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] record-aware options tag X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 15:41:14 -0000 On 7/15/11 11:18 AM, Henry Lum wrote: > There is also some normative text on the obligation of an SRC if no > recording awareness has been indicated. > > "When a UA has not indicated that it is recording aware, an SRC must > provide recording indications, where SRC is required to do so based > on policies, through other means such as playing a tone inband." > > Would the above text be sufficient? This is tricky, because ultimately what is required is all based on local policy. AFAICT all this is saying is "An SRC must do what its local policy requires it to do". Perhaps this could be strengthened as follows: "When a UA has not indicated that it is recording aware, an SRC must provide recording indications via the media streams, unless local policy specifies some other means of indication." To a lawyer I don't think that is *any* stronger. But it *sounds* stronger. :-) Thanks, Paul From partr@cisco.com Sat Jul 16 04:46: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 EB49321F84F8 for ; Sat, 16 Jul 2011 04:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.751 X-Spam-Level: X-Spam-Status: No, score=-9.751 tagged_above=-999 required=5 tests=[AWL=-0.352, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, J_CHICKENPOX_74=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 BuNJb0CDJCCf for ; Sat, 16 Jul 2011 04:46: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 3DAFA21F84EF for ; Sat, 16 Jul 2011 04:46:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=21476; q=dns/txt; s=iport; t=1310816797; x=1312026397; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=Q189XJJVpfnUXdYImsA2FvatFF+2aG0KzQtQaCKG1I4=; b=FvvvLDm573MA8006Pt3/fj/q31H7aMrxWU2MWL9QbR3m/LowPGNkZGKm p65bDqpeiP9XNGLa5wQUHzqEuK0jXwrBVPFy388knJXPb0QHed4KXxOHI JKsbfoULffOx9JyS4Xt9IS94S01pzRtfSnzb3fD0+WrldoxPK1j2/ARhr A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At8AADJ5IU5Io8UR/2dsb2JhbABEAQ2YMY9Dd4h8ozWdb4MjAYI5XwSHUpAei1M0 X-IronPort-AV: E=Sophos;i="4.67,213,1309737600"; d="scan'208";a="102689680" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-1.cisco.com with ESMTP; 16 Jul 2011 11:46:34 +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 p6GBkYVi006847; Sat, 16 Jul 2011 11:46:34 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 16 Jul 2011 17:16:34 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Sat, 16 Jul 2011 17:16:32 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Review of metadata-03 Thread-Index: AcxCBGRNA+vWWzKOQdKee6BfMA3hewBkBI/g References: From: "Parthasarathi R (partr)" To: "Elwell, John" , X-OriginalArrivalTime: 16 Jul 2011 11:46:34.0069 (UTC) FILETIME=[03015050:01CC43AE] Subject: Re: [siprec] Review of metadata-03 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 16 Jul 2011 11:46:40 -0000 John, Thanks a lot for the detailed comments. I have replied for few of the comments which look straight forward to me. The authors of the draft will discuss and get back for the rest of the comments ASAP. Please read inline. Thanks Partha=20 > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > Sent: Thursday, July 14, 2011 2:30 PM > To: siprec@ietf.org > Subject: [siprec] Review of metadata-03 >=20 > I have reviewed metadata-03 up to and including section 6 and=20 > have the following comments (as individual): >=20 > 1. In general, we are much too liberal with normative=20 > language. I have highlighted in later comments some=20 > particular places where we use it inappropriately. In=20 > particular, we should not use it for things that are more a=20 > matter for the protocol document. Also, since this document=20 > is defining the metadata model and its XML representation, I=20 > think we can just use simple present tense, rather than=20 > normative statements, to state what the model or its XML=20 > representation is. This applies in many places, but I have=20 > avoided repeating my comments in all places. >=20 > 2. In general, we should avoid saying too much about the=20 > protocol or about conveyance of a metadata XML document, but=20 > should restrict ourselves, as far as possible, to the model=20 > and the XML document format. Again, specific comments touch on this. >=20 > 3. On terminology, I think it might be more helpful to=20 > restrict the term "element" to cases where we are talking=20 > about XML elements, and use some other term (e.g., object,=20 > class) when talking about components of the model. Then we=20 > could say, for example, that a 'stream' XML element=20 > represents a 'Media Stream' object or an object of class=20 > 'Media Stream'. >=20 > 4. Related to this, I think we should stick to a single=20 > convention, either: > - use the same name for the model object and for the=20 > corresponding XML element (we do this for "Participant", for=20 > example, at present); or > - use different names (we do this for "Media Stream" and=20 > "stream", for example, at present). >=20 > 5. Section 3: > "Metadata element: A metadata element represent one block/class of > metadata model." > This says what it represents, not what it is. Is it an XML=20 > element or what? Also, all definitions should be in the form=20 > of a dictionary definition, not a sentence. >=20 > 6. Terms "Metadata attributes" and "XML attributes are=20 > defined (section 3) but not used. >=20 > 7. "Metadata Composition" is defined (section 3) but used=20 > only in the title of 6.6.1, which could perhaps be changed to=20 > something that doesn't need defining. In fact a later comment=20 > questions the need for 6.6.1. >=20 > 8. Section 3: > "Metadata associations represents the > associations between different Metadata elements in the model. It > uses UML notation." > Defining Metadata Associations in terms of associations is=20 > not very helpful, and I can't find the term used anywhere. >=20 > 9. Section 4 and elsewhere: > I don't think Extension data should be shown as a separate=20 > block. Rather like start-time and stop-time, it is just a=20 > property of other blocks. In fact, I would go so far as to=20 > say that extension data should not be in the model - it is an=20 > XML technique that allows an extended model to be=20 > accommodated in future, but the model itself (being abstract)=20 > does not need such an extensibility mechanism. >=20 > 10. Section 4: > "The metadata MUST be conveyed within the Recording > Session Dialog." > I think this statement is outside scope of this document -=20 > more a protocol matter. This statement is as per our discussion on "recording" element in RS. "recording" metadata element will be represented using RS SIP messages. The statement is better presented in the metadata draft and in case the text has to be modified, Pls suggest. =20 >=20 > 11. Section 4: > "Note that the metadata model captures changes that occur over the > duration of the recording session." > I don't believe it captures changes. I think the model allows=20 > the capture of a snapshot of a recording's metadata at a=20 > given instant in time. Metadata changes to reflect changes in=20 > what is being recorded. >=20 > 12. Section 4: > "then the SRC MUST convey > a change of participant and the properties of the new=20 > media stream to > the SRS." > The "MUST convey" statement seems more like a protocol=20 > matter. All we can say is that the model changes and there is=20 > a need for the SRC to convey the change in the model to the SRS. Agreed >=20 > 13. Section 4: > "Some of the metadata is not required to be conveyed explicitly from > the SRC to the SRS, if it can be obtained contextually by the SRS. > For instance, the timing of RS block changes(like Start /=20 > Stop time) > may not be explicitly conveyed from the SRC to the SRS (The Date > header in RS dialog SIP message MAY provide the timing, but it is > optional). In such cases the time a change occurred may be assumed > to be the same as the time when notification of the change is > received by the SRS." > This is starting to talk about conveyance, rather than the=20 > model itself. I am not sure it belongs in this section. Also=20 > we shouldn't make normative statements ("MAY") on protocol=20 > issues. Furthermore, the statement about the time of change=20 > being the time the notification is received is not=20 > necessarily valid. For example, send notification with a=20 > change, this is lost, a little later the SRS asks for a=20 > snapshot, the snapshot is sent and the SRS observes the=20 > change - however, the time is wrong. >=20 > 14. Section 5: > "The > media related details of metadata MUST be passed across=20 > using session > description protocol (SDP) [RFC4566]. SDP attributes=20 > describes about > different media formats like audio, video." > We should not be making normative statements. We should=20 > express in terms like: "Some data from the metadata model is=20 > assumed to be made available to the SRS through SDP, and=20 > therefore this data is not represented in the XML document=20 > format specified in this document. >=20 > 15. Section 5: > "MUST be passed across" > I don't think a normative statement about passing across is=20 > appropriate to this document. I think it is sufficient here=20 > to say "are represented". >=20 > 16. Section 5: > "The linkage between application/rs-metadata+xml XML schema and > metadata SDP is done using the SDP label attribute (a=3Dlabel:xxx) > referenced in [RFC4574]." > I think this is trying to say something like: > "The SDP label attribute [RFC4574] provides an identifier by=20 > which a metadata XML document can refer to a specific media=20 > description in the SDP sent from the SRC to the SRS." >=20 > 17. Section 5: > "Metadata is passed across in Recording Session(RS) incrementally > whenever there is a change in CS." > I don't think we should be talking about passing across - we=20 > should limit ourselves to talking about the format. I think=20 > this should say something like: > "The XML document format can be used to represent either the=20 > complete metadata or a partial update to the metadata. The=20 > latter includes only elements that have changed compared to=20 > the previously reported metadata." >=20 > 18. Section 5.1: > "which will be embedded > as a message body" > Out of scope - delete. >=20 > 19. Section 5.1: > "Recording object is a XML document." > There seems to be confusion between this statement and the=20 > opening of the previous paragraph ("Recording Metadata=20 > document is an XML document"). Also it is unclear what=20 > "recording object" is. >=20 > 20. Section 5.1.2: > "dataMode element shows whether the XML document is complete document > or partial update. The default value is complete." > Any particular reason why this is an element rather than an=20 > attribute? I don't have a strong opinion either way - just=20 > curious, because it seems like the sort of thing that might=20 > typically be an attribute. >=20 In the metadata XML document, XML attribute is used only in case of unique value for an element. The rest of the data is represented as an element. > 21. Section 6.1: > "This element is represented by a SIP RS dialog and hence there is no > need for this element to be reflected in metadata XML" > Would it be more accurate or more helpful to say that the=20 > Recording Session object is represented by recording XML=20 > element?=20 Recording session metadata element is not represented in XML. As we discussed earlier, the value has to derived from RS dialog That in turn relies on the SIP/SDP session with=20 > which the XML document is associated to provide some of the=20 > attributes of the Recording Session element. Also I think,=20 > for consistency, this statement should be in a new=20 > sub-section 6.1.3, since it concerns representation, not modelling. Agreed for the last sentence >=20 > 22. Section 6.1.1: > "A Recording Session element MAY have attributes like:" I=20 > don't think RFC 2119 language is appropriate. We are defining=20 > the model - we are not giving permission for somebody to=20 > define the model. We should simply state (present tense) the=20 > attributes that apply. If any are optional, we could state=20 > that it is optional (rather than "MAY"), or we could say that=20 > it can have zero instances. Also, the word "like" leaves the=20 > list open ended, which is certainly unsatisfactory for a=20 > normative statement. But even if we change the language to=20 > informative, I think we need to be more precise. >=20 > 23. Section 6.1.1: > "Start and End time value MUST be derived from" > This is not a testable requirement - how do you test that=20 > something has been derived, unless there is a requirement to=20 > do more with the derived information? I think "are derivable"=20 > would suffice. Also, I think this would be more appropriate for 6.1.3. >=20 > 23. Section 6.1.1: > "Start/End time MAY be set to the time at > which SRS receives" > Again I don't think RFC2119 language is appropriate. This is=20 > not a protocol document. Could say "are derivable from...". =20 > Again it would be applicable to 6.1.3. >=20 > 23. Section 6.1.2: > "Also the allowance of > zero instances is to accommodate persistent recording,=20 > where there > may be none." > It seems this sentence is more applicable to the next bullet=20 > (concerning CS) than to the CSG bullet. >=20 > 24. Section 6.1.2: > "Each CS Group MUST be associated with one or more Recording > Sessions [Here each RS can be setup by the potentially different > SRCs." > This bullet doesn't fit below the introductory text (which is=20 > talking about what an RS must have). In fact this information=20 > is repeated in 6.2.2 , which seems a more appropriate place. >=20 > 25. Section 6.2: > "A Communication Session Group provides association or linking of > Communication Sessions." > I think we need to say a little more (informatively) about=20 > how grouping might be used. >=20 > 26. Section 6.2.1: > "SRC (or MAY be SRS) MUST > ensure the uniqueness of Unique-ID in case multiple SRC interacts > with the same SRS." > How do I interpret this normative language? I think we need=20 > to say that the SRC is responsible for assigning Unique-ID=20 > values that are unique. >=20 > 27. Section 6.2.2: > "o There can be one or more Recording Session elements per > Communication Session Group. > o Each Communication Session Group MUST be associated with one or > more RS [Here each RS can be setup by the potentially different > SRCs]" > What is the difference between these two bullets? >=20 > 28. Section 6.2.2: > "Each CS MAY be associated to zero or one CS-Group" > Would this fit better in 6.3.2? >=20 > 28. Section 6.2.3: > "Group element is an optional element" > Do we need to say "optional". We already know from 6.1.2 that=20 > an RS has zero or more associated CSGs - isn't that sufficient? This is more of elaborative text. Even though Sec 6.1.2 and XML schema helps to infer, it is better to have this text for readability =20 >=20 > 29. Section 6.2.3: > "Each group element has unique URN UUID attribute which > helps to uniquely identify CSG." > Why does it only help - why doesn't uniquely identify? >=20 This text will be updated according to the unique id usage e-mail thread in SIPREC > 30. Section 6.3.1: > "The communication session MAY contain a Call Termination Reason" > This conflicts with the "MUST" in the sentence introducing=20 > the bullets. >=20 Agreed. "MUST" has to be modified > 31. Section 6.3.1: > "Attributes like Retention (represent the value/duration for which > Media streams of the CS needs to be retained), Force=20 > Deletion, Access" > These look like named attributes, which they are not. Are we=20 > trying to say something like: > "This document does not specify attributes relating to what=20 > should happen to a recording of a CS after it has been=20 > delivered to the SRS, e.g., how long to retain the recording,=20 > what access controls to apply. The SRS is assumed to behave=20 > in accordance with policy. The ability for the SRC to=20 > influence this policy is outside the scope of this document."=20 > Also, should such a statement occur up front, e.g., in section 4? >=20 > 32. Section 6.3.1: > "However if there are > implementations where SRC has enough information, this=20 > could be sent > as Extension Data attached to CS" > Extension data is an XML concept, so should be covered in 6.3.3. >=20 > 33. Section 6.3.2: > "CS to have atleast two or more participants" > Are there any corner cases where there might be fewer than two? >=20 We don't know the usecase till now and concluded for two participant. In case you know of any usecase, Please let us know > 34. Section 6.3.2: > "o Participant MUST be associated with one or more CS's. This may > even includes participants who are not directly part of any CS. > An example of such a case is participants in a premixed media > stream. The SRC may have knowledge of such=20 > Participants, yet not > have any signaling relationship with them. This might arise if > one participant in CS is a conf focus. Another use=20 > case is if one > UA in CS works in 3pcc mode to acquire an MoH media stream, this > might be reflected as unique source for media stream without > having a reported signaling relationship to it. In all these > cases if SRC can learn enough information about the Participant, > they MUST be associated with CS." > All this is very confusing. I think what it is saying is that=20 > the SRC might not have direct signalling relationships with=20 > all participants in a CS, but should nevertheless create a=20 > Participant object for each participant that it knows about,=20 > e.g., participants visible as a result of the conference=20 > event package [RFC4575]. I failed to understand the bit about=20 > MoH, so that too would need rewording if retained. >=20 > 35. Section 6.3.2: > "o The model also allows participants in CS that are not participants > in the media. An example is the identity of a 3pcc controller > that has initiated a CS to two or more participants of the CS. > Another example is the identity of a conference focus. =20 > Of course > a focus is probably in the media, but since it may only be there > as a mixer, it may not report itself as a participant in any of > the media streams." > It is unclear why these cases would need to be Participants.=20 > However, I agree that where nothing is known about what is=20 > beyond a conference focus or B2BUA, the conference focus or=20 > B2BUA itself should probably be identified (if possible). >=20 > 36. Section 6.3.2: > "o A stream can be associated with 1 or more CS. An example is > multicast MoH stream which might be associated with many CSs." > I don't find this a convincing example. Does the SRC know for=20 > certain that the two streams are both the same MoH, and if so=20 > whether they are synchronized or not (if that matters)? >=20 > 37. Section 6.3.2 (same bullet): > "Also if we were to consider a B2BUA to have a separate CS on each > "side" then they might share a stream.(Though more likely this > would be treated as a single CS.)" > Again, this is a possibility, but why would a B2BUA want to=20 > do this - it seems to complicate the metadata unnecessarily? >=20 > 38. Section 6.3.3: > "Each communication session(CS) has one session element" > I would suggest changing "has" to "is represented by". >=20 Agreed > 39. Section 6.3.3: > "Reason element MAY be included to indicate the reason for > termination." > In order to tie it more clearly to the model, I would suggest=20 > changing "to indicate the reason for termination" to "to=20 > represent the Termination Reason attribute". >=20 Agreed > 40. Section 6.4.1: > "AoR list - Has list of AoRs." > Should we use a more generic name, rather than AOR? For=20 > example, "Identifier", since it need not necessarily be a SIP=20 > AOR, but could, for example, be a TEL URI, or even a JID if=20 > the CS is not a SIP session? >=20 > 41. Concerning the same bullet, in the schema, this has=20 > maxOccurs=3D1, so it doesn't seem to be a list, just a single=20 > AOR. I think a single identifier might be sufficient. >=20 > 42. Section 6.4.1: > "o Name - This attribute represents Participant name(SIP display > name) or DN number ( in case it is known)" > Assuming "DN number" means "directory number", or telephone=20 > number, why is this part of the name attribute, rather than=20 > the previous attribute? For example, I have available a tel:=20 > URI from P-Asserted-Identity - why would I treat that as name=20 > rather than identifier? >=20 > 43. Section 6.4.1: > "Other attributes [ like Participant Role, Participant type ] MAY be > carried as part of extension data to Participant from SRC to SRS." > Again this seems to be a statement about XML, so more=20 > relevant to 6.4.3 (if we need to say anything at all). >=20 > 44. Section 6.4.3: > "Participant element provides information regarding the specific > participant involved in the recording" > I think this should say something like: "A participant=20 > element represents a Participant object." >=20 > 45. Section 6.4.3: > ""receive" element" > I think this should be ""recv" element". Agreed >=20 > 46. Section 6.4.3: > "and by > default all participant will receive the stream" > I can't figure out how this works. If I omit a "recv" element=20 > for a particular Participant, it seems to mean that the=20 > Participant is receiving by default. So how do I indicate=20 > that a Participant is NOT receiving a stream? >=20 > 47. Section 6.4.3: > "URN UUID of participant > *MUST* used in the scope of CSG " > What does this mean? >=20 > 48. Section 6.4.3: > "and no new URN UUID has to be created > for the same element (participant, stream) between different CS in > the same CSG." > Concerning the mention of "stream", why are we talking about=20 > stream in the section on participant? >=20 > 49. Section 6.4.3: > "careful > usage of URN UUID to original AoR" > What does this mean? >=20 > 50. Section 6.5: > "Different instances of Media Stream block would be > created whenever there is a change in media (e.g. dir change like > pause/resume and/or codec change and/or participant change." > It is unclear to me why this would be so. None of the things=20 > mentioned here are attributes of Media Stream, so why would a=20 > new block be created if any of these change? >=20 > 51. Section 6.5.1: > The schema also has mode element, which presumably must have=20 > a corresponding attribute in the model, yet I don't see it in=20 > this section. >=20 > 52. Section 6.5.2: > "Label attribute is used ..." > I think we need to say that this corresponds to Media Stream=20 > Reference above. >=20 > 53. Section 6.5.2: > "The media mode helps " > Is this the "mode" element? >=20 > 54: "6.6.1. Composition" > Why do we need this section? We don't have a "composition"=20 > section for "start-time", for example, this being another=20 > example of an element type that can appear in different=20 > parent elements. >=20 >=20 > John > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec >=20 From Leon.Portman@nice.com Sun Jul 17 02:57: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 3D31921F872E for ; Sun, 17 Jul 2011 02:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 Qj4+kRDbqR7I for ; Sun, 17 Jul 2011 02:57:56 -0700 (PDT) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0A721F85F5 for ; Sun, 17 Jul 2011 02:57:52 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.15]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Sun, 17 Jul 2011 12:57:49 +0300 From: Leon Portman To: Paul Kyzivat , "siprec@ietf.org" Date: Sun, 17 Jul 2011 12:57:48 +0300 Thread-Topic: [siprec] record-aware options tag Thread-Index: AcxDBbs34Byk8oBaR/uCRRM9GrC9cABYh+Lg Message-ID: <07465C1D981ABC41A344374066AE1A2C38B00DD6D6@TLVMBX01.nice.com> References: <059AF07365DC474393A19A3AF187DF740747F9B8@NAHALD.us.int.genesyslab.com> <059AF07365DC474393A19A3AF187DF74075211CA@NAHALD.us.int.genesyslab.com> <4E205F83.1080100@alum.mit.edu> In-Reply-To: <4E205F83.1080100@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] record-aware options tag X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jul 2011 09:57:57 -0000 The question is if the revised statement does not open a loophole for local= policy "not to indicate at all". And we don't want that Leon -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Paul Kyzivat Sent: Friday, July 15, 2011 6:41 PM To: siprec@ietf.org Subject: Re: [siprec] record-aware options tag On 7/15/11 11:18 AM, Henry Lum wrote: > There is also some normative text on the obligation of an SRC if no=20 > recording awareness has been indicated. > > "When a UA has not indicated that it is recording aware, an SRC must > provide recording indications, where SRC is required to do so based > on policies, through other means such as playing a tone inband." > > Would the above text be sufficient? This is tricky, because ultimately what is required is all based on local p= olicy. AFAICT all this is saying is "An SRC must do what its local policy r= equires it to do". Perhaps this could be strengthened as follows: "When a UA has not indicated that it is recording aware, an SRC must provide recording indications via the media streams, unless local policy specifies some other means of indication." To a lawyer I don't think that is *any* stronger. But it *sounds* stronger.= :-) Thanks, Paul _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From pkyzivat@alum.mit.edu Sun Jul 17 10:05:32 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCD1521F8665 for ; Sun, 17 Jul 2011 10:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, 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 AzSwKQNAfSRa for ; Sun, 17 Jul 2011 10:05:31 -0700 (PDT) Received: from qmta10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by ietfa.amsl.com (Postfix) with ESMTP id DCF3F21F8591 for ; Sun, 17 Jul 2011 10:05:30 -0700 (PDT) Received: from omta11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by qmta10.emeryville.ca.mail.comcast.net with comcast id 94qV1h0050mlR8UAA55TcH; Sun, 17 Jul 2011 17:05:27 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta11.emeryville.ca.mail.comcast.net with comcast id 955U1h00a0tdiYw8X55V8C; Sun, 17 Jul 2011 17:05:30 +0000 Message-ID: <4E231656.4070504@alum.mit.edu> Date: Sun, 17 Jul 2011 13:05:26 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Leon Portman References: <059AF07365DC474393A19A3AF187DF740747F9B8@NAHALD.us.int.genesyslab.com> <059AF07365DC474393A19A3AF187DF74075211CA@NAHALD.us.int.genesyslab.com> <4E205F83.1080100@alum.mit.edu> <07465C1D981ABC41A344374066AE1A2C38B00DD6D6@TLVMBX01.nice.com> In-Reply-To: <07465C1D981ABC41A344374066AE1A2C38B00DD6D6@TLVMBX01.nice.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "siprec@ietf.org" Subject: Re: [siprec] record-aware options tag X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jul 2011 17:05:32 -0000 On 7/17/11 5:57 AM, Leon Portman wrote: > The question is if the revised statement does not open a loophole for local policy "not to indicate at all". And we don't want that I think the two statements both have that possibility to the same degree. Is there a way to leave it to policy and not have that possibility? And I think there are contexts in which the potential for recording is always known to be present and no further indication is required. For instance that is usually the situation with call center agent participants in call center calls. Perhaps we could add something about compliance with legal requirements. But I'm reluctant to go that way. Thanks, Paul > Leon > > > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Friday, July 15, 2011 6:41 PM > To: siprec@ietf.org > Subject: Re: [siprec] record-aware options tag > > On 7/15/11 11:18 AM, Henry Lum wrote: > >> There is also some normative text on the obligation of an SRC if no >> recording awareness has been indicated. >> >> "When a UA has not indicated that it is recording aware, an SRC must >> provide recording indications, where SRC is required to do so based >> on policies, through other means such as playing a tone inband." >> >> Would the above text be sufficient? > > This is tricky, because ultimately what is required is all based on local policy. AFAICT all this is saying is "An SRC must do what its local policy requires it to do". > > Perhaps this could be strengthened as follows: > > "When a UA has not indicated that it is recording aware, an SRC must > provide recording indications via the media streams, unless local > policy specifies some other means of indication." > > To a lawyer I don't think that is *any* stronger. But it *sounds* stronger. :-) > > Thanks, > Paul > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From john.elwell@siemens-enterprise.com Mon Jul 18 00:17: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 6CCDE21F8568 for ; Mon, 18 Jul 2011 00:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.476 X-Spam-Level: X-Spam-Status: No, score=-106.476 tagged_above=-999 required=5 tests=[AWL=0.123, 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 RJTxR7E45yEA for ; Mon, 18 Jul 2011 00:17:32 -0700 (PDT) Received: from mail182.messagelabs.com (mail182.messagelabs.com [85.158.139.83]) by ietfa.amsl.com (Postfix) with SMTP id 8DC2021F87BC for ; Mon, 18 Jul 2011 00:17:28 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-12.tower-182.messagelabs.com!1310973447!11439027!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 29033 invoked from network); 18 Jul 2011 07:17:27 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-12.tower-182.messagelabs.com with SMTP; 18 Jul 2011 07:17:27 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 08D2123F03E9; Mon, 18 Jul 2011 09:17:27 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Mon, 18 Jul 2011 09:17:26 +0200 From: "Elwell, John" To: "Parthasarathi R (partr)" , "siprec@ietf.org" Date: Mon, 18 Jul 2011 09:17:25 +0200 Thread-Topic: [siprec] Review of metadata-03 Thread-Index: AcxCBGRNA+vWWzKOQdKee6BfMA3hewBkBI/gAGBJQ4A= Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Review of metadata-03 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 07:17:34 -0000 (Stripping out the ones we have dealt with)=20 > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com]=20 > Sent: 16 July 2011 12:47 > To: Elwell, John; siprec@ietf.org > Subject: RE: [siprec] Review of metadata-03 >=20 > > 10. Section 4: > > "The metadata MUST be conveyed within the Recording > > Session Dialog." > > I think this statement is outside scope of this document -=20 > > more a protocol matter. > This statement is as per our discussion on=20 > "recording" element > in RS. "recording" metadata element will be represented using RS SIP > messages. The statement is better presented in the metadata=20 > draft and in > case the text has to be modified, Pls suggest. =20 [JRE] My concern was more with the use of RFC 2119 language - sorry for not= expressing it better. Just saying it MUST be conveyed within the RS dialog= is not really testable. I would expect the protocol draft to make normativ= e statements about exactly how to convey. Also I don't think we need to men= tion "dialog" - that too is a matter for the protocol document. Also the pr= evious sentence "The metadata MUST be conveyed from SRC to SRS" doesn't nee= d to use normative language. Instead of the two sentences, just say somethi= ng like "Metadata is conveyed from SRC to SRS as part of the RS". > > 20. Section 5.1.2: > > "dataMode element shows whether the XML document is=20 > complete document > > or partial update. The default value is complete." > > Any particular reason why this is an element rather than an=20 > > attribute? I don't have a strong opinion either way - just=20 > > curious, because it seems like the sort of thing that might=20 > > typically be an attribute. > >=20 > In the metadata XML document, XML attribute is used only in > case of unique value for an element. The rest of the data is=20 > represented > as an element. [JRE] I don't understand this explanation. Can anyone else shed light? >=20 > > 21. Section 6.1: > > "This element is represented by a SIP RS dialog and hence=20 > there is no > > need for this element to be reflected in metadata XML" > > Would it be more accurate or more helpful to say that the=20 > > Recording Session object is represented by recording XML=20 > > element?=20 > Recording session metadata element is not represented in XML. > As we discussed earlier, the value has to derived from RS dialog > [JRE] I was wondering how the recording XML element relates to the model. I= guess it is just a placeholder for those objects in the model that need to= be represented in XML. Perhaps we can say something to that effect in sect= ion 5. I withdraw my comment concerning 6.1. > > 28. Section 6.2.3: > > "Group element is an optional element" > > Do we need to say "optional". We already know from 6.1.2 that=20 > > an RS has zero or more associated CSGs - isn't that sufficient? >=20 > This is more of elaborative text. Even though Sec=20 > 6.1.2 and XML > schema helps to infer, it is better to have this text for readability > =20 [JRE] I still find it unhelpful to say "optional", given that all of the el= ements at this level are optional (minOccurs=3D0) - a partial XML document = can omit any of them, can't it? It is confusing to say one is optional when= , in effect, all are optional. Don't forget, this particular section (6.2.3= ) is concerned with XML representation, not the model. > > 33. Section 6.3.2: > > "CS to have atleast two or more participants" > > Are there any corner cases where there might be fewer than two? > >=20 > We don't know the usecase till now and concluded for two > participant. In case you know of any usecase, Please let us know > [JRE] I am not aware of a use case - I just feel slightly uncomfortable. Le= ave it for now. John (as individual) From john.elwell@siemens-enterprise.com Mon Jul 18 00:23: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 E88D221F8828 for ; Mon, 18 Jul 2011 00:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.479 X-Spam-Level: X-Spam-Status: No, score=-106.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 X4d3yc0q19QZ for ; Mon, 18 Jul 2011 00:22:59 -0700 (PDT) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfa.amsl.com (Postfix) with SMTP id D794D21F8588 for ; Mon, 18 Jul 2011 00:22:58 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1310973767!37325398!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 20276 invoked from network); 18 Jul 2011 07:22:47 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-9.tower-27.messagelabs.com with SMTP; 18 Jul 2011 07:22:47 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 276D91EB83ED; Mon, 18 Jul 2011 09:22:57 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Mon, 18 Jul 2011 09:22:56 +0200 From: "Elwell, John" To: Paul Kyzivat , "siprec@ietf.org" Date: Mon, 18 Jul 2011 09:22:55 +0200 Thread-Topic: [siprec] Handling of element deletions Thread-Index: AcxC9pmzgcWKsTroRsiT4Im2Io3YuwCJGWgg Message-ID: References: <35BCE99A477D6A4986FB2216D8CF2CFD07055655@XMB-BGL-417.cisco.com> <35BCE99A477D6A4986FB2216D8CF2CFD07055670@XMB-BGL-417.cisco.com> <4E20465A.4090104@alum.mit.edu> In-Reply-To: <4E20465A.4090104@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Handling of element deletions X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 07:23:00 -0000 =20 > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 15 July 2011 14:53 > To: siprec@ietf.org > Subject: Re: [siprec] Handling of element deletions >=20 > On 7/14/11 12:40 PM, Elwell, John wrote: >=20 > >> - If we have an MS element ( having a unique id), the > >> start/stop time of > >> the MS can be derived from the time of arrival of first=20 > participant, > >> time of departure of last participant. Assume here that the > >> MS is mixed > >> stream. > > [JRE] This concerns me. It seems to say that if both/all=20 > participants temporarily stop their involvement in a media=20 > stream (e.g., because of hold), that MS implicitly ceases and=20 > a new MS has to be created it they rejoin the stream? I had=20 > not appreciated that - is it what people really want? >=20 > Why is this concerning? > What would it mean to have an MS with no participants? >=20 > Note that hold doesn't necessarily mean participants leave the media=20 > stream. (Typically the receiver is still there as a participant, and=20 > there is *some* sender.) But if they all do leave it, what=20 > else makes sense? >=20 > Also note that there could still be an actual RS media stream=20 > in place,=20 > but not associated with any MS metadata. [JRE] It was not so much a concern, more a surprise. I can see it doesn't d= o any harm, although in the meantime Ram has acknowledged tht the same MS o= bject might be retained. John >=20 > Thanks, > Paul > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > = From john.elwell@siemens-enterprise.com Mon Jul 18 00:44: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 329F921F8B56 for ; Mon, 18 Jul 2011 00:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.482 X-Spam-Level: X-Spam-Status: No, score=-106.482 tagged_above=-999 required=5 tests=[AWL=0.117, 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 1YCIpqwzDVhm for ; Mon, 18 Jul 2011 00:44:42 -0700 (PDT) Received: from mail182.messagelabs.com (mail182.messagelabs.com [85.158.139.83]) by ietfa.amsl.com (Postfix) with SMTP id 4815F21F8B55 for ; Mon, 18 Jul 2011 00:44:42 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-14.tower-182.messagelabs.com!1310975081!11441658!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 9356 invoked from network); 18 Jul 2011 07:44:41 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-14.tower-182.messagelabs.com with SMTP; 18 Jul 2011 07:44:41 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 4E9F223F03EA; Mon, 18 Jul 2011 09:44:41 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 18 Jul 2011 09:44:38 +0200 From: "Elwell, John" To: Henry Lum , "siprec@ietf.org" Date: Mon, 18 Jul 2011 09:44:37 +0200 Thread-Topic: [siprec] what to put in the message header to indicate metadata snapshot request Thread-Index: AcxDAXs5+KzATc9uTXKC9cmn/NCNPQCHDk+Q Message-ID: References: <059AF07365DC474393A19A3AF187DF74075211C2@NAHALD.us.int.genesyslab.com> In-Reply-To: <059AF07365DC474393A19A3AF187DF74075211C2@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] what to put in the message header to indicate metadata snapshot request X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 07:44:43 -0000 Henry, At the last interim it was minuted: "Slide 8: Concerning the nature of a snapshot request, Charles thought this= could be just a simple request, with no parameters. The discussion seemed = to lean towards something in the header, rather than in the body. To be con= tinued on the list." I don't recall much discussion on the list, but the proposal in 05 for a bo= dy part seems to go against the meeting's general preference for something = in the header. I also don't recall anything in either the metadata draft or in the protoco= l draft to help the SRS determine whether it has lost a metadata update (an= d therefore needs to request a snapshot). Some sort of sequence numbering i= s perhaps required. John =20 > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Henry Lum > Sent: 15 July 2011 16:12 > To: siprec@ietf.org > Subject: [siprec] what to put in the message header to=20 > indicate metadata snapshot request >=20 > Hi, >=20 > =20 >=20 > In the latest protocol draft revision (05) I proposed a=20 > mechanism to request for metadata snapshot request. This is=20 > outlined in section 5.5. I want to get some comments on=20 > whether the proposed mechanism is sufficient. >=20 > =20 >=20 > Thanks >=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 Leon.Portman@nice.com Mon Jul 18 01:14: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 435BC21F8B64 for ; Mon, 18 Jul 2011 01:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.457 X-Spam-Level: X-Spam-Status: No, score=-2.457 tagged_above=-999 required=5 tests=[AWL=0.142, 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 74FMxNybutUM for ; Mon, 18 Jul 2011 01:14:21 -0700 (PDT) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id 4A45721F8B5F for ; Mon, 18 Jul 2011 01:14:21 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.15]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Mon, 18 Jul 2011 11:14:13 +0300 From: Leon Portman To: Paul Kyzivat Date: Mon, 18 Jul 2011 11:14:12 +0300 Thread-Topic: [siprec] record-aware options tag Thread-Index: AcxEo8Bz8ETd3ydMSWGa13mU/wa4ogAfo/Fg Message-ID: <07465C1D981ABC41A344374066AE1A2C38B00DDA69@TLVMBX01.nice.com> References: <059AF07365DC474393A19A3AF187DF740747F9B8@NAHALD.us.int.genesyslab.com> <059AF07365DC474393A19A3AF187DF74075211CA@NAHALD.us.int.genesyslab.com> <4E205F83.1080100@alum.mit.edu> <07465C1D981ABC41A344374066AE1A2C38B00DD6D6@TLVMBX01.nice.com> <4E231656.4070504@alum.mit.edu> In-Reply-To: <4E231656.4070504@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] record-aware options tag X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 08:14:22 -0000 I agree, there are multiple ways to indicate recording, like announcements = etc. This whole discussion is less relevant to protocols and standards and = more to policies, legalities and IETF RAVEN stuff. Leon -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20 Sent: Sunday, July 17, 2011 8:05 PM To: Leon Portman Cc: siprec@ietf.org Subject: Re: [siprec] record-aware options tag On 7/17/11 5:57 AM, Leon Portman wrote: > The question is if the revised statement does not open a loophole for=20 > local policy "not to indicate at all". And we don't want that I think the two statements both have that possibility to the same degree. I= s there a way to leave it to policy and not have that possibility? And I think there are contexts in which the potential for recording is alwa= ys known to be present and no further indication is required. For instance = that is usually the situation with call center agent participants in call c= enter calls. Perhaps we could add something about compliance with legal requirements.=20 But I'm reluctant to go that way. Thanks, Paul > Leon > > > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > Behalf Of Paul Kyzivat > Sent: Friday, July 15, 2011 6:41 PM > To: siprec@ietf.org > Subject: Re: [siprec] record-aware options tag > > On 7/15/11 11:18 AM, Henry Lum wrote: > >> There is also some normative text on the obligation of an SRC if no=20 >> recording awareness has been indicated. >> >> "When a UA has not indicated that it is recording aware, an SRC mus= t >> provide recording indications, where SRC is required to do so based >> on policies, through other means such as playing a tone inband." >> >> Would the above text be sufficient? > > This is tricky, because ultimately what is required is all based on local= policy. AFAICT all this is saying is "An SRC must do what its local policy= requires it to do". > > Perhaps this could be strengthened as follows: > > "When a UA has not indicated that it is recording aware, an SRC must > provide recording indications via the media streams, unless local > policy specifies some other means of indication." > > To a lawyer I don't think that is *any* stronger. But it *sounds*=20 > stronger. :-) > > Thanks, > Paul > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From partr@cisco.com Mon Jul 18 01:45: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 E0A9521F86D1 for ; Mon, 18 Jul 2011 01:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.332 X-Spam-Level: X-Spam-Status: No, score=-10.332 tagged_above=-999 required=5 tests=[AWL=0.267, 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 tndSTb6bUJzU for ; Mon, 18 Jul 2011 01:45:55 -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 B418F21F86C1 for ; Mon, 18 Jul 2011 01:45:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=5254; q=dns/txt; s=iport; t=1310978754; x=1312188354; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=G7nKv/EcNevrAAzogoqyv3ROODZHCU9ePbHENZXlBoo=; b=EVASnBUwApjRXcoB97JdNytmVqQQkCNnDJFRUqbIoOVD4+H69RhjKGGS rTzDBCCCozVGUm016I025tbV3BahOP/0QG8WTbSgr02UuwOEeODhziczB u/e8NNLM0rTug3j94H/1NypwazeJwz5p9d6IOkGQV3j9/Ulx1BsDMlAIW Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuEAADjyI05Io8UQ/2dsb2JhbABTmCyPQneIfKVMnUuFXV8Eh1KQHotT X-IronPort-AV: E=Sophos;i="4.67,221,1309737600"; d="scan'208";a="102850187" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-1.cisco.com with ESMTP; 18 Jul 2011 08:45:50 +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 p6I8joC9021174; Mon, 18 Jul 2011 08:45:50 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 18 Jul 2011 14:15: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: Mon, 18 Jul 2011 14:15:48 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Review of metadata-03 Thread-Index: AcxCBGRNA+vWWzKOQdKee6BfMA3hewBkBI/gAGBJQ4AAA0angA== References: From: "Parthasarathi R (partr)" To: "Elwell, John" , X-OriginalArrivalTime: 18 Jul 2011 08:45:49.0875 (UTC) FILETIME=[18302030:01CC4527] Subject: Re: [siprec] Review of metadata-03 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 08:45:59 -0000 John, Please read inline. Thanks Partha=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > Sent: Monday, July 18, 2011 12:47 PM > To: Parthasarathi R (partr); siprec@ietf.org > Subject: RE: [siprec] Review of metadata-03 >=20 > (Stripping out the ones we have dealt with)=20 >=20 > > -----Original Message----- > > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > > Sent: 16 July 2011 12:47 > > To: Elwell, John; siprec@ietf.org > > Subject: RE: [siprec] Review of metadata-03 > >=20 >=20 > > > 10. Section 4: > > > "The metadata MUST be conveyed within the Recording > > > Session Dialog." > > > I think this statement is outside scope of this document -=20 > > > more a protocol matter. > > This statement is as per our discussion on=20 > > "recording" element > > in RS. "recording" metadata element will be represented using RS SIP > > messages. The statement is better presented in the metadata=20 > > draft and in > > case the text has to be modified, Pls suggest. =20 > [JRE] My concern was more with the use of RFC 2119 language -=20 > sorry for not expressing it better. Just saying it MUST be=20 > conveyed within the RS dialog is not really testable. I would=20 > expect the protocol draft to make normative statements about=20 > exactly how to convey. Also I don't think we need to mention=20 > "dialog" - that too is a matter for the protocol document.=20 > Also the previous sentence "The metadata MUST be conveyed=20 > from SRC to SRS" doesn't need to use normative language.=20 > Instead of the two sentences, just say something like=20 > "Metadata is conveyed from SRC to SRS as part of the RS". Agreed. We will update in the next revision >=20 > > > 20. Section 5.1.2: > > > "dataMode element shows whether the XML document is=20 > > complete document > > > or partial update. The default value is complete." > > > Any particular reason why this is an element rather than an=20 > > > attribute? I don't have a strong opinion either way - just=20 > > > curious, because it seems like the sort of thing that might=20 > > > typically be an attribute. > > >=20 > > In the metadata XML document, XML attribute is used only in > > case of unique value for an element. The rest of the data is=20 > > represented > > as an element. > [JRE] I don't understand this explanation. Can anyone else shed light? >=20 Attribute of an XML element is used in this XML document only in case the value is constant and unique throughout for the element. In case the value shall be changed, then it is represented as sub-element within an element. This is as per recommendation provided by Joe. > >=20 > > > 21. Section 6.1: > > > "This element is represented by a SIP RS dialog and hence=20 > > there is no > > > need for this element to be reflected in metadata XML" > > > Would it be more accurate or more helpful to say that the=20 > > > Recording Session object is represented by recording XML=20 > > > element?=20 > > Recording session metadata element is not=20 > represented in XML. > > As we discussed earlier, the value has to derived from RS dialog > > > [JRE] I was wondering how the recording XML element relates=20 > to the model. I guess it is just a placeholder for those=20 > objects in the model that need to be represented in XML.=20 > Perhaps we can say something to that effect in section 5. I=20 > withdraw my comment concerning 6.1. >=20 Agreed. We will add text related to recording XML element in sec 5 for more clarity > > > 28. Section 6.2.3: > > > "Group element is an optional element" > > > Do we need to say "optional". We already know from 6.1.2 that=20 > > > an RS has zero or more associated CSGs - isn't that sufficient? > >=20 > > This is more of elaborative text. Even though Sec=20 > > 6.1.2 and XML > > schema helps to infer, it is better to have this text for=20 > readability > > =20 > [JRE] I still find it unhelpful to say "optional", given that=20 > all of the elements at this level are optional (minOccurs=3D0)=20 > - a partial XML document can omit any of them, can't it? It=20 > is confusing to say one is optional when, in effect, all are=20 > optional. Don't forget, this particular section (6.2.3) is=20 > concerned with XML representation, not the model. optional in the model perspective apart from the specific XML document (minOccurs=3D0). Let me think and come up with the appropriate text to clarify this >=20 > > > 33. Section 6.3.2: > > > "CS to have atleast two or more participants" > > > Are there any corner cases where there might be fewer than two? > > >=20 > > We don't know the usecase till now and concluded for two > > participant. In case you know of any usecase, Please let us know > > > [JRE] I am not aware of a use case - I just feel slightly=20 > uncomfortable. Leave it for now. >=20 Let us track this as an open item for IETF-81 and explore the possibility > John (as individual) >=20 >=20 From john.elwell@siemens-enterprise.com Mon Jul 18 03:21: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 2474B21F8B94 for ; Mon, 18 Jul 2011 03:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.51 X-Spam-Level: X-Spam-Status: No, score=-106.51 tagged_above=-999 required=5 tests=[AWL=0.089, 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 wcoQ9QrrQaLz for ; Mon, 18 Jul 2011 03:21:54 -0700 (PDT) Received: from mail174.messagelabs.com (mail174.messagelabs.com [85.158.138.51]) by ietfa.amsl.com (Postfix) with SMTP id 290D721F8B91 for ; Mon, 18 Jul 2011 03:21:53 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1310984512!25055238!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 15874 invoked from network); 18 Jul 2011 10:21:52 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-7.tower-174.messagelabs.com with SMTP; 18 Jul 2011 10:21:52 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 768CD23F03ED; Mon, 18 Jul 2011 12:21:52 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 18 Jul 2011 12:21:43 +0200 From: "Elwell, John" To: "Parthasarathi R (partr)" , "siprec@ietf.org" Date: Mon, 18 Jul 2011 12:21:42 +0200 Thread-Topic: [siprec] Review of metadata-03 Thread-Index: AcxCBGRNA+vWWzKOQdKee6BfMA3hewBkBI/gAGBJQ4AAA0angAAD9T3g Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Joe Hildebrand \(jhildebr\)" Subject: Re: [siprec] Review of metadata-03 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 10:21:55 -0000 Partha, Just following up on the dataMode element versus attribute discussion. Copy= ing Joe too. See below. > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com]=20 > Sent: 18 July 2011 09:46 > To: Elwell, John; siprec@ietf.org > Subject: RE: [siprec] Review of metadata-03 > > > > 20. Section 5.1.2: > > > > "dataMode element shows whether the XML document is=20 > > > complete document > > > > or partial update. The default value is complete." > > > > Any particular reason why this is an element rather than an=20 > > > > attribute? I don't have a strong opinion either way - just=20 > > > > curious, because it seems like the sort of thing that might=20 > > > > typically be an attribute. > > > >=20 > > > In the metadata XML document, XML attribute is=20 > used only in > > > case of unique value for an element. The rest of the data is=20 > > > represented > > > as an element. > > [JRE] I don't understand this explanation. Can anyone else=20 > shed light? > >=20 > Attribute of an XML element is used in this XML document only > in case the value is constant and unique throughout for the=20 > element. In > case the value shall be changed, then it is represented as sub-element > within an element. This is as per recommendation provided by Joe. > [JRE] So you are saying that value of the dataMode flag can vary over time?= This is true, of course. However, the recording element is a little bit di= fferent from the elements below it (session, stream, participant...). The r= ecording element is a sort of container for child elements, and I don't rea= lly think it has a lifetime beyond that of a single XML document. The dataM= ode flag, likewise, has a lifetime only for the single XML document in whic= h it is contained. It describes only whether that particular XML document i= s complete metadata or partial metadata. It is not an update of the dataMod= e flag in a previous XML document. So I don't think this particular criteri= on for making it an element, rather than an attribute, is valid. I am not e= xpert enough to know whether there might be other criteria that lead to use= of an element rather than an attribute. John (as individual)= From rmohanr@cisco.com Mon Jul 18 07:27: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 5F8FD21F8BE4 for ; Mon, 18 Jul 2011 07:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.344 X-Spam-Level: X-Spam-Status: No, score=-10.344 tagged_above=-999 required=5 tests=[AWL=0.254, 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 DZL-EGDE8QLQ for ; Mon, 18 Jul 2011 07:27:48 -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 0929021F8BBF for ; Mon, 18 Jul 2011 07:27:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=26263; q=dns/txt; s=iport; t=1310999267; x=1312208867; h=mime-version:subject:date:message-id:from:to; bh=urEle9Es6I1PLXTWiT5r7SWqxPvD8d+GsXMKDj0sOs8=; b=arqP6WisRF+oQf+1K642E+xgLKBlhYOWNz3ScX6HvCqlOFgLZscjTrYc ce2vHQEejJN/t9EzkeufnCm9c628HzEvJqZDU5lDFXSokF27oS9wFDkTu wvChAwY2vn/2JU6OV023bPte6+MiF5JIh9wWWeThYQCvw8g0A1heYS0jW E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EABZCJE5Io8UQ/2dsb2JhbABUglOlIXetMJ19hV1fBIdSkB6LUw X-IronPort-AV: E=Sophos;i="4.67,222,1309737600"; d="scan'208,217";a="43021719" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-2.cisco.com with ESMTP; 18 Jul 2011 14:27:36 +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 p6IERJei015628; Mon, 18 Jul 2011 14:27:35 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 18 Jul 2011 19:57:27 +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_01CC4556.D1817FFE" Date: Mon, 18 Jul 2011 19:57:26 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD07055D71@XMB-BGL-417.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-portman-siprec-protocol-05 Thread-Index: AcxFVtDX2/BM3obRTkKA9PPOnZTIuQ== From: "Ram Mohan R (rmohanr)" To: "Leon Portman" , X-OriginalArrivalTime: 18 Jul 2011 14:27:27.0624 (UTC) FILETIME=[D1CC6880:01CC4556] Subject: [siprec] Comments on draft-portman-siprec-protocol-05 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 14:27:51 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC4556.D1817FFE Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Leon et all, =20 Over all the draft is coming up good. Here are some of my comments.. =20 1)Section 1 says "The Session Recording Protocol uses SIP as the protocol for session establishment with special attention to reducing size of the required SIP messages. " I am not clear on what is the context of this statement w.r.t SIPREC solution and how it helps in reducing size of messages. Can you please clarify ? =20 2)Section 1 says "In addition, it is designed for future extendibility and protocol version management to ensure backward compatibility" Again can you please clarify how this is done ? =20 3)I would suggest to have only new definitions on Section 2. In case you still want to retain them please make them consistent. I see some mismatch in the definitions of Section 2 to the ones in Requirement draft.=20 =20 4)In Figure 2, the RS may be setup upon receiving INVITE from UA A. It need not wait always until A and B are connected. IMO this is a policy decision. You may want to add a note saying the same. The diagram gives an impression that it may be the only way RS may be setup. =20 5)Section 4.3 has this text about delivering metadata "In some cases session metadata can be conveyed through non-SIP mechanism such as HTTP or JTAPI. These non-SIP mechanisms are considered out of the scope of the Session Recording Protocol, however, it is envisoned that a link with a URI can be provided in the recording session INVITE message so that the SRS can access the session metadata via the URI provided that the SRS supports the type of URI." IMO since the current metadata XML schema is not extensible outside SIP it is better to not mention this text. =20 6)Section 5.2 "To remove a recorded media stream from the recording session, send a reINVITE and set the port to zero in the m=3D line. =20 To add a recorded media stream, send a reINVITE and add a new m=3D line." You may want to add a text here that this is applicable only if SRC is recording each stream independently. I have a question here. In case the stream sent from SRC to SRS happens to be a mixed stream (IOW we have only one m-line), addition /deletion of participants can be known by looking at metadata xml schema and looking for all participants who a . Apart from this do we need anything else in metadata or in protocol ? =20 7)Section 5.4 "As mentioned in the previous section, the SDP of the recording session is the metadata for all recorded media streams." =20 You may want to re-word this sentence to make it more clearer. Something like this: As mentioned in the previous section, the SDP of the recording session describes the properties of media for all recorded media streams. =20 =20 8) Section 5.4 For all basic metadata information such as communication session, participants, call identifiers and direction, they can be included in the initial INVITE request sent by the SRC.=20 Note that we are not sending direction attribute in basic metadata. It was agreed earlier that direction value is not possible to be determined at all times and hence we may send it as extension data. what is call identifier here ? =20 =20 9) Sectoin 5.5 IMO this needs some more discussion before acceptance. As John mentioned in another thread, we have not had much discussion on this either before.=20 =20 10) Section 6.1 Apart from what is mentioned in last para of this section, I think we can explicitly add a note that this attribute is NOT intended tell an SRC to start/stop recording. =20 11) Section 6.3 Any reason why we explicitly need to indicate "nopreference". Cant the absence of this SDP attribute itself says that a UA has no preference. =20 =20 Regards, Ram =20 =20 =20 =20 ------_=_NextPart_001_01CC4556.D1817FFE Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

L= eon et all,

<= o:p> 

O= ver all the draft is coming up good. Here are some of my = comments..

<= o:p> 

1= )Section 1 says “The Session Recording Protocol uses SIP as the = protocol for session establishment with special attention to reducing = size of the required SIP messages. “

I= am not clear on what is the context of this statement w.r.t SIPREC = solution and how it helps in reducing size of messages.  Can you = please clarify ?

<= o:p> 

2= )Section 1 says “In addition, it is designed for future = extendibility and protocol version management to ensure backward = compatibility”

A= gain can you please clarify how this is done ?

<= o:p> 

3= )I would suggest to have only new definitions on Section 2. In case you = still want to retain them please make them consistent.  I see some = mismatch in the definitions of Section 2 to the ones in Requirement = draft.

<= o:p> 

4= )In Figure 2, the RS may be setup upon receiving INVITE from UA A. It = need not wait always until A and B are connected. IMO this is a policy = decision. You may want to add a note saying the same. The diagram gives = an impression that it may be the only way RS may be = setup.

<= o:p> 

5= )Section 4.3 has this text about delivering = metadata

&= lt;snip>

&= #8220;In some cases session metadata can be conveyed through = non-SIP

&= nbsp;  mechanism such as HTTP or JTAPI.  These non-SIP = mechanisms are

&= nbsp;  considered out of the scope of the Session Recording = Protocol,

&= nbsp;  however, it is envisoned that a link with a URI can be = provided in

&= nbsp;  the recording session INVITE message so that the SRS can = access the

&= nbsp;  session metadata via the URI provided that the SRS supports = the type

&= nbsp;  of URI.”

&= lt;/snip>

I= MO since the current metadata XML schema is not extensible outside SIP = it is better to not mention this text.

<= o:p> 

6= )Section 5.2

&= lt;snip>

&= #8220;To remove a recorded media stream from the recording session, send = a

&= nbsp;  reINVITE and set the port to zero in the m=3D = line.

<= o:p> 

&= nbsp;  To add a recorded media stream, send a reINVITE and add a = new m=3D

&= nbsp;  line.“

&= lt;/snip>

Y= ou may want to add a text here that this is applicable only if SRC is = recording each stream independently.

I= have a question here. In case the stream sent from SRC to SRS happens = to be a mixed stream (IOW we have only one m-line), addition /deletion = of participants can be known by looking at metadata xml schema and = looking for all participants who <sends> a <stream>. Apart = from this do we need anything else in metadata or in protocol = ?

<= o:p> 

7= )Section 5.4

&= lt;snip>

&= #8220;As mentioned in the previous section, the SDP of the = recording

&= nbsp;  session is the metadata for all recorded media = streams.”

&= lt;/snip>

<= o:p> 

Y= ou may want to re-word this sentence to make it more clearer. Something = like this:

A= s mentioned in the previous section, the SDP of the recording  = session describes the properties of media for all recorded media = streams.

<= o:p> 

<= o:p> 

8= ) Section 5.4

&= lt;snip>

F= or all basic metadata information such as communication = session,

&= nbsp;  participants, call identifiers and direction, they can be = included in

&= nbsp;  the initial INVITE request sent by the SRC. =

&= lt;/snip>

N= ote that we are not sending direction attribute in  basic metadata. = It was agreed earlier that direction value is not possible to be = determined at all times and hence we may send it as extension = data.

w= hat is call identifier here ?

<= o:p> 

<= o:p> 

9= ) Sectoin 5.5

I= MO this needs some more discussion before acceptance. As John mentioned = in another thread, we have not had much discussion on this either = before.

<= o:p> 

1= 0) Section 6.1

A= part from what is mentioned in last para of this section, I think we can = explicitly add a note that this attribute is NOT intended tell an SRC to = start/stop recording.

<= o:p> 

1= 1) Section 6.3

A= ny reason why we explicitly need to indicate = “nopreference”.  Cant the absence of this SDP attribute = itself says that a UA has no preference.

<= o:p> 

<= o:p> 

R= egards,

R= am

<= o:p> 

<= o:p> 

 

 

------_=_NextPart_001_01CC4556.D1817FFE-- From andrew.hutton@siemens-enterprise.com Mon Jul 18 08:17: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 DD87921F8BB7 for ; Mon, 18 Jul 2011 08:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cLPWPdreZZzP for ; Mon, 18 Jul 2011 08:17:51 -0700 (PDT) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfa.amsl.com (Postfix) with SMTP id 86DE621F8C33 for ; Mon, 18 Jul 2011 08:17:50 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: andrew.hutton@siemens-enterprise.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1311002259!37395901!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 21613 invoked from network); 18 Jul 2011 15:17:39 -0000 Received: from senmx12-mx.siemens-enterprise.com (HELO senmx12-mx) (62.134.46.10) by server-9.tower-27.messagelabs.com with SMTP; 18 Jul 2011 15:17:39 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 43EEB23F03E2; Mon, 18 Jul 2011 17:17:49 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 18 Jul 2011 17:17:49 +0200 From: "Hutton, Andrew" To: Leon Portman , Henry Lum , "'alan.b.johnston@gmail.com'" Date: Mon, 18 Jul 2011 17:17:46 +0200 Thread-Topic: Some comments on draft-portman-siprec-protocol-05 Thread-Index: AcxFXdkXN8YzUTtCTWGqrQp3xx/MvA== Message-ID: <101C6067BEC68246B0C3F6843BCCC1E30D755D8290@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 Cc: "siprec@ietf.org" Subject: [siprec] Some comments on draft-portman-siprec-protocol-05 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 15:17:52 -0000 Hi, I have a few comments on draft-portman-siprec-protocol-05.=20 1. The introduction talks about "special attention to reducing size of the = required SIP messages" but I don't think we really do this so the statement= should be removed.=20 2. Definitions - Should also include the definition for "Recording Aware UA= ". 3. The scope should be expanded to include the CS for indications sent to a= recording aware UA. 4. In section 5.1.2 (srs Feature Tag) the last paragraph mentions this use = of this tag in an Accept-Contact and Require headers. Similar text should a= lso be included in section 5.1.1 (src Feature Tag) which could be used in t= he same way to route the request to an SRC. 5. Section 6 "SIP Extensions for Recording-aware UA's" is actually all abou= t SDP and therefore should be renamed to "SDP Extensions ...". 6. Section 6.1 "Providing recording indication". The 1st paragraph talks ab= out an indication that the CS is being recorded however the indication is a= t the media level in SDP and not at the CS level so we need to change the t= ext to reflect this. 7. I am not sure how we deal with the SDP extensions in terms of getting th= em reviewed by MMUSIC but would I think be a good idea to change the struct= ure a little to separate the SDP and SIP extensions so that if need be we c= ould split in to separate drafts. Regards Andy From andrew.hutton@siemens-enterprise.com Mon Jul 18 08: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 C85DE21F86FF for ; Mon, 18 Jul 2011 08:46:46 -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 aoFyGdtCN4aL for ; Mon, 18 Jul 2011 08:46:46 -0700 (PDT) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfa.amsl.com (Postfix) with SMTP id AF10421F8696 for ; Mon, 18 Jul 2011 08:46:45 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: andrew.hutton@siemens-enterprise.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1311003990!32758458!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 21812 invoked from network); 18 Jul 2011 15:46:30 -0000 Received: from senmx11-mx.siemens-enterprise.com (HELO senmx11-mx.siemens-enterprise.com) (62.134.46.9) by server-3.tower-27.messagelabs.com with SMTP; 18 Jul 2011 15:46:30 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 964811EB83E3; Mon, 18 Jul 2011 17:46:44 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Mon, 18 Jul 2011 17:46:44 +0200 From: "Hutton, Andrew" To: "Ram Mohan R (rmohanr)" , Leon Portman , "siprec@ietf.org" Date: Mon, 18 Jul 2011 17:46:42 +0200 Thread-Topic: Comments on draft-portman-siprec-protocol-05 Thread-Index: AcxFVtDX2/BM3obRTkKA9PPOnZTIuQAB/ouA Message-ID: <101C6067BEC68246B0C3F6843BCCC1E30D755D82CA@MCHP058A.global-ad.net> References: <35BCE99A477D6A4986FB2216D8CF2CFD07055D71@XMB-BGL-417.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD07055D71@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Comments on draft-portman-siprec-protocol-05 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 15:46:46 -0000 Hi Ram, Sorry I did not see your response before sending my own comments. See some responses below. Reading your comments made me think a more thorough review is needed which = I will attempt to do. Regards Andy > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Ram Mohan R (rmohanr) > Sent: 18 July 2011 15:27 > To: Leon Portman; siprec@ietf.org > Subject: [siprec] Comments on draft-portman-siprec-protocol-05 >=20 > Leon et all, >=20 > Over all the draft is coming up good. Here are some of my comments.. >=20 > 1)Section 1 says "The Session Recording Protocol uses SIP as the > protocol for session establishment with special attention to reducing > size of the required SIP messages. " > I am not clear on what is the context of this statement w.r.t SIPREC > solution and how it helps in reducing size of messages. =A0Can you please > clarify ? >=20 I had the same comment I think this statement should be removed. > 2)Section 1 says "In addition, it is designed for future extendibility > and protocol version management to ensure backward compatibility" > Again can you please clarify how this is done ? >=20 I don't think this is relevant to this document probably more applicable to= the metadata. > 3)I would suggest to have only new definitions on Section 2. In case > you still want to retain them please make them consistent.=A0 I see some > mismatch in the definitions of Section 2 to the ones in Requirement > draft. >=20 Personally I think the architecture draft should be the master regarding de= finitions as this defines the architecture and therefore the entities invol= ved. > 4)In Figure 2, the RS may be setup upon receiving INVITE from UA A. It > need not wait always until A and B are connected. IMO this is a policy > decision. You may want to add a note saying the same. The diagram gives > an impression that it may be the only way RS may be setup. >=20 > 5)Section 4.3 has this text about delivering metadata > > "In some cases session metadata can be conveyed through non-SIP > =A0=A0 mechanism such as HTTP or JTAPI.=A0 These non-SIP mechanisms are > =A0=A0 considered out of the scope of the Session Recording Protocol, > =A0=A0 however, it is envisoned that a link with a URI can be provided in > =A0=A0 the recording session INVITE message so that the SRS can access th= e > =A0=A0 session metadata via the URI provided that the SRS supports the ty= pe > =A0=A0 of URI." > > IMO since the current metadata XML schema is not extensible outside SIP > it is better to not mention this text. >=20 I agree. > 6)Section 5.2 > > "To remove a recorded media stream from the recording session, send a > =A0=A0 reINVITE and set the port to zero in the m=3D line. >=20 > =A0=A0 To add a recorded media stream, send a reINVITE and add a new m=3D > =A0=A0 line." > > You may want to add a text here that this is applicable only if SRC is > recording each stream independently. > I have a question here. In case the stream sent from SRC to SRS happens > to be a mixed stream (IOW we have only one m-line), addition /deletion > of participants can be known by looking at metadata xml schema and > looking for all participants who a . Apart from this do > we need anything else in metadata or in protocol ? >=20 > 7)Section 5.4 > > "As mentioned in the previous section, the SDP of the recording > =A0=A0 session is the metadata for all recorded media streams." > >=20 > You may want to re-word this sentence to make it more clearer. > Something like this: > As mentioned in the previous section, the SDP of the recording=A0 session > describes the properties of media for all recorded media streams. >=20 I agree the text does not seem to make much sense to me your suggestion is = better. >=20 > 8) Section 5.4 > > For all basic metadata information such as communication session, > =A0=A0 participants, call identifiers and direction, they can be included > in > =A0=A0 the initial INVITE request sent by the SRC. > > Note that we are not sending direction attribute in =A0basic metadata. It > was agreed earlier that direction value is not possible to be > determined at all times and hence we may send it as extension data. > what is call identifier here ? >=20 >=20 > 9) Sectoin 5.5 > IMO this needs some more discussion before acceptance. As John > mentioned in another thread, we have not had much discussion on this > either before. >=20 > 10) Section 6.1 > Apart from what is mentioned in last para of this section, I think we > can explicitly add a note that this attribute is NOT intended tell an > SRC to start/stop recording. >=20 > 11) Section 6.3 > Any reason why we explicitly need to indicate "nopreference".=A0 Cant the > absence of this SDP attribute itself says that a UA has no preference. >=20 > Regards, > Ram >=20 >=20 >=20 From eckelcu@cisco.com Mon Jul 18 10:13: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 D0F2D21F85F2 for ; Mon, 18 Jul 2011 10:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.281 X-Spam-Level: X-Spam-Status: No, score=-4.281 tagged_above=-999 required=5 tests=[AWL=-1.682, 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 t6PyXeRP9Ixg for ; Mon, 18 Jul 2011 10:13:25 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id C539C21F8585 for ; Mon, 18 Jul 2011 10:13:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=5984; q=dns/txt; s=iport; t=1311009204; x=1312218804; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=7/HJdRXnpOh4PMJNlXA80OQvfJLq6aNDf0FB/MMiue0=; b=h6Hgq7y4BWsinrsBCMQIeTHggLaXAnEZJb3ne/Yrch4U2yBMBaLrOJik uOcB5B2wqC9fuYTwCFdc1nfQ+aWXqozmH9t7zrfLDAXDCjA3SFquwerfP 4YWISRC/UH+Y4ER40WLrVHXpd1QEXJqKX/K3QxbFnpx02/dQkU9rY3FIz 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuQAABRpJE6rRDoG/2dsb2JhbABUmDiPQXeIfKQ0nhKFXV8EhyUvkByLaw X-IronPort-AV: E=Sophos;i="4.67,223,1309737600"; d="scan'208";a="4028958" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-6.cisco.com with ESMTP; 18 Jul 2011 17:13:24 +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 p6IHDNOC029221; Mon, 18 Jul 2011 17:13:23 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, 18 Jul 2011 10:13: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Jul 2011 10:13:22 -0700 Message-ID: In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E30D755D82CA@MCHP058A.global-ad.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Comments on draft-portman-siprec-protocol-05 Thread-Index: AcxFVtDX2/BM3obRTkKA9PPOnZTIuQAB/ouAAAOHuBA= References: <35BCE99A477D6A4986FB2216D8CF2CFD07055D71@XMB-BGL-417.cisco.com> <101C6067BEC68246B0C3F6843BCCC1E30D755D82CA@MCHP058A.global-ad.net> From: "Charles Eckel (eckelcu)" To: "Hutton, Andrew" , "Ram Mohan R (rmohanr)" , "Leon Portman" , X-OriginalArrivalTime: 18 Jul 2011 17:13:23.0691 (UTC) FILETIME=[0013ABB0:01CC456E] Subject: Re: [siprec] Comments on draft-portman-siprec-protocol-05 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 17:13:25 -0000 Please see inline. > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On = Behalf Of Hutton, Andrew > Sent: Monday, July 18, 2011 8:47 AM > To: Ram Mohan R (rmohanr); Leon Portman; siprec@ietf.org > Subject: Re: [siprec] Comments on draft-portman-siprec-protocol-05 >=20 > Hi Ram, >=20 > Sorry I did not see your response before sending my own comments. >=20 > See some responses below. >=20 > Reading your comments made me think a more thorough review is needed = which I will attempt to do. >=20 > Regards > Andy >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Ram Mohan R (rmohanr) > > Sent: 18 July 2011 15:27 > > To: Leon Portman; siprec@ietf.org > > Subject: [siprec] Comments on draft-portman-siprec-protocol-05 > > > > Leon et all, > > > > Over all the draft is coming up good. Here are some of my comments.. > > > > 1)Section 1 says "The Session Recording Protocol uses SIP as the > > protocol for session establishment with special attention to = reducing > > size of the required SIP messages. " > > I am not clear on what is the context of this statement w.r.t SIPREC > > solution and how it helps in reducing size of messages. =A0Can you = please > > clarify ? > > >=20 > I had the same comment I think this statement should be removed. >=20 >=20 > > 2)Section 1 says "In addition, it is designed for future = extendibility > > and protocol version management to ensure backward compatibility" > > Again can you please clarify how this is done ? > > >=20 > I don't think this is relevant to this document probably more = applicable to the metadata. >=20 >=20 > > 3)I would suggest to have only new definitions on Section 2. In case > > you still want to retain them please make them consistent.=A0 I see = some > > mismatch in the definitions of Section 2 to the ones in Requirement > > draft. > > >=20 > Personally I think the architecture draft should be the master = regarding definitions as this defines > the architecture and therefore the entities involved. I prefer this approach as well. Note, this is the approach taken by = draft-eckel-siprec-rtp-rec as well. Cheers, Charles >=20 > > 4)In Figure 2, the RS may be setup upon receiving INVITE from UA A. = It > > need not wait always until A and B are connected. IMO this is a = policy > > decision. You may want to add a note saying the same. The diagram = gives > > an impression that it may be the only way RS may be setup. > > > > 5)Section 4.3 has this text about delivering metadata > > > > "In some cases session metadata can be conveyed through non-SIP > > =A0=A0 mechanism such as HTTP or JTAPI.=A0 These non-SIP mechanisms = are > > =A0=A0 considered out of the scope of the Session Recording = Protocol, > > =A0=A0 however, it is envisoned that a link with a URI can be = provided in > > =A0=A0 the recording session INVITE message so that the SRS can = access the > > =A0=A0 session metadata via the URI provided that the SRS supports = the type > > =A0=A0 of URI." > > > > IMO since the current metadata XML schema is not extensible outside = SIP > > it is better to not mention this text. > > >=20 > I agree. >=20 >=20 > > 6)Section 5.2 > > > > "To remove a recorded media stream from the recording session, send = a > > =A0=A0 reINVITE and set the port to zero in the m=3D line. > > > > =A0=A0 To add a recorded media stream, send a reINVITE and add a new = m=3D > > =A0=A0 line." > > > > You may want to add a text here that this is applicable only if SRC = is > > recording each stream independently. > > I have a question here. In case the stream sent from SRC to SRS = happens > > to be a mixed stream (IOW we have only one m-line), addition = /deletion > > of participants can be known by looking at metadata xml schema and > > looking for all participants who a . Apart from this = do > > we need anything else in metadata or in protocol ? > > > > 7)Section 5.4 > > > > "As mentioned in the previous section, the SDP of the recording > > =A0=A0 session is the metadata for all recorded media streams." > > > > > > You may want to re-word this sentence to make it more clearer. > > Something like this: > > As mentioned in the previous section, the SDP of the recording=A0 = session > > describes the properties of media for all recorded media streams. > > >=20 > I agree the text does not seem to make much sense to me your = suggestion is better. >=20 > > > > 8) Section 5.4 > > > > For all basic metadata information such as communication session, > > =A0=A0 participants, call identifiers and direction, they can be = included > > in > > =A0=A0 the initial INVITE request sent by the SRC. > > > > Note that we are not sending direction attribute in =A0basic = metadata. It > > was agreed earlier that direction value is not possible to be > > determined at all times and hence we may send it as extension data. > > what is call identifier here ? > > > > > > 9) Sectoin 5.5 > > IMO this needs some more discussion before acceptance. As John > > mentioned in another thread, we have not had much discussion on this > > either before. > > > > 10) Section 6.1 > > Apart from what is mentioned in last para of this section, I think = we > > can explicitly add a note that this attribute is NOT intended tell = an > > SRC to start/stop recording. > > > > 11) Section 6.3 > > Any reason why we explicitly need to indicate "nopreference".=A0 = Cant the > > absence of this SDP attribute itself says that a UA has no = preference. > > >=20 > > Regards, > > Ram > > > > > > >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From Ranjit.Avasarala@Polycom.com Mon Jul 18 11:06: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 90E0421F84EB for ; Mon, 18 Jul 2011 11:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJrDGm6nd2uI for ; Mon, 18 Jul 2011 11:06:40 -0700 (PDT) Received: from Hkgehubprd01.polycom.com (hkgehubprd01.polycom.com [140.242.6.225]) by ietfa.amsl.com (Postfix) with ESMTP id 94A4A21F84EE for ; Mon, 18 Jul 2011 11:06:38 -0700 (PDT) Received: from Hkgmboxprd01.polycom.com ([fe80::7d4e:b35f:33e1:6ae3]) by Hkgehubprd01.polycom.com ([fe80::5efe:172.21.6.201%12]) with mapi; Tue, 19 Jul 2011 02:06:36 +0800 From: "Avasarala, Ranjit" To: Leon Portman , Paul Kyzivat Date: Tue, 19 Jul 2011 02:06:33 +0800 Thread-Topic: [siprec] record-aware options tag Thread-Index: AcxEo8Bz8ETd3ydMSWGa13mU/wa4ogAfo/FgABS3rpA= Message-ID: <9F9278CB1892FB48BF35CB5CC3992478A536CB2B27@HKGMBOXPRD01.polycom.com> References: <059AF07365DC474393A19A3AF187DF740747F9B8@NAHALD.us.int.genesyslab.com> <059AF07365DC474393A19A3AF187DF74075211CA@NAHALD.us.int.genesyslab.com> <4E205F83.1080100@alum.mit.edu> <07465C1D981ABC41A344374066AE1A2C38B00DD6D6@TLVMBX01.nice.com> <4E231656.4070504@alum.mit.edu> <07465C1D981ABC41A344374066AE1A2C38B00DDA69@TLVMBX01.nice.com> In-Reply-To: <07465C1D981ABC41A344374066AE1A2C38B00DDA69@TLVMBX01.nice.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] record-aware options tag X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 18:06:40 -0000 Hi all Are there any suggestions for option-tags to use for indicating that the se= ssion is to be recorded? E.g. record.=20 E.g. "Require: record" could be used to indicate that a particular session= should be recorded. Thanks Regards Ranjit -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Leon Portman Sent: Monday, July 18, 2011 1:44 PM To: Paul Kyzivat Cc: siprec@ietf.org Subject: Re: [siprec] record-aware options tag I agree, there are multiple ways to indicate recording, like announcements = etc. This whole discussion is less relevant to protocols and standards and = more to policies, legalities and IETF RAVEN stuff. Leon -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20 Sent: Sunday, July 17, 2011 8:05 PM To: Leon Portman Cc: siprec@ietf.org Subject: Re: [siprec] record-aware options tag On 7/17/11 5:57 AM, Leon Portman wrote: > The question is if the revised statement does not open a loophole for=20 > local policy "not to indicate at all". And we don't want that I think the two statements both have that possibility to the same degree. I= s there a way to leave it to policy and not have that possibility? And I think there are contexts in which the potential for recording is alwa= ys known to be present and no further indication is required. For instance = that is usually the situation with call center agent participants in call c= enter calls. Perhaps we could add something about compliance with legal requirements.=20 But I'm reluctant to go that way. Thanks, Paul > Leon > > > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > Behalf Of Paul Kyzivat > Sent: Friday, July 15, 2011 6:41 PM > To: siprec@ietf.org > Subject: Re: [siprec] record-aware options tag > > On 7/15/11 11:18 AM, Henry Lum wrote: > >> There is also some normative text on the obligation of an SRC if no=20 >> recording awareness has been indicated. >> >> "When a UA has not indicated that it is recording aware, an SRC mus= t >> provide recording indications, where SRC is required to do so based >> on policies, through other means such as playing a tone inband." >> >> Would the above text be sufficient? > > This is tricky, because ultimately what is required is all based on local= policy. AFAICT all this is saying is "An SRC must do what its local policy= requires it to do". > > Perhaps this could be strengthened as follows: > > "When a UA has not indicated that it is recording aware, an SRC must > provide recording indications via the media streams, unless local > policy specifies some other means of indication." > > To a lawyer I don't think that is *any* stronger. But it *sounds*=20 > stronger. :-) > > Thanks, > Paul > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From pkyzivat@alum.mit.edu Mon Jul 18 13:30: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 98E4321F8AF9 for ; Mon, 18 Jul 2011 13:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.291 X-Spam-Level: X-Spam-Status: No, score=-2.291 tagged_above=-999 required=5 tests=[AWL=-0.292, BAYES_00=-2.599, J_CHICKENPOX_73=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 LnwF7FKnghjs for ; Mon, 18 Jul 2011 13:30:30 -0700 (PDT) Received: from qmta04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by ietfa.amsl.com (Postfix) with ESMTP id 18A9621F89CC for ; Mon, 18 Jul 2011 13:30:30 -0700 (PDT) Received: from omta17.emeryville.ca.mail.comcast.net ([76.96.30.73]) by qmta04.emeryville.ca.mail.comcast.net with comcast id 9Xo81h0061afHeLA4YWRFZ; Mon, 18 Jul 2011 20:30:25 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta17.emeryville.ca.mail.comcast.net with comcast id 9YXP1h0240tdiYw8dYXQyn; Mon, 18 Jul 2011 20:31:26 +0000 Message-ID: <4E2497DF.1040308@alum.mit.edu> Date: Mon, 18 Jul 2011 16:30:23 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "Avasarala, Ranjit" References: <059AF07365DC474393A19A3AF187DF740747F9B8@NAHALD.us.int.genesyslab.com> <059AF07365DC474393A19A3AF187DF74075211CA@NAHALD.us.int.genesyslab.com> <4E205F83.1080100@alum.mit.edu> <07465C1D981ABC41A344374066AE1A2C38B00DD6D6@TLVMBX01.nice.com> <4E231656.4070504@alum.mit.edu> <07465C1D981ABC41A344374066AE1A2C38B00DDA69@TLVMBX01.nice.com> <9F9278CB1892FB48BF35CB5CC3992478A536CB2B27@HKGMBOXPRD01.polycom.com> In-Reply-To: <9F9278CB1892FB48BF35CB5CC3992478A536CB2B27@HKGMBOXPRD01.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "siprec@ietf.org" Subject: Re: [siprec] record-aware options tag X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 20:30:30 -0000 On 7/18/11 2:06 PM, Avasarala, Ranjit wrote: > Hi all > Are there any suggestions for option-tags to use for indicating that the session is to be recorded? E.g. record. > E.g. "Require: record" could be used to indicate that a particular session should be recorded. That is a whole different thing! Option tags aren't really suitable for that, for a number of reasons: - Require:foo is to fail unless the UAS *supports* foo, but has no implication that foo be used. So in this case it could ensure that the UAS was *capable* of recording, but not that it *is* recording. - This doesn't say anything about *what* is recorded, where it is recorded, how one might access the recording, etc. ISTM that requesting a recording is a complex process, something on the order of configuring a conference focus. Among other things, just ensuring that there in an SRC on the path to the callee may not be trivial. If we want to do that then I think it is a separate deliverable. Thanks, Paul > Thanks > > Regards > Ranjit > > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Leon Portman > Sent: Monday, July 18, 2011 1:44 PM > To: Paul Kyzivat > Cc: siprec@ietf.org > Subject: Re: [siprec] record-aware options tag > > I agree, there are multiple ways to indicate recording, like announcements etc. This whole discussion is less relevant to protocols and standards and more to policies, legalities and IETF RAVEN stuff. > > Leon > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Sunday, July 17, 2011 8:05 PM > To: Leon Portman > Cc: siprec@ietf.org > Subject: Re: [siprec] record-aware options tag > > On 7/17/11 5:57 AM, Leon Portman wrote: >> The question is if the revised statement does not open a loophole for >> local policy "not to indicate at all". And we don't want that > > I think the two statements both have that possibility to the same degree. Is there a way to leave it to policy and not have that possibility? > > And I think there are contexts in which the potential for recording is always known to be present and no further indication is required. For instance that is usually the situation with call center agent participants in call center calls. > > Perhaps we could add something about compliance with legal requirements. > But I'm reluctant to go that way. > > Thanks, > Paul > >> Leon >> >> >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Paul Kyzivat >> Sent: Friday, July 15, 2011 6:41 PM >> To: siprec@ietf.org >> Subject: Re: [siprec] record-aware options tag >> >> On 7/15/11 11:18 AM, Henry Lum wrote: >> >>> There is also some normative text on the obligation of an SRC if no >>> recording awareness has been indicated. >>> >>> "When a UA has not indicated that it is recording aware, an SRC must >>> provide recording indications, where SRC is required to do so based >>> on policies, through other means such as playing a tone inband." >>> >>> Would the above text be sufficient? >> >> This is tricky, because ultimately what is required is all based on local policy. AFAICT all this is saying is "An SRC must do what its local policy requires it to do". >> >> Perhaps this could be strengthened as follows: >> >> "When a UA has not indicated that it is recording aware, an SRC must >> provide recording indications via the media streams, unless local >> policy specifies some other means of indication." >> >> To a lawyer I don't think that is *any* stronger. But it *sounds* >> stronger. :-) >> >> 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 Mon Jul 18 15:41: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 8098721F867E for ; Mon, 18 Jul 2011 15:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.141 X-Spam-Level: X-Spam-Status: No, score=-4.141 tagged_above=-999 required=5 tests=[AWL=-1.542, 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 YYdgmwMYAOqi for ; Mon, 18 Jul 2011 15:41:56 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id B6B8221F8620 for ; Mon, 18 Jul 2011 15:41:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=4220; q=dns/txt; s=iport; t=1311028916; x=1312238516; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=tH8i7df2hfBJZbxvsVjJMPmiblhQ6saKPLdGyrwSQCg=; b=Fj24Y0MPJvd9LJZWswEBqYzfSXhjFi+IQHavZwRp1C7VO4c8I9vklJj6 TxDFV9xTu83RVLT357HYm0Fq8A8USYdkkfv8M3T44Hye0YbpbFMIotSBR DXWNYexeGRAB08u0ftvyjvtqRWzliU1yxjNBsx4d7tdNInPBGB6YyTlVB U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuAAAFy2JE6rRDoJ/2dsb2JhbABTmAaPRHeuUp43hV1fBIdUkByLbA X-IronPort-AV: E=Sophos;i="4.67,224,1309737600"; d="scan'208";a="4131845" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-2.cisco.com with ESMTP; 18 Jul 2011 22:41:56 +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 p6IMfsfr000894; Mon, 18 Jul 2011 22:41:54 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, 18 Jul 2011 15:41:54 -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, 18 Jul 2011 15:41:53 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] what to put in the message header to indicatemetadata snapshot request Thread-Index: AcxDAXs5+KzATc9uTXKC9cmn/NCNPQCHDk+QAB5Cb4A= References: <059AF07365DC474393A19A3AF187DF74075211C2@NAHALD.us.int.genesyslab.com> From: "Charles Eckel (eckelcu)" To: "Elwell, John" , "Henry Lum" , X-OriginalArrivalTime: 18 Jul 2011 22:41:54.0513 (UTC) FILETIME=[E4A46C10:01CC459B] Subject: Re: [siprec] what to put in the message header to indicatemetadata snapshot request X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 22:41:57 -0000 I was initially thinking of this from the perspective of wanting to avoid requiring metadata processing on the behalf of the SRS or SRC in order to request a snapshot. In this case, a SIP header is appealing. Another option, and the one implied by section 5.5 of the draft, is to enable generic metadata error handling. If you want to do this, requesting a snapshot could be a type of error reported by the SRS, and sending a snapshot could be a recovery mechanism used by the SRC. More complex error reporting and recovery would probably involve some sort of metadata sequence number and an indication of the last sequence number processed properly on the SRS. This would enable the SRC to send updates based on an intermediate point in the recording. I am thinking the former mechanism is sufficient. The latter mechanism, though definitely much more efficient in many cases, is more complex. The cynic/realist in me thinks that with either method, the odds are high that once an error is encountered any recovery mechanism (e.g. a snapshot, an intermediate update, etc.) has a high probability of failing. The important thing is to be able to debug the failure. For example, it may be that the update resulted in a parsing error on the RS within some participant element. I see some value in having this in some SIP or metadata message, but having it enable auto-recovery is not likely. As I do not see any error handling within the current metadata model/format, I am thinking it is best to leave the snapshot request outside of the context of the metadata. Cheers, Charles =20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Elwell, John > Sent: Monday, July 18, 2011 12:45 AM > To: Henry Lum; siprec@ietf.org > Subject: Re: [siprec] what to put in the message header to indicatemetadata snapshot request >=20 > Henry, >=20 > At the last interim it was minuted: > "Slide 8: Concerning the nature of a snapshot request, Charles thought this could be just a simple > request, with no parameters. The discussion seemed to lean towards something in the header, rather > than in the body. To be continued on the list." > I don't recall much discussion on the list, but the proposal in 05 for a body part seems to go against > the meeting's general preference for something in the header. >=20 > I also don't recall anything in either the metadata draft or in the protocol draft to help the SRS > determine whether it has lost a metadata update (and therefore needs to request a snapshot). Some sort > of sequence numbering is perhaps required. >=20 > John >=20 >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf Of Henry Lum > > Sent: 15 July 2011 16:12 > > To: siprec@ietf.org > > Subject: [siprec] what to put in the message header to > > indicate metadata snapshot request > > > > Hi, > > > > > > > > In the latest protocol draft revision (05) I proposed a > > mechanism to request for metadata snapshot request. This is > > outlined in section 5.5. I want to get some comments on > > whether the proposed mechanism is sufficient. > > > > > > > > Thanks > > > > 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. > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From eckelcu@cisco.com Mon Jul 18 16:19: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 9661721F899D for ; Mon, 18 Jul 2011 16:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.022 X-Spam-Level: X-Spam-Status: No, score=-4.022 tagged_above=-999 required=5 tests=[AWL=-1.423, 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 duTbHy3y0BLk for ; Mon, 18 Jul 2011 16:19:12 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id AE0BA21F88DC for ; Mon, 18 Jul 2011 16:19:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=457; q=dns/txt; s=iport; t=1311031151; x=1312240751; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=CWvVkFfCL0Hs+7S3pZUhqXV8F7ljbnUr3VPa/zwjzxM=; b=NhIqVpfyKCFhv0v8p4+9q0V+/n4u36UefU7RoSRLg2f6pUCdS6KCDgwU u7hh7c9jWCy8Gm66XMR+Ix+b1PZS7Lr/IvIXtUs7ATlp6l8HMGm4f5QAc ueyKM9JXtEeNM7RaoJpwZFs56BgTZjK/vlGnh5hU6jgwqzYwKBL0r0PVi A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An8HADm/JE6rRDoI/2dsb2JhbABTmEmPAXetGoEjnjmFXV8Eh1SQHIts X-IronPort-AV: E=Sophos;i="4.67,225,1309737600"; d="scan'208";a="4142105" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-9.cisco.com with ESMTP; 18 Jul 2011 23:19:11 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6INJA8q003768 for ; Mon, 18 Jul 2011 23:19:10 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, 18 Jul 2011 16:19: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="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Jul 2011 16:19:04 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: cancel or restart/redo a recording Thread-Index: AcxFoRYSR6RXJJIDTUyS0vPdoEdm6g== From: "Charles Eckel (eckelcu)" To: X-OriginalArrivalTime: 18 Jul 2011 23:19:05.0549 (UTC) FILETIME=[16717FD0:01CC45A1] Subject: [siprec] cancel or restart/redo a recording X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 23:19:12 -0000 Something common with existing recording solutions is allowing the user to cancel or restart/redo a recording (i.e. while leaving a voice messages, cancel the existing message and start recording a new one). I do not see anything in the SIPREC requirements or protocol drafts to support this. This could be considered a special case of playback and therefore lie outside the scope of SIPREC. Does anyone see this as a problem? Thanks, Charles=20 From rmohanr@cisco.com Tue Jul 19 00:04: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 F208221F865D for ; Tue, 19 Jul 2011 00:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.355 X-Spam-Level: X-Spam-Status: No, score=-10.355 tagged_above=-999 required=5 tests=[AWL=0.244, 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 cCBtdY3HG2jN for ; Tue, 19 Jul 2011 00:04:28 -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 4F9B721F865B for ; Tue, 19 Jul 2011 00:04:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=6171; q=dns/txt; s=iport; t=1311059067; x=1312268667; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=7ETBrelO/sGYu+L9pg8DcqrGYdMAeE37TA2xrFsW54M=; b=MREIhRYXNl0AuERmJjVBEDqt1t63JvZLin/YEW1gGB2EHFE8uSuCqd/H 1cDZ2AvR0ohk9+kEcQEaQ3HoO7hXrYAJihIE6YwURqf1wFSccMYjS2nsD kOGhBaNvL+y1jdOeI0M14FKzcx2VNHv+H4vchZS6g9KoZbEvqoB2aH/NZ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuEAABgrJU5Io8US/2dsb2JhbABTmAWPQ3eIfKVynkyFXV8EhyUtkCGLVA X-IronPort-AV: E=Sophos;i="4.67,227,1309737600"; d="scan'208";a="43276021" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-2.cisco.com with ESMTP; 19 Jul 2011 07:03:53 +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 p6J73qjg023326; Tue, 19 Jul 2011 07:03:52 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 19 Jul 2011 12:33:52 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 19 Jul 2011 12:33:48 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD071634E8@XMB-BGL-417.cisco.com> In-reply-to: <101C6067BEC68246B0C3F6843BCCC1E30D755D82CA@MCHP058A.global-ad.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-portman-siprec-protocol-05 Thread-Index: AcxFVtDX2/BM3obRTkKA9PPOnZTIuQAB/ouAABkkA5A= References: <35BCE99A477D6A4986FB2216D8CF2CFD07055D71@XMB-BGL-417.cisco.com> <101C6067BEC68246B0C3F6843BCCC1E30D755D82CA@MCHP058A.global-ad.net> From: "Ram Mohan R (rmohanr)" To: "Hutton, Andrew" , "Leon Portman" , X-OriginalArrivalTime: 19 Jul 2011 07:03:52.0629 (UTC) FILETIME=[04703650:01CC45E2] Subject: Re: [siprec] Comments on draft-portman-siprec-protocol-05 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 07:04:32 -0000 Hi Andy, Thanks for your responses. A comment on the below response. > > 2)Section 1 says "In addition, it is designed for future > extendibility > > and protocol version management to ensure backward compatibility" > > Again can you please clarify how this is done ? > > >=20 > I don't think this is relevant to this document probably more > applicable to the metadata. Are you suggesting to have something in metadata for version management = ? Why do we need it ? Regards, Ram > -----Original Message----- > From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com] > Sent: Monday, July 18, 2011 9:17 PM > To: Ram Mohan R (rmohanr); Leon Portman; siprec@ietf.org > Subject: RE: Comments on draft-portman-siprec-protocol-05 >=20 > Hi Ram, >=20 > Sorry I did not see your response before sending my own comments. >=20 > See some responses below. >=20 > Reading your comments made me think a more thorough review is needed > which I will attempt to do. >=20 > Regards > Andy >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Ram Mohan R (rmohanr) > > Sent: 18 July 2011 15:27 > > To: Leon Portman; siprec@ietf.org > > Subject: [siprec] Comments on draft-portman-siprec-protocol-05 > > > > Leon et all, > > > > Over all the draft is coming up good. Here are some of my comments.. > > > > 1)Section 1 says "The Session Recording Protocol uses SIP as the > > protocol for session establishment with special attention to = reducing > > size of the required SIP messages. " > > I am not clear on what is the context of this statement w.r.t SIPREC > > solution and how it helps in reducing size of messages. =A0Can you > please > > clarify ? > > >=20 > I had the same comment I think this statement should be removed. >=20 >=20 > > 2)Section 1 says "In addition, it is designed for future > extendibility > > and protocol version management to ensure backward compatibility" > > Again can you please clarify how this is done ? > > >=20 > I don't think this is relevant to this document probably more > applicable to the metadata. >=20 >=20 > > 3)I would suggest to have only new definitions on Section 2. In case > > you still want to retain them please make them consistent.=A0 I see > some > > mismatch in the definitions of Section 2 to the ones in Requirement > > draft. > > >=20 > Personally I think the architecture draft should be the master > regarding definitions as this defines the architecture and therefore > the entities involved. >=20 >=20 > > 4)In Figure 2, the RS may be setup upon receiving INVITE from UA A. > It > > need not wait always until A and B are connected. IMO this is a > policy > > decision. You may want to add a note saying the same. The diagram > gives > > an impression that it may be the only way RS may be setup. > > > > 5)Section 4.3 has this text about delivering metadata > > > > "In some cases session metadata can be conveyed through non-SIP > > =A0=A0 mechanism such as HTTP or JTAPI.=A0 These non-SIP mechanisms = are > > =A0=A0 considered out of the scope of the Session Recording = Protocol, > > =A0=A0 however, it is envisoned that a link with a URI can be = provided in > > =A0=A0 the recording session INVITE message so that the SRS can = access > the > > =A0=A0 session metadata via the URI provided that the SRS supports = the > type > > =A0=A0 of URI." > > > > IMO since the current metadata XML schema is not extensible outside > SIP > > it is better to not mention this text. > > >=20 > I agree. >=20 >=20 > > 6)Section 5.2 > > > > "To remove a recorded media stream from the recording session, send = a > > =A0=A0 reINVITE and set the port to zero in the m=3D line. > > > > =A0=A0 To add a recorded media stream, send a reINVITE and add a new = m=3D > > =A0=A0 line." > > > > You may want to add a text here that this is applicable only if SRC > is > > recording each stream independently. > > I have a question here. In case the stream sent from SRC to SRS > happens > > to be a mixed stream (IOW we have only one m-line), addition > /deletion > > of participants can be known by looking at metadata xml schema and > > looking for all participants who a . Apart from this > do > > we need anything else in metadata or in protocol ? > > > > 7)Section 5.4 > > > > "As mentioned in the previous section, the SDP of the recording > > =A0=A0 session is the metadata for all recorded media streams." > > > > > > You may want to re-word this sentence to make it more clearer. > > Something like this: > > As mentioned in the previous section, the SDP of the recording > session > > describes the properties of media for all recorded media streams. > > >=20 > I agree the text does not seem to make much sense to me your = suggestion > is better. >=20 > > > > 8) Section 5.4 > > > > For all basic metadata information such as communication session, > > =A0=A0 participants, call identifiers and direction, they can be = included > > in > > =A0=A0 the initial INVITE request sent by the SRC. > > > > Note that we are not sending direction attribute in =A0basic = metadata. > It > > was agreed earlier that direction value is not possible to be > > determined at all times and hence we may send it as extension data. > > what is call identifier here ? > > > > > > 9) Sectoin 5.5 > > IMO this needs some more discussion before acceptance. As John > > mentioned in another thread, we have not had much discussion on this > > either before. > > > > 10) Section 6.1 > > Apart from what is mentioned in last para of this section, I think = we > > can explicitly add a note that this attribute is NOT intended tell = an > > SRC to start/stop recording. > > > > 11) Section 6.3 > > Any reason why we explicitly need to indicate "nopreference".=A0 = Cant > the > > absence of this SDP attribute itself says that a UA has no > preference. > > >=20 > > Regards, > > Ram > > > > > > From john.elwell@siemens-enterprise.com Tue Jul 19 01:49: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 6082121F88DC for ; Tue, 19 Jul 2011 01:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.512 X-Spam-Level: X-Spam-Status: No, score=-104.512 tagged_above=-999 required=5 tests=[AWL=-1.913, 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 P2IZ3Ltc-5wC for ; Tue, 19 Jul 2011 01:49:30 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 829E921F88D9 for ; Tue, 19 Jul 2011 01:49:30 -0700 (PDT) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 5998E23F0417; Tue, 19 Jul 2011 10:49:29 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 19 Jul 2011 10:49:14 +0200 From: "Elwell, John" To: "Avasarala, Ranjit" , Leon Portman , Paul Kyzivat Date: Tue, 19 Jul 2011 10:49:12 +0200 Thread-Topic: [siprec] record-aware options tag Thread-Index: AcxEo8Bz8ETd3ydMSWGa13mU/wa4ogAfo/FgABS3rpAAHsD2EA== Message-ID: References: <059AF07365DC474393A19A3AF187DF740747F9B8@NAHALD.us.int.genesyslab.com> <059AF07365DC474393A19A3AF187DF74075211CA@NAHALD.us.int.genesyslab.com> <4E205F83.1080100@alum.mit.edu> <07465C1D981ABC41A344374066AE1A2C38B00DD6D6@TLVMBX01.nice.com> <4E231656.4070504@alum.mit.edu> <07465C1D981ABC41A344374066AE1A2C38B00DDA69@TLVMBX01.nice.com> <9F9278CB1892FB48BF35CB5CC3992478A536CB2B27@HKGMBOXPRD01.polycom.com> In-Reply-To: <9F9278CB1892FB48BF35CB5CC3992478A536CB2B27@HKGMBOXPRD01.polycom.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] record-aware options tag X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 08:49:31 -0000 Ranjit, Past discussions seem to have led to the following consensus: - We will not specify a means for a UA in a CS to "require" that the CS be = recorded. - We will specify means for a UA in a CS to express a preference whether or= not to record, but this will not be binding on any SRC. - This preference will be expressed on a per medium level, and therefore in= SDP (as currently proposed in the draft). It would be good to avoid opening up this issue again unless you have new t= echnical arguments. Thanks, John (as chair) > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Avasarala, Ranjit > Sent: 18 July 2011 19:07 > To: Leon Portman; Paul Kyzivat > Cc: siprec@ietf.org > Subject: Re: [siprec] record-aware options tag >=20 > Hi all > Are there any suggestions for option-tags to use for=20 > indicating that the session is to be recorded? E.g. record.=20 > E.g. "Require: record" could be used to indicate that a=20 > particular session should be recorded. >=20 > Thanks >=20 > Regards > Ranjit >=20 > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Leon Portman > Sent: Monday, July 18, 2011 1:44 PM > To: Paul Kyzivat > Cc: siprec@ietf.org > Subject: Re: [siprec] record-aware options tag >=20 > I agree, there are multiple ways to indicate recording, like=20 > announcements etc. This whole discussion is less relevant to=20 > protocols and standards and more to policies, legalities and=20 > IETF RAVEN stuff. >=20 > Leon >=20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20 > Sent: Sunday, July 17, 2011 8:05 PM > To: Leon Portman > Cc: siprec@ietf.org > Subject: Re: [siprec] record-aware options tag >=20 > On 7/17/11 5:57 AM, Leon Portman wrote: > > The question is if the revised statement does not open a=20 > loophole for=20 > > local policy "not to indicate at all". And we don't want that >=20 > I think the two statements both have that possibility to the=20 > same degree. Is there a way to leave it to policy and not=20 > have that possibility? >=20 > And I think there are contexts in which the potential for=20 > recording is always known to be present and no further=20 > indication is required. For instance that is usually the=20 > situation with call center agent participants in call center calls. >=20 > Perhaps we could add something about compliance with legal=20 > requirements.=20 > But I'm reluctant to go that way. >=20 > Thanks, > Paul >=20 > > Leon > > > > > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > > Behalf Of Paul Kyzivat > > Sent: Friday, July 15, 2011 6:41 PM > > To: siprec@ietf.org > > Subject: Re: [siprec] record-aware options tag > > > > On 7/15/11 11:18 AM, Henry Lum wrote: > > > >> There is also some normative text on the obligation of an=20 > SRC if no=20 > >> recording awareness has been indicated. > >> > >> "When a UA has not indicated that it is recording=20 > aware, an SRC must > >> provide recording indications, where SRC is required=20 > to do so based > >> on policies, through other means such as playing a=20 > tone inband." > >> > >> Would the above text be sufficient? > > > > This is tricky, because ultimately what is required is all=20 > based on local policy. AFAICT all this is saying is "An SRC=20 > must do what its local policy requires it to do". > > > > Perhaps this could be strengthened as follows: > > > > "When a UA has not indicated that it is recording=20 > aware, an SRC must > > provide recording indications via the media streams,=20 > unless local > > policy specifies some other means of indication." > > > > To a lawyer I don't think that is *any* stronger. But it *sounds*=20 > > stronger. :-) > > > > Thanks, > > Paul > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > > >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > = From john.elwell@siemens-enterprise.com Tue Jul 19 02:03: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 0591821F84F8 for ; Tue, 19 Jul 2011 02:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.47 X-Spam-Level: X-Spam-Status: No, score=-104.47 tagged_above=-999 required=5 tests=[AWL=-1.871, 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 PlXRgc7wCmgK for ; Tue, 19 Jul 2011 02:03:03 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 27E0D21F84DA for ; Tue, 19 Jul 2011 02:03:03 -0700 (PDT) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 8A94C23F0450; Tue, 19 Jul 2011 11:03:02 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 19 Jul 2011 11:02:54 +0200 From: "Elwell, John" To: "Charles Eckel (eckelcu)" , "siprec@ietf.org" Date: Tue, 19 Jul 2011 11:02:52 +0200 Thread-Topic: cancel or restart/redo a recording Thread-Index: AcxFoRYSR6RXJJIDTUyS0vPdoEdm6gAUExmQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] cancel or restart/redo a recording X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 09:03:04 -0000 Charles, Looking at the requirements draft we have: "REQ-017: The mechanism MUST support a means for a recording-aware UA involved in a CS to request during a session that the recording of the 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 such requests." The present mechanism proposal addresses this to some extent, but on a per = medium basis. So the UA can request stopping / starting recording a given m= edium. There is no distinction between pausing and stopping and no distinct= ion between resuming and starting. Stopping an entire recording could be do= ne by a UA requesting that recording be stopped for each medium, but that a= ssumes the particular UA is aware of (participating in) all the media. So a= n audio-only UA participating in an audio-video conference might not have t= he ability to request stopping the recording of video and therefore might n= ot have the ability to request stopping the entire recording. You specifically said "cancel or restart/redo". Cancel might seem to indica= te that it be erased from the SRS archives, but I think we said anything to= do with retention is a policy matter and out of scope. Also "redo" implies= going back in time recording from the beginning again, which is hard to do= (requires buffering at the SRC?). Or maybe you just meant start again afte= r previously stopping the recording. So the question is whether the existing mechanism is sufficient. John > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Charles Eckel (eckelcu) > Sent: 19 July 2011 00:19 > To: siprec@ietf.org > Subject: [siprec] cancel or restart/redo a recording >=20 > Something common with existing recording solutions is=20 > allowing the user > to cancel or restart/redo a recording (i.e. while leaving a voice > messages, cancel the existing message and start recording a new one). > I do not see anything in the SIPREC requirements or protocol drafts to > support this. This could be considered a special case of playback and > therefore lie outside the scope of SIPREC. Does anyone see this as a > problem? >=20 > Thanks, > Charles=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > = From Ranjit.Avasarala@Polycom.com Tue Jul 19 03:46: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 DD6E921F8508 for ; Tue, 19 Jul 2011 03:46:16 -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 M4BBEWNgZBPq for ; Tue, 19 Jul 2011 03:46:16 -0700 (PDT) Received: from Hkgehubprd01.polycom.com (hkgehubprd01.polycom.com [140.242.6.225]) by ietfa.amsl.com (Postfix) with ESMTP id B078321F84FC for ; Tue, 19 Jul 2011 03:46:15 -0700 (PDT) Received: from Hkgmboxprd01.polycom.com ([fe80::7d4e:b35f:33e1:6ae3]) by Hkgehubprd01.polycom.com ([fe80::5efe:172.21.6.201%12]) with mapi; Tue, 19 Jul 2011 18:46:13 +0800 From: "Avasarala, Ranjit" To: "Elwell, John" , Leon Portman , Paul Kyzivat Date: Tue, 19 Jul 2011 18:45:55 +0800 Thread-Topic: [siprec] record-aware options tag Thread-Index: AcxEo8Bz8ETd3ydMSWGa13mU/wa4ogAfo/FgABS3rpAAHsD2EAAEI49w Message-ID: <9F9278CB1892FB48BF35CB5CC3992478A536CB2D8B@HKGMBOXPRD01.polycom.com> References: <059AF07365DC474393A19A3AF187DF740747F9B8@NAHALD.us.int.genesyslab.com> <059AF07365DC474393A19A3AF187DF74075211CA@NAHALD.us.int.genesyslab.com> <4E205F83.1080100@alum.mit.edu> <07465C1D981ABC41A344374066AE1A2C38B00DD6D6@TLVMBX01.nice.com> <4E231656.4070504@alum.mit.edu> <07465C1D981ABC41A344374066AE1A2C38B00DDA69@TLVMBX01.nice.com> <9F9278CB1892FB48BF35CB5CC3992478A536CB2B27@HKGMBOXPRD01.polycom.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] record-aware options tag X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 10:46:17 -0000 Hi John So how do I indicate to the SRS that a particular session has to recorded a= t the beginning of the session? Also say I want to begin recording at some = point in the session or end it at some point in between, how do I do this? I feel putting all info in INVITE alone is not useful! Regards Ranjit -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 Sent: Tuesday, July 19, 2011 2:19 PM To: Avasarala, Ranjit; Leon Portman; Paul Kyzivat Cc: siprec@ietf.org Subject: RE: [siprec] record-aware options tag Ranjit, Past discussions seem to have led to the following consensus: - We will not specify a means for a UA in a CS to "require" that the CS be = recorded. - We will specify means for a UA in a CS to express a preference whether or= not to record, but this will not be binding on any SRC. - This preference will be expressed on a per medium level, and therefore in= SDP (as currently proposed in the draft). It would be good to avoid opening up this issue again unless you have new t= echnical arguments. Thanks, John (as chair) > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Avasarala, Ranjit > Sent: 18 July 2011 19:07 > To: Leon Portman; Paul Kyzivat > Cc: siprec@ietf.org > Subject: Re: [siprec] record-aware options tag >=20 > Hi all > Are there any suggestions for option-tags to use for=20 > indicating that the session is to be recorded? E.g. record.=20 > E.g. "Require: record" could be used to indicate that a=20 > particular session should be recorded. >=20 > Thanks >=20 > Regards > Ranjit >=20 > -----Original Message----- > From: siprec-bounces@ietf.org=20 > [mailto:siprec-bounces@ietf.org] On Behalf Of Leon Portman > Sent: Monday, July 18, 2011 1:44 PM > To: Paul Kyzivat > Cc: siprec@ietf.org > Subject: Re: [siprec] record-aware options tag >=20 > I agree, there are multiple ways to indicate recording, like=20 > announcements etc. This whole discussion is less relevant to=20 > protocols and standards and more to policies, legalities and=20 > IETF RAVEN stuff. >=20 > Leon >=20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20 > Sent: Sunday, July 17, 2011 8:05 PM > To: Leon Portman > Cc: siprec@ietf.org > Subject: Re: [siprec] record-aware options tag >=20 > On 7/17/11 5:57 AM, Leon Portman wrote: > > The question is if the revised statement does not open a=20 > loophole for=20 > > local policy "not to indicate at all". And we don't want that >=20 > I think the two statements both have that possibility to the=20 > same degree. Is there a way to leave it to policy and not=20 > have that possibility? >=20 > And I think there are contexts in which the potential for=20 > recording is always known to be present and no further=20 > indication is required. For instance that is usually the=20 > situation with call center agent participants in call center calls. >=20 > Perhaps we could add something about compliance with legal=20 > requirements.=20 > But I'm reluctant to go that way. >=20 > Thanks, > Paul >=20 > > Leon > > > > > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > > Behalf Of Paul Kyzivat > > Sent: Friday, July 15, 2011 6:41 PM > > To: siprec@ietf.org > > Subject: Re: [siprec] record-aware options tag > > > > On 7/15/11 11:18 AM, Henry Lum wrote: > > > >> There is also some normative text on the obligation of an=20 > SRC if no=20 > >> recording awareness has been indicated. > >> > >> "When a UA has not indicated that it is recording=20 > aware, an SRC must > >> provide recording indications, where SRC is required=20 > to do so based > >> on policies, through other means such as playing a=20 > tone inband." > >> > >> Would the above text be sufficient? > > > > This is tricky, because ultimately what is required is all=20 > based on local policy. AFAICT all this is saying is "An SRC=20 > must do what its local policy requires it to do". > > > > Perhaps this could be strengthened as follows: > > > > "When a UA has not indicated that it is recording=20 > aware, an SRC must > > provide recording indications via the media streams,=20 > unless local > > policy specifies some other means of indication." > > > > To a lawyer I don't think that is *any* stronger. But it *sounds*=20 > > stronger. :-) > > > > Thanks, > > Paul > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > > >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec >=20 From pkyzivat@alum.mit.edu Tue Jul 19 06:02:51 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7948121F85AA for ; Tue, 19 Jul 2011 06:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 4oyd6SGRSqIT for ; Tue, 19 Jul 2011 06:02:49 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by ietfa.amsl.com (Postfix) with ESMTP id D8BB121F85A3 for ; Tue, 19 Jul 2011 06:02:48 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta03.westchester.pa.mail.comcast.net with comcast id 9p2R1h0031ei1Bg53p2pGo; Tue, 19 Jul 2011 13:02:49 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta24.westchester.pa.mail.comcast.net with comcast id 9p2n1h00v0tdiYw3kp2nZB; Tue, 19 Jul 2011 13:02:48 +0000 Message-ID: <4E258075.2040503@alum.mit.edu> Date: Tue, 19 Jul 2011 09:02:45 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "Avasarala, Ranjit" References: <059AF07365DC474393A19A3AF187DF740747F9B8@NAHALD.us.int.genesyslab.com> <059AF07365DC474393A19A3AF187DF74075211CA@NAHALD.us.int.genesyslab.com> <4E205F83.1080100@alum.mit.edu> <07465C1D981ABC41A344374066AE1A2C38B00DD6D6@TLVMBX01.nice.com> <4E231656.4070504@alum.mit.edu> <07465C1D981ABC41A344374066AE1A2C38B00DDA69@TLVMBX01.nice.com> <9F9278CB1892FB48BF35CB5CC3992478A536CB2B27@HKGMBOXPRD01.polycom.com> <9F9278CB1892FB48BF35CB5CC3992478A536CB2D8B@HKGMBOXPRD01.polycom.com> In-Reply-To: <9F9278CB1892FB48BF35CB5CC3992478A536CB2D8B@HKGMBOXPRD01.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "siprec@ietf.org" Subject: Re: [siprec] record-aware options tag X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 13:02:51 -0000 A UA that is determined to have a session recorded can act as an SRC. In that case it needs no protocol mechanisms to cause that to happen. But if a UA is determined to require that some other entity be involved in the call as an SRC, then I think something considerably beyond what we have been addressing is required. For instance, suppose the UAC makes its request, and gets a successful response, but the response is from the UAS that happens to have SRC capabilities. The result may be a recording, but one that is inaccessible to the UAC. Presumably that wouldn't meet your expectations. Perhaps the UAC could accomplish its goals by ensuring that the call is routed through a particular SRC it knows will meet its needs. If it does that it may not need any additional protocol to initiate the recording - it would be implied by the SRC being in the call path. Thanks, Paul On 7/19/11 6:45 AM, Avasarala, Ranjit wrote: > Hi John > > So how do I indicate to the SRS that a particular session has to recorded at the beginning of the session? Also say I want to begin recording at some point in the session or end it at some point in between, how do I do this? > I feel putting all info in INVITE alone is not useful! > > Regards > Ranjit > > > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Tuesday, July 19, 2011 2:19 PM > To: Avasarala, Ranjit; Leon Portman; Paul Kyzivat > Cc: siprec@ietf.org > Subject: RE: [siprec] record-aware options tag > > Ranjit, > > Past discussions seem to have led to the following consensus: > - We will not specify a means for a UA in a CS to "require" that the CS be recorded. > - We will specify means for a UA in a CS to express a preference whether or not to record, but this will not be binding on any SRC. > - This preference will be expressed on a per medium level, and therefore in SDP (as currently proposed in the draft). > > It would be good to avoid opening up this issue again unless you have new technical arguments. > > Thanks, > > John (as chair) > > >> -----Original Message----- >> From: siprec-bounces@ietf.org >> [mailto:siprec-bounces@ietf.org] On Behalf Of Avasarala, Ranjit >> Sent: 18 July 2011 19:07 >> To: Leon Portman; Paul Kyzivat >> Cc: siprec@ietf.org >> Subject: Re: [siprec] record-aware options tag >> >> Hi all >> Are there any suggestions for option-tags to use for >> indicating that the session is to be recorded? E.g. record. >> E.g. "Require: record" could be used to indicate that a >> particular session should be recorded. >> >> Thanks >> >> Regards >> Ranjit >> >> -----Original Message----- >> From: siprec-bounces@ietf.org >> [mailto:siprec-bounces@ietf.org] On Behalf Of Leon Portman >> Sent: Monday, July 18, 2011 1:44 PM >> To: Paul Kyzivat >> Cc: siprec@ietf.org >> Subject: Re: [siprec] record-aware options tag >> >> I agree, there are multiple ways to indicate recording, like >> announcements etc. This whole discussion is less relevant to >> protocols and standards and more to policies, legalities and >> IETF RAVEN stuff. >> >> Leon >> >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: Sunday, July 17, 2011 8:05 PM >> To: Leon Portman >> Cc: siprec@ietf.org >> Subject: Re: [siprec] record-aware options tag >> >> On 7/17/11 5:57 AM, Leon Portman wrote: >>> The question is if the revised statement does not open a >> loophole for >>> local policy "not to indicate at all". And we don't want that >> >> I think the two statements both have that possibility to the >> same degree. Is there a way to leave it to policy and not >> have that possibility? >> >> And I think there are contexts in which the potential for >> recording is always known to be present and no further >> indication is required. For instance that is usually the >> situation with call center agent participants in call center calls. >> >> Perhaps we could add something about compliance with legal >> requirements. >> But I'm reluctant to go that way. >> >> Thanks, >> Paul >> >>> Leon >>> >>> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>> Behalf Of Paul Kyzivat >>> Sent: Friday, July 15, 2011 6:41 PM >>> To: siprec@ietf.org >>> Subject: Re: [siprec] record-aware options tag >>> >>> On 7/15/11 11:18 AM, Henry Lum wrote: >>> >>>> There is also some normative text on the obligation of an >> SRC if no >>>> recording awareness has been indicated. >>>> >>>> "When a UA has not indicated that it is recording >> aware, an SRC must >>>> provide recording indications, where SRC is required >> to do so based >>>> on policies, through other means such as playing a >> tone inband." >>>> >>>> Would the above text be sufficient? >>> >>> This is tricky, because ultimately what is required is all >> based on local policy. AFAICT all this is saying is "An SRC >> must do what its local policy requires it to do". >>> >>> Perhaps this could be strengthened as follows: >>> >>> "When a UA has not indicated that it is recording >> aware, an SRC must >>> provide recording indications via the media streams, >> unless local >>> policy specifies some other means of indication." >>> >>> To a lawyer I don't think that is *any* stronger. But it *sounds* >>> stronger. :-) >>> >>> Thanks, >>> Paul >>> _______________________________________________ >>> siprec mailing list >>> siprec@ietf.org >>> https://www.ietf.org/mailman/listinfo/siprec >>> >> >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >> > From john.elwell@siemens-enterprise.com Tue Jul 19 06:31: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 AB76121F86E8 for ; Tue, 19 Jul 2011 06:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.431 X-Spam-Level: X-Spam-Status: No, score=-104.431 tagged_above=-999 required=5 tests=[AWL=-1.832, 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 oXXNaDwlUSuO for ; Tue, 19 Jul 2011 06:31:07 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8856A21F84E0 for ; Tue, 19 Jul 2011 06:31:06 -0700 (PDT) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id E3AB01EB841F; Tue, 19 Jul 2011 15:31:03 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 19 Jul 2011 15:31:03 +0200 From: "Elwell, John" To: "Avasarala, Ranjit" , Leon Portman , Paul Kyzivat Date: Tue, 19 Jul 2011 15:31:01 +0200 Thread-Topic: [siprec] record-aware options tag Thread-Index: AcxEo8Bz8ETd3ydMSWGa13mU/wa4ogAfo/FgABS3rpAAHsD2EAAEI49wAAXESZA= Message-ID: References: <059AF07365DC474393A19A3AF187DF740747F9B8@NAHALD.us.int.genesyslab.com> <059AF07365DC474393A19A3AF187DF74075211CA@NAHALD.us.int.genesyslab.com> <4E205F83.1080100@alum.mit.edu> <07465C1D981ABC41A344374066AE1A2C38B00DD6D6@TLVMBX01.nice.com> <4E231656.4070504@alum.mit.edu> <07465C1D981ABC41A344374066AE1A2C38B00DDA69@TLVMBX01.nice.com> <9F9278CB1892FB48BF35CB5CC3992478A536CB2B27@HKGMBOXPRD01.polycom.com> <9F9278CB1892FB48BF35CB5CC3992478A536CB2D8B@HKGMBOXPRD01.polycom.com> In-Reply-To: <9F9278CB1892FB48BF35CB5CC3992478A536CB2D8B@HKGMBOXPRD01.polycom.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] record-aware options tag X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 13:31:07 -0000 Ranjit, You ask how to indicate to the SRS that a particular session has to be reco= rded. Did you really mean SRS? If so, that is achieved using the SIPREC pro= tocol and the transfer of metadata, including updates to metadata during th= e session (e.g., any pausing and resuming of streams). John=20 > -----Original Message----- > From: Avasarala, Ranjit [mailto:Ranjit.Avasarala@Polycom.com]=20 > Sent: 19 July 2011 11:46 > To: Elwell, John; Leon Portman; Paul Kyzivat > Cc: siprec@ietf.org > Subject: RE: [siprec] record-aware options tag >=20 > Hi John >=20 > So how do I indicate to the SRS that a particular session has=20 > to recorded at the beginning of the session? Also say I want=20 > to begin recording at some point in the session or end it at=20 > some point in between, how do I do this? > I feel putting all info in INVITE alone is not useful! >=20 > Regards > Ranjit >=20 >=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > Sent: Tuesday, July 19, 2011 2:19 PM > To: Avasarala, Ranjit; Leon Portman; Paul Kyzivat > Cc: siprec@ietf.org > Subject: RE: [siprec] record-aware options tag >=20 > Ranjit, >=20 > Past discussions seem to have led to the following consensus: > - We will not specify a means for a UA in a CS to "require"=20 > that the CS be recorded. > - We will specify means for a UA in a CS to express a=20 > preference whether or not to record, but this will not be=20 > binding on any SRC. > - This preference will be expressed on a per medium level,=20 > and therefore in SDP (as currently proposed in the draft). >=20 > It would be good to avoid opening up this issue again unless=20 > you have new technical arguments. >=20 > Thanks, >=20 > John (as chair) >=20 >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org=20 > > [mailto:siprec-bounces@ietf.org] On Behalf Of Avasarala, Ranjit > > Sent: 18 July 2011 19:07 > > To: Leon Portman; Paul Kyzivat > > Cc: siprec@ietf.org > > Subject: Re: [siprec] record-aware options tag > >=20 > > Hi all > > Are there any suggestions for option-tags to use for=20 > > indicating that the session is to be recorded? E.g. record.=20 > > E.g. "Require: record" could be used to indicate that a=20 > > particular session should be recorded. > >=20 > > Thanks > >=20 > > Regards > > Ranjit > >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org=20 > > [mailto:siprec-bounces@ietf.org] On Behalf Of Leon Portman > > Sent: Monday, July 18, 2011 1:44 PM > > To: Paul Kyzivat > > Cc: siprec@ietf.org > > Subject: Re: [siprec] record-aware options tag > >=20 > > I agree, there are multiple ways to indicate recording, like=20 > > announcements etc. This whole discussion is less relevant to=20 > > protocols and standards and more to policies, legalities and=20 > > IETF RAVEN stuff. > >=20 > > Leon > >=20 > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20 > > Sent: Sunday, July 17, 2011 8:05 PM > > To: Leon Portman > > Cc: siprec@ietf.org > > Subject: Re: [siprec] record-aware options tag > >=20 > > On 7/17/11 5:57 AM, Leon Portman wrote: > > > The question is if the revised statement does not open a=20 > > loophole for=20 > > > local policy "not to indicate at all". And we don't want that > >=20 > > I think the two statements both have that possibility to the=20 > > same degree. Is there a way to leave it to policy and not=20 > > have that possibility? > >=20 > > And I think there are contexts in which the potential for=20 > > recording is always known to be present and no further=20 > > indication is required. For instance that is usually the=20 > > situation with call center agent participants in call center calls. > >=20 > > Perhaps we could add something about compliance with legal=20 > > requirements.=20 > > But I'm reluctant to go that way. > >=20 > > Thanks, > > Paul > >=20 > > > Leon > > > > > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > > > Behalf Of Paul Kyzivat > > > Sent: Friday, July 15, 2011 6:41 PM > > > To: siprec@ietf.org > > > Subject: Re: [siprec] record-aware options tag > > > > > > On 7/15/11 11:18 AM, Henry Lum wrote: > > > > > >> There is also some normative text on the obligation of an=20 > > SRC if no=20 > > >> recording awareness has been indicated. > > >> > > >> "When a UA has not indicated that it is recording=20 > > aware, an SRC must > > >> provide recording indications, where SRC is required=20 > > to do so based > > >> on policies, through other means such as playing a=20 > > tone inband." > > >> > > >> Would the above text be sufficient? > > > > > > This is tricky, because ultimately what is required is all=20 > > based on local policy. AFAICT all this is saying is "An SRC=20 > > must do what its local policy requires it to do". > > > > > > Perhaps this could be strengthened as follows: > > > > > > "When a UA has not indicated that it is recording=20 > > aware, an SRC must > > > provide recording indications via the media streams,=20 > > unless local > > > policy specifies some other means of indication." > > > > > > To a lawyer I don't think that is *any* stronger. But it *sounds*=20 > > > stronger. :-) > > > > > > Thanks, > > > Paul > > > _______________________________________________ > > > siprec mailing list > > > siprec@ietf.org > > > https://www.ietf.org/mailman/listinfo/siprec > > > > >=20 > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > >=20 > = From eckelcu@cisco.com Tue Jul 19 07:56: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 4DFCB21F84F6 for ; Tue, 19 Jul 2011 07:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.92 X-Spam-Level: X-Spam-Status: No, score=-3.92 tagged_above=-999 required=5 tests=[AWL=-1.321, 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 dX9CJh+6qtRG for ; Tue, 19 Jul 2011 07:56:22 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 0F91A21F8564 for ; Tue, 19 Jul 2011 07:56:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=4092; q=dns/txt; s=iport; t=1311087380; x=1312296980; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=tBk6FkZwSPkGHtkqm49JIzqpIvX+kjBklWwzpxW5U78=; b=DY+mFvF7PsvMq4KoHqIg16wiM8upVvMp6HGrid+q7efTPl3N2zEYxVH4 4tsgB+3o3p2QvEgd9pP95KPwpfX60//fwBTUvElietP3lw5INe4igvR8m K06UGmpMGFYXDa1+A6hr/50r8N3XtD4Bt57oXHAZZTrqD7HjLriKKwv1n o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuIAAOaaJU6rRDoJ/2dsb2JhbABUmAiPRXeuGZ5MhV1fBIdUkCCLbQ X-IronPort-AV: E=Sophos;i="4.67,228,1309737600"; d="scan'208";a="4363478" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-4.cisco.com with ESMTP; 19 Jul 2011 14:56:18 +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 p6JEuBjm029984; Tue, 19 Jul 2011 14:56:18 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, 19 Jul 2011 07:56:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 19 Jul 2011 07:56:16 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: cancel or restart/redo a recording Thread-Index: AcxFoRYSR6RXJJIDTUyS0vPdoEdm6gAUExmQAAvgOoA= References: From: "Charles Eckel (eckelcu)" To: "Elwell, John" , X-OriginalArrivalTime: 19 Jul 2011 14:56:18.0020 (UTC) FILETIME=[039BA240:01CC4624] Subject: Re: [siprec] cancel or restart/redo a recording X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 14:56:26 -0000 Hi John, To phrase it another way, I am looking for a way to: 1) start "My Recording" at time t+0 2) stop "My Recording" at time+1 because I messed up what I wanted to say 3) erase "My Recording" at time+2 4) start "My Recording" at time+3 in hopes of expressing my message more clearly Repeat steps 2-4 as many times as necessary. My goal is to have a single version of "My Recording". It seems that instead I would have multiple versions, "My Recording 1", My Recording 2", etc., and I would use mechanism outside of the scope of SIPREC to perhaps delete and rename the recordings to get the combination I wanted. Going back to my voicemail example, if I made several attempts at leaving a voicemail for someone, I would really be creating multiple recordings. Eventually the last recording would get put into the voicemail box of the called party, and the other versions would still exist but probably get deleted by some other mechanism. As I understand it, SIPREC is concerned with facilitating the recording of the various voicemail attempts. Ultimately selecting one of these versions and erasing the rest is outside of the scope of SIPREC. I think I am okay with that, but I wanted to make sure this was the intention of the group. Thanks, Charles > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Tuesday, July 19, 2011 2:03 AM > To: Charles Eckel (eckelcu); siprec@ietf.org > Subject: RE: cancel or restart/redo a recording >=20 > Charles, >=20 > Looking at the requirements draft we have: > "REQ-017: The mechanism MUST support a means for a recording-aware > UA involved in a CS to request during a session that the recording of > the 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 such requests." > The present mechanism proposal addresses this to some extent, but on a per medium basis. So the UA can > request stopping / starting recording a given medium. There is no distinction between pausing and > stopping and no distinction between resuming and starting. Stopping an entire recording could be done > by a UA requesting that recording be stopped for each medium, but that assumes the particular UA is > aware of (participating in) all the media. So an audio-only UA participating in an audio-video > conference might not have the ability to request stopping the recording of video and therefore might > not have the ability to request stopping the entire recording. >=20 > You specifically said "cancel or restart/redo". Cancel might seem to indicate that it be erased from > the SRS archives, but I think we said anything to do with retention is a policy matter and out of > scope. Also "redo" implies going back in time recording from the beginning again, which is hard to do > (requires buffering at the SRC?). Or maybe you just meant start again after previously stopping the > recording. >=20 > So the question is whether the existing mechanism is sufficient. >=20 > John >=20 >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org > > [mailto:siprec-bounces@ietf.org] On Behalf Of Charles Eckel (eckelcu) > > Sent: 19 July 2011 00:19 > > To: siprec@ietf.org > > Subject: [siprec] cancel or restart/redo a recording > > > > Something common with existing recording solutions is > > allowing the user > > to cancel or restart/redo a recording (i.e. while leaving a voice > > messages, cancel the existing message and start recording a new one). > > I do not see anything in the SIPREC requirements or protocol drafts to > > support this. This could be considered a special case of playback and > > therefore lie outside the scope of SIPREC. Does anyone see this as a > > problem? > > > > Thanks, > > Charles > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > > From john.elwell@siemens-enterprise.com Wed Jul 20 02:04: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 4067121F86E9 for ; Wed, 20 Jul 2011 02:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.392 X-Spam-Level: X-Spam-Status: No, score=-104.392 tagged_above=-999 required=5 tests=[AWL=-1.793, 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 s46E1ZQYomOw for ; Wed, 20 Jul 2011 02:04:06 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 4961621F86A5 for ; Wed, 20 Jul 2011 02:04:06 -0700 (PDT) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 8C4651EB8443 for ; Wed, 20 Jul 2011 11:04:04 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 20 Jul 2011 11:04:02 +0200 From: "Elwell, John" To: "siprec@ietf.org" Date: Wed, 20 Jul 2011 11:04:01 +0200 Thread-Topic: Interim proceedings now formally published Thread-Index: AcxGu/d6oMCkQICSTLyLWGZjzNBmyA== 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 proceedings now formally published X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 09:04:10 -0000 All interim proceedings between IETF#78 and IETF#81 are now published by th= e secretariat at: http://www.ietf.org/meeting/interim/draft-proceedings.html (Those prior to IETF#78 were published as part of the IETF#78 proceedings) A tool is becoming available to make publication of interim proceedings eas= ier, so I hope there will not be such a long delay in future. John John Elwell Tel: +44 1908 817801 (office and mobile) Email: john.elwell@siemens-enterprise.com http://www.siemens-enterprise.com/uk/ Siemens Enterprise Communications Limited. Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ. Registered No: 5903714, England. Siemens Enterprise Communications Limited is a Trademark Licensee of Siemen= s AG. = From john.elwell@siemens-enterprise.com Wed Jul 20 02:48: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 CC7A821F888A for ; Wed, 20 Jul 2011 02:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.321 X-Spam-Level: X-Spam-Status: No, score=-104.321 tagged_above=-999 required=5 tests=[AWL=-1.722, 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 jEmHWI30gMDN for ; Wed, 20 Jul 2011 02:48:30 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 8294921F865E for ; Wed, 20 Jul 2011 02:48:30 -0700 (PDT) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id E7E6123F03F5 for ; Wed, 20 Jul 2011 11:48:29 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 20 Jul 2011 11:48:29 +0200 From: "Elwell, John" To: "siprec@ietf.org" Date: Wed, 20 Jul 2011 11:48:28 +0200 Thread-Topic: Agenda slots and slides Thread-Index: AcxGwi1VcKScL9evSa+zfEhnNCwUkg== 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] Agenda slots and slides X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 09:48:34 -0000 I really need to finalise the agenda - I have had little feedback on times = required or whether indeed a topic needs to be on the agenda. Would all aut= hors please respond. Also, please let me have your initial slides by Sunday= - they can always be updated later in the week, up to the day before the m= eeting. Thanks, John John Elwell Tel: +44 1908 817801 (office and mobile) Email: john.elwell@siemens-enterprise.com http://www.siemens-enterprise.com/uk/ Siemens Enterprise Communications Limited. Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ. Registered No: 5903714, England. Siemens Enterprise Communications Limited is a Trademark Licensee of Siemen= s AG. From pkyzivat@alum.mit.edu Wed Jul 20 07:52: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 4143421F863E for ; Wed, 20 Jul 2011 07:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 LXDDRSRAZDY3 for ; Wed, 20 Jul 2011 07:52:15 -0700 (PDT) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by ietfa.amsl.com (Postfix) with ESMTP id 57DB521F85EC for ; Wed, 20 Jul 2011 07:52:15 -0700 (PDT) Received: from omta10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by qmta03.emeryville.ca.mail.comcast.net with comcast id AErM1h0060cQ2SLA3EsCBm; Wed, 20 Jul 2011 14:52:12 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta10.emeryville.ca.mail.comcast.net with comcast id AEsB1h00g0tdiYw8WEsCPw; Wed, 20 Jul 2011 14:52:13 +0000 Message-ID: <4E26EB9C.90200@alum.mit.edu> Date: Wed, 20 Jul 2011 10:52:12 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: siprec@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] cancel or restart/redo a recording X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 14:52:19 -0000 On 7/19/11 10:56 AM, Charles Eckel (eckelcu) wrote: > Hi John, > > To phrase it another way, I am looking for a way to: > 1) start "My Recording" at time t+0 > 2) stop "My Recording" at time+1 because I messed up what I wanted to > say > 3) erase "My Recording" at time+2 > 4) start "My Recording" at time+3 in hopes of expressing my message more > clearly > Repeat steps 2-4 as many times as necessary. So, you are trying to make this into the control interface for a voicemail server? Something akin to RTSP??? For that I think you would also want control over playback, so you could hear your recording. While I guess siprec could be used as part of the infrastructure for a VM server, I don't know if it is really ideal for that. And even if so, I think this functionality is quite a different interface. IMO this is not in scope for the current effort. Thanks, Paul > My goal is to have a single version of "My Recording". It seems that > instead I would have multiple versions, "My Recording 1", My Recording > 2", etc., and I would use mechanism outside of the scope of SIPREC to > perhaps delete and rename the recordings to get the combination I > wanted. > Going back to my voicemail example, if I made several attempts at > leaving a voicemail for someone, I would really be creating multiple > recordings. Eventually the last recording would get put into the > voicemail box of the called party, and the other versions would still > exist but probably get deleted by some other mechanism. > As I understand it, SIPREC is concerned with facilitating the recording > of the various voicemail attempts. Ultimately selecting one of these > versions and erasing the rest is outside of the scope of SIPREC. I think > I am okay with that, but I wanted to make sure this was the intention of > the group. > > Thanks, > Charles > > >> -----Original Message----- >> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >> Sent: Tuesday, July 19, 2011 2:03 AM >> To: Charles Eckel (eckelcu); siprec@ietf.org >> Subject: RE: cancel or restart/redo a recording >> >> Charles, >> >> Looking at the requirements draft we have: >> "REQ-017: The mechanism MUST support a means for a recording-aware >> UA involved in a CS to request during a session that the recording > of >> the 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 such requests." >> The present mechanism proposal addresses this to some extent, but on a > per medium basis. So the UA can >> request stopping / starting recording a given medium. There is no > distinction between pausing and >> stopping and no distinction between resuming and starting. Stopping an > entire recording could be done >> by a UA requesting that recording be stopped for each medium, but that > assumes the particular UA is >> aware of (participating in) all the media. So an audio-only UA > participating in an audio-video >> conference might not have the ability to request stopping the > recording of video and therefore might >> not have the ability to request stopping the entire recording. >> >> You specifically said "cancel or restart/redo". Cancel might seem to > indicate that it be erased from >> the SRS archives, but I think we said anything to do with retention is > a policy matter and out of >> scope. Also "redo" implies going back in time recording from the > beginning again, which is hard to do >> (requires buffering at the SRC?). Or maybe you just meant start again > after previously stopping the >> recording. >> >> So the question is whether the existing mechanism is sufficient. >> >> John >> >> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org >>> [mailto:siprec-bounces@ietf.org] On Behalf Of Charles Eckel > (eckelcu) >>> Sent: 19 July 2011 00:19 >>> To: siprec@ietf.org >>> Subject: [siprec] cancel or restart/redo a recording >>> >>> Something common with existing recording solutions is >>> allowing the user >>> to cancel or restart/redo a recording (i.e. while leaving a voice >>> messages, cancel the existing message and start recording a new > one). >>> I do not see anything in the SIPREC requirements or protocol drafts > to >>> support this. This could be considered a special case of playback > and >>> therefore lie outside the scope of SIPREC. Does anyone see this as a >>> problem? >>> >>> Thanks, >>> Charles >>> _______________________________________________ >>> siprec mailing list >>> siprec@ietf.org >>> https://www.ietf.org/mailman/listinfo/siprec >>> > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From pkyzivat@alum.mit.edu Wed Jul 20 08: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 8B25321F87D3 for ; Wed, 20 Jul 2011 08:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 FWdmVFeraws3 for ; Wed, 20 Jul 2011 08:10:39 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by ietfa.amsl.com (Postfix) with ESMTP id 583E721F85C6 for ; Wed, 20 Jul 2011 08:10:39 -0700 (PDT) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta07.westchester.pa.mail.comcast.net with comcast id AEzm1h0020Fqzac57FAfwn; Wed, 20 Jul 2011 15:10:39 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta08.westchester.pa.mail.comcast.net with comcast id AFAb1h01r0tdiYw3UFAcqb; Wed, 20 Jul 2011 15:10:38 +0000 Message-ID: <4E26EFE9.3050507@alum.mit.edu> Date: Wed, 20 Jul 2011 11:10:33 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: siprec@ietf.org References: <059AF07365DC474393A19A3AF187DF74075211C2@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] what to put in the message header to indicatemetadata snapshot request X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 15:10:40 -0000 On 7/18/11 6:41 PM, Charles Eckel (eckelcu) wrote: > I was initially thinking of this from the perspective of wanting to > avoid requiring metadata processing on the behalf of the SRS or SRC in > order to request a snapshot. In this case, a SIP header is appealing. I agree that it would be good to simplify the processing the SRC must do to recognize the request. This could be done using a sip header, but also by using a body with a different content type from that of the metadata. That body might not be xml - it might simply be text with a very simple syntax. > Another option, and the one implied by section 5.5 of the draft, is to > enable generic metadata error handling. If you want to do this, > requesting a snapshot could be a type of error reported by the SRS, and > sending a snapshot could be a recovery mechanism used by the SRC. More > complex error reporting and recovery would probably involve some sort of > metadata sequence number and an indication of the last sequence number > processed properly on the SRS. This would enable the SRC to send updates > based on an intermediate point in the recording. IMO many of the primary use cases for recording are likely to be paranoid about recording as much as possible even in the face of errors. This probably translates into capturing the incoming media from the negotiated RS media streams even if the metadata is missing or malformed. And maybe capturing the metadata even if it is malformed. Another priority is probably to simply SRCs, since they are likely to be grafted onto lots of things. I don't think it is a good idea to expect the SRC to maintain a lot of data to facilitate error recovery. As a result, I don't see complex error recovery mechanisms as helpful. Simple ones are probably all that we should expect an SRC to be able to handle, and are all that would be very useful. I've also been pondering what "full" means for metadata in contrast to "partial". I am coming to the conclusion that to the SRS there is really no difference - "full" metadata is processed exactly the same way as "partial" is. It is just likely to contain data that would be redundant if all had gone well before. From the perspective of the SRC, a request for a snapshot simply means "send everything you currently know about all the media streams you currently are sending to the SRS, and then continue sending updates after that." Thanks, Paul > I am thinking the former mechanism is sufficient. The latter mechanism, > though definitely much more efficient in many cases, is more complex. > The cynic/realist in me thinks that with either method, the odds are > high that once an error is encountered any recovery mechanism (e.g. a > snapshot, an intermediate update, etc.) has a high probability of > failing. The important thing is to be able to debug the failure. For > example, it may be that the update resulted in a parsing error on the RS > within some participant element. I see some value in having this in some > SIP or metadata message, but having it enable auto-recovery is not > likely. > As I do not see any error handling within the current metadata > model/format, I am thinking it is best to leave the snapshot request > outside of the context of the metadata. > > Cheers, > Charles > > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Elwell, John >> Sent: Monday, July 18, 2011 12:45 AM >> To: Henry Lum; siprec@ietf.org >> Subject: Re: [siprec] what to put in the message header to > indicatemetadata snapshot request >> >> Henry, >> >> At the last interim it was minuted: >> "Slide 8: Concerning the nature of a snapshot request, Charles thought > this could be just a simple >> request, with no parameters. The discussion seemed to lean towards > something in the header, rather >> than in the body. To be continued on the list." >> I don't recall much discussion on the list, but the proposal in 05 for > a body part seems to go against >> the meeting's general preference for something in the header. >> >> I also don't recall anything in either the metadata draft or in the > protocol draft to help the SRS >> determine whether it has lost a metadata update (and therefore needs > to request a snapshot). Some sort >> of sequence numbering is perhaps required. >> >> John >> >> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org >>> [mailto:siprec-bounces@ietf.org] On Behalf Of Henry Lum >>> Sent: 15 July 2011 16:12 >>> To: siprec@ietf.org >>> Subject: [siprec] what to put in the message header to >>> indicate metadata snapshot request >>> >>> Hi, >>> >>> >>> >>> In the latest protocol draft revision (05) I proposed a >>> mechanism to request for metadata snapshot request. This is >>> outlined in section 5.5. I want to get some comments on >>> whether the proposed mechanism is sufficient. >>> >>> >>> >>> Thanks >>> >>> 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. >>> >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From pkyzivat@alum.mit.edu Wed Jul 20 08:42:23 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E33D21F86C0 for ; Wed, 20 Jul 2011 08:42:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 47HiE7gBvTZF for ; Wed, 20 Jul 2011 08:42:22 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9C721F85E2 for ; Wed, 20 Jul 2011 08:42:22 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta05.westchester.pa.mail.comcast.net with comcast id AFav1h0031YDfWL55FiNLC; Wed, 20 Jul 2011 15:42:22 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta20.westchester.pa.mail.comcast.net with comcast id AFiE1h00N0tdiYw3gFiHCY; Wed, 20 Jul 2011 15:42:20 +0000 Message-ID: <4E26F755.20704@alum.mit.edu> Date: Wed, 20 Jul 2011 11:42:13 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "Ram Mohan R (rmohanr)" , "Parthasarathi R (partr)" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "siprec@ietf.org" Subject: [siprec] recording callee capabilities X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 15:42:23 -0000 Based on discussions, I think we ought to provide for capturing "callee capabilities" as defined in RFC 3840 in the metadata. This would give access to properties such as "isFocus" that could be significant. As defined in 3840, callee capabilities are passed around as header field parameters of the Contact header, both in REGISTER requests and in Contacts specifying the remote target of dialogs. Its the ones in dialogs that make sense for siprec. The main questions I see about this are: - where in the metamodel do these belong? - how should these be represented in XML? Regarding where these belong in the metamodel: My first thought is that they are attributes of a Participant. Typically participants correspond to UAs involved in a session (dialog). A problem with that approach is that we plan to share Participants among multiple sessions. But a Participant may not report the same capabilities in every dialog it is involved in. For instance, while a UA may be *capable* of being a focus, it will probably only report the isFocus capability in dialogs where it is actually serving as a focus. (This probably is evidence that isFocus is not a proper capability.) To solve this, an SRC might have to represent a UA involved in two sessions as two *different* participants in order to correctly report the capabilities UA in each session. That in turn would make it harder for the SRS to determine that the two sessions have a common participant. In spite of this problem, and with reservations, I do propose that we make capabilities attributes of Participant. Each Participant would have zero or more Capabilities. How to represent capabilities in XML? In the ABNF syntax of 3840, each capability is encoded as a feature-param: feature-param = enc-feature-tag [EQUAL LDQUOT (tag-value-list / string-value ) RDQUOT] enc-feature-tag = base-tags / other-tags base-tags = "audio" / "automata" / "class" / "duplex" / "data" / "control" / "mobility" / "description" / "events" / "priority" / "methods" / "schemes" / "application" / "video" / "language" / "type" / "isfocus" / "actor" / "text" / "extensions" other-tags = "+" ftag-name ftag-name = ALPHA *( ALPHA / DIGIT / "!" / "'" / "." / "-" / "%" ) tag-value-list = tag-value *("," tag-value) tag-value = ["!"] (token-nobang / boolean / numeric) token-nobang = 1*(alphanum / "-" / "." / "%" / "*" / "_" / "+" / "`" / "'" / "~" ) boolean = "TRUE" / "FALSE" numeric = "#" numeric-relation number numeric-relation = ">=" / "<=" / "=" / (number ":") number = [ "+" / "-" ] 1*DIGIT ["." 0*DIGIT] string-value = "<" *(qdtext-no-abkt / quoted-pair ) ">" qdtext-no-abkt = LWS / %x21 / %x23-3B / %x3D / %x3F-5B / %x5D-7E / UTF8-NONASCII (When the optional value part is missing, the default is "TRUE". This is specified in section 8 of 3841.) This needs to be represented as an XML element that can be present zero or more times in the 'participant' element. I'm no xml expert, so I'm hoping for one to help get this right. I see a few general approaches to defining this element: - as a single value containing the entire feature-param. E.g. isFocus="TRUE" - passing the capability name and value as xml attributes. E.g. In this case we could either make value optional, or require that the default be filled out. - passing the name and value as subelements. E.g. isFocus TRUE Again we could require the value or allow it to be optional - a hybrid of the above. E.g. or TRUE Another possibility would be to take the parsing a step further and provide separate xml syntax for string-value and tag-value-list, breaking out the individual tag-values of the tag-value-list. Even if we don't do that, there may be character set and escaping issues to deal with. The string-value uses quoted-pair from 3261 (a backslash followed by two hex digits) to represent some characters. I don't know, but suspect that is alien to xml, which has its own escaping conventions. And token-nobang includes some special characters - are any of them problematic for xml? Thanks, Paul From alan.b.johnston@gmail.com Wed Jul 20 09:24: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 3CC4721F8AD8 for ; Wed, 20 Jul 2011 09:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.516 X-Spam-Level: X-Spam-Status: No, score=-103.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 rjYK2cC0NOlU for ; Wed, 20 Jul 2011 09:24:41 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5FBF821F8ACC for ; Wed, 20 Jul 2011 09:24:41 -0700 (PDT) Received: by ywp31 with SMTP id 31so202036ywp.31 for ; Wed, 20 Jul 2011 09:24:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=bl8B8ON+HoodNotHFF6q4K8X5W1lPltlLrEDrxk/yVk=; b=jxxH6EGqGvl5NpDJ1XWgG5VpmrdmSFrBA2G/1BAlLqu+DzL8TGDaEMLXkv4huHzAQc FCcJXdzCiSCYwwbgBMXFxXyffAyS8DdlXVFmH+IdxB4SERZIhSrLWOf8UkkZ+BVHDD6H NKl12bgEHnV+kGSwmQFZ8I098E9917cIHtIkc= MIME-Version: 1.0 Received: by 10.150.193.1 with SMTP id q1mr3107521ybf.225.1311179079866; Wed, 20 Jul 2011 09:24:39 -0700 (PDT) Received: by 10.151.106.1 with HTTP; Wed, 20 Jul 2011 09:24:39 -0700 (PDT) In-Reply-To: <4E26F755.20704@alum.mit.edu> References: <4E26F755.20704@alum.mit.edu> Date: Wed, 20 Jul 2011 11:24:39 -0500 Message-ID: From: Alan Johnston To: Paul Kyzivat Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "siprec@ietf.org" Subject: Re: [siprec] recording callee capabilities X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 16:24:42 -0000 This is how it is done in RFC 4235: sip:alice@example.com - Alan - On Wed, Jul 20, 2011 at 10:42 AM, Paul Kyzivat wrot= e: > Based on discussions, I think we ought to provide for capturing "callee > capabilities" as defined in RFC 3840 in the metadata. This would give acc= ess > to properties such as "isFocus" that could be significant. > > As defined in 3840, callee capabilities are passed around as header field > parameters of the Contact header, both in REGISTER requests and in Contac= ts > specifying the remote target of dialogs. Its the ones in dialogs that mak= e > sense for siprec. > > The main questions I see about this are: > - where in the metamodel do these belong? > - how should these be represented in XML? > > Regarding where these belong in the metamodel: > > My first thought is that they are attributes of a Participant. Typically > participants correspond to UAs involved in a session (dialog). > > A problem with that approach is that we plan to share Participants among > multiple sessions. But a Participant may not report the same capabilities= in > every dialog it is involved in. For instance, while a UA may be *capable*= of > being a focus, it will probably only report the isFocus capability in > dialogs where it is actually serving as a focus. (This probably is eviden= ce > that isFocus is not a proper capability.) > > To solve this, an SRC might have to represent a UA involved in two sessio= ns > as two *different* participants in order to correctly report the > capabilities UA in each session. That in turn would make it harder for th= e > SRS to determine that the two sessions have a common participant. > > In spite of this problem, and with reservations, I do propose that we mak= e > capabilities attributes of Participant. Each Participant would have zero = or > more Capabilities. > > How to represent capabilities in XML? > > In the ABNF syntax of 3840, each capability is encoded as a feature-param= : > > =A0 feature-param =A0 =A0=3D =A0enc-feature-tag [EQUAL LDQUOT (tag-value-= list > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 / string-value ) RDQUOT] > =A0 enc-feature-tag =A0=3D =A0base-tags / other-tags > =A0 base-tags =A0 =A0 =A0 =A0=3D =A0"audio" / "automata" / > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "class" / "duplex" / "data" / > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "control" / "mobility" / "des= cription" / > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "events" / "priority" / "meth= ods" / > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "schemes" / "application" / "= video" / > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "language" / "type" / "isfocu= s" / > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "actor" / "text" / "extension= s" > =A0 other-tags =A0 =A0 =A0=3D =A0"+" ftag-name > =A0 ftag-name =A0 =A0 =A0 =3D =A0ALPHA *( ALPHA / DIGIT / "!" / "'" / > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"." / "-" / "%" ) > =A0 tag-value-list =A0=3D =A0tag-value *("," tag-value) > =A0 tag-value =A0 =A0 =A0 =3D =A0["!"] (token-nobang / boolean / numeric) > =A0 token-nobang =A0 =A0=3D =A01*(alphanum / "-" / "." / "%" / "*" > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/ "_" / "+" / "`" / "'" / "~" = ) > =A0 boolean =A0 =A0 =A0 =A0 =3D =A0"TRUE" / "FALSE" > =A0 numeric =A0 =A0 =A0 =A0 =3D =A0"#" numeric-relation number > =A0 numeric-relation =A0=3D =A0">=3D" / "<=3D" / "=3D" / (number ":") > =A0 number =A0 =A0 =A0 =A0 =A0=3D =A0[ "+" / "-" ] 1*DIGIT ["." 0*DIGIT] > =A0 string-value =A0 =A0=3D =A0"<" *(qdtext-no-abkt / quoted-pair ) ">" > =A0 qdtext-no-abkt =A0=3D =A0LWS / %x21 / %x23-3B / %x3D > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 / %x3F-5B / %x5D-7E /= UTF8-NONASCII > > (When the optional value part is missing, the default is "TRUE". This is > specified in section 8 of 3841.) > > This needs to be represented as an XML element that can be present zero o= r > more times in the 'participant' element. I'm no xml expert, so I'm hoping > for one to help get this right. I see a few general approaches to definin= g > this element: > > - as a single value containing the entire feature-param. E.g. > =A0isFocus=3D"TRUE" > > - passing the capability name and value as xml attributes. E.g. > =A0 > =A0In this case we could either make value optional, or require that > =A0the default be filled out. > > - passing the name and value as subelements. E.g. > =A0 > =A0 =A0 =A0isFocus > =A0 =A0 =A0TRUE > =A0 > =A0Again we could require the value or allow it to be optional > > - a hybrid of the above. E.g. > =A0 > =A0or > =A0TRUE > > Another possibility would be to take the parsing a step further and provi= de > separate xml syntax for string-value and tag-value-list, breaking out the > individual tag-values of the tag-value-list. > > Even if we don't do that, there may be character set and escaping issues = to > deal with. The string-value uses quoted-pair from 3261 (a backslash follo= wed > by two hex digits) to represent some characters. I don't know, but suspec= t > that is alien to xml, which has its own escaping conventions. And > token-nobang includes some special characters - are any of them problemat= ic > for xml? > > =A0 =A0 =A0 =A0Thanks, > =A0 =A0 =A0 =A0Paul > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From pkyzivat@alum.mit.edu Wed Jul 20 10:52: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 B995521F8AF5 for ; Wed, 20 Jul 2011 10:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 16a+0ahiFIls for ; Wed, 20 Jul 2011 10:52:38 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1FC21F8AF0 for ; Wed, 20 Jul 2011 10:52:38 -0700 (PDT) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta05.westchester.pa.mail.comcast.net with comcast id AHr21h0091wpRvQ55HsHkC; Wed, 20 Jul 2011 17:52:17 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta18.westchester.pa.mail.comcast.net with comcast id AHrB1h00c0tdiYw3eHrZ52; Wed, 20 Jul 2011 17:52:17 +0000 Message-ID: <4E27158D.4020308@alum.mit.edu> Date: Wed, 20 Jul 2011 13:51:09 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Alan Johnston References: <4E26F755.20704@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "siprec@ietf.org" Subject: Re: [siprec] recording callee capabilities X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 17:52:39 -0000 On 7/20/11 12:24 PM, Alan Johnston wrote: > This is how it is done in RFC 4235: > > > sip:alice@example.com > > > > > > > - Alan - Thanks Alan, I didn't think of that. It does provide a precedent we can consider following. It carries arbitrary contact parameters, not just capabilities. We can do that too. I am a little concerned about something it does (4.1.6.2): It can contain a list of Contact header parameters in param sub- elements (such as those defined in [10]). The param element contains two required attributes, pname and pval. Boolean parameters are represented by the explicit pval values, "true" and "false" (for example, when a feature parameter is explicitly negated). Parameters that have no value at all are represented by the explicit pval value "true". The param element itself has no contents. To avoid repeating Contact information in each request, the subscriber can assume that the target URI and parameters are the same as in previous notifications if no target element is present in the corresponding local or remote element. If a target element is present in the local or remote part of a notification, the new target tag and list of parameter tags completely supersedes the old target and parameter list in the corresponding part. Note that any quoting (including extra angle-bracket quoting used to quote string values in [10]) or backslash escaping MUST be removed before being placed in a pval attribute. Any remaining single quotes, double quotes, and ampersands MUST be properly XML escaped. If I am not mistaken, the removal of the angle quoting used to distinguish string-values introduces an ambiguity, in that it will then be impossible to distinguish a string-value from a tag-value-list. That may be a bug in 4235. I'll have to look into that. Fixing that bug will require more than a token change. Thanks, Paul > On Wed, Jul 20, 2011 at 10:42 AM, Paul Kyzivat wrote: >> Based on discussions, I think we ought to provide for capturing "callee >> capabilities" as defined in RFC 3840 in the metadata. This would give access >> to properties such as "isFocus" that could be significant. >> >> As defined in 3840, callee capabilities are passed around as header field >> parameters of the Contact header, both in REGISTER requests and in Contacts >> specifying the remote target of dialogs. Its the ones in dialogs that make >> sense for siprec. >> >> The main questions I see about this are: >> - where in the metamodel do these belong? >> - how should these be represented in XML? >> >> Regarding where these belong in the metamodel: >> >> My first thought is that they are attributes of a Participant. Typically >> participants correspond to UAs involved in a session (dialog). >> >> A problem with that approach is that we plan to share Participants among >> multiple sessions. But a Participant may not report the same capabilities in >> every dialog it is involved in. For instance, while a UA may be *capable* of >> being a focus, it will probably only report the isFocus capability in >> dialogs where it is actually serving as a focus. (This probably is evidence >> that isFocus is not a proper capability.) >> >> To solve this, an SRC might have to represent a UA involved in two sessions >> as two *different* participants in order to correctly report the >> capabilities UA in each session. That in turn would make it harder for the >> SRS to determine that the two sessions have a common participant. >> >> In spite of this problem, and with reservations, I do propose that we make >> capabilities attributes of Participant. Each Participant would have zero or >> more Capabilities. >> >> How to represent capabilities in XML? >> >> In the ABNF syntax of 3840, each capability is encoded as a feature-param: >> >> feature-param = enc-feature-tag [EQUAL LDQUOT (tag-value-list >> / string-value ) RDQUOT] >> enc-feature-tag = base-tags / other-tags >> base-tags = "audio" / "automata" / >> "class" / "duplex" / "data" / >> "control" / "mobility" / "description" / >> "events" / "priority" / "methods" / >> "schemes" / "application" / "video" / >> "language" / "type" / "isfocus" / >> "actor" / "text" / "extensions" >> other-tags = "+" ftag-name >> ftag-name = ALPHA *( ALPHA / DIGIT / "!" / "'" / >> "." / "-" / "%" ) >> tag-value-list = tag-value *("," tag-value) >> tag-value = ["!"] (token-nobang / boolean / numeric) >> token-nobang = 1*(alphanum / "-" / "." / "%" / "*" >> / "_" / "+" / "`" / "'" / "~" ) >> boolean = "TRUE" / "FALSE" >> numeric = "#" numeric-relation number >> numeric-relation = ">=" / "<=" / "=" / (number ":") >> number = [ "+" / "-" ] 1*DIGIT ["." 0*DIGIT] >> string-value = "<" *(qdtext-no-abkt / quoted-pair )">" >> qdtext-no-abkt = LWS / %x21 / %x23-3B / %x3D >> / %x3F-5B / %x5D-7E / UTF8-NONASCII >> >> (When the optional value part is missing, the default is "TRUE". This is >> specified in section 8 of 3841.) >> >> This needs to be represented as an XML element that can be present zero or >> more times in the 'participant' element. I'm no xml expert, so I'm hoping >> for one to help get this right. I see a few general approaches to defining >> this element: >> >> - as a single value containing the entire feature-param. E.g. >> isFocus="TRUE" >> >> - passing the capability name and value as xml attributes. E.g. >> >> In this case we could either make value optional, or require that >> the default be filled out. >> >> - passing the name and value as subelements. E.g. >> >> isFocus >> TRUE >> >> Again we could require the value or allow it to be optional >> >> - a hybrid of the above. E.g. >> >> or >> TRUE >> >> Another possibility would be to take the parsing a step further and provide >> separate xml syntax for string-value and tag-value-list, breaking out the >> individual tag-values of the tag-value-list. >> >> Even if we don't do that, there may be character set and escaping issues to >> deal with. The string-value uses quoted-pair from 3261 (a backslash followed >> by two hex digits) to represent some characters. I don't know, but suspect >> that is alien to xml, which has its own escaping conventions. And >> token-nobang includes some special characters - are any of them problematic >> for xml? >> >> Thanks, >> Paul >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >> > From eckelcu@cisco.com Wed Jul 20 11:34: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 93E4D21F8B1C for ; Wed, 20 Jul 2011 11:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.832 X-Spam-Level: X-Spam-Status: No, score=-3.832 tagged_above=-999 required=5 tests=[AWL=-1.233, 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 QwJzwXvCHuL5 for ; Wed, 20 Jul 2011 11:34:27 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id A104E21F8A1A for ; Wed, 20 Jul 2011 11:34:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=5747; q=dns/txt; s=iport; t=1311186867; x=1312396467; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=2cQNRwrjI0s4L2pUa8U+aFBVRkuIRn+/xSuGfmWHS04=; b=UxK4lUmdaqetTwhr9n3LppyYS+V4z83/TTIoNg7oD/7MLH3KU95/R2G+ 48jD0iDUZq1VF/q1yJbEmgq54UspPAMUdd9kuOMTTAGFngXgTDtrPpgV8 b9A4iCWNAk6HjVF5uNoQaZH0n2oBpCRAOLquNMi9rPjKlOL9GroidcOkz s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AucAAMIeJ06rRDoH/2dsb2JhbABTEJgMj0t3qlieKoVeXwSHVZApixZX X-IronPort-AV: E=Sophos;i="4.67,236,1309737600"; d="scan'208";a="4827950" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-6.cisco.com with ESMTP; 20 Jul 2011 18:34:27 +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 p6KIXp2K020489; Wed, 20 Jul 2011 18:34: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); Wed, 20 Jul 2011 11:34:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Jul 2011 11:34:17 -0700 Message-ID: In-Reply-To: <4E26EB9C.90200@alum.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] cancel or restart/redo a recording Thread-Index: AcxG7KIpFEC2zD0ZRwi/dabwjpzaWgAHtvnQ References: <4E26EB9C.90200@alum.mit.edu> From: "Charles Eckel (eckelcu)" To: "Paul Kyzivat" , X-OriginalArrivalTime: 20 Jul 2011 18:34:19.0475 (UTC) FILETIME=[A32D0230:01CC470B] Subject: Re: [siprec] cancel or restart/redo a recording X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 18:34:31 -0000 This works for me, and is in line with my understanding of what is in/out of scope of SIPREC. I wanted to highlight it to make sure we are all on the same page.=20 Thanks, Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Wednesday, July 20, 2011 7:52 AM > To: siprec@ietf.org > Subject: Re: [siprec] cancel or restart/redo a recording >=20 > On 7/19/11 10:56 AM, Charles Eckel (eckelcu) wrote: > > Hi John, > > > > To phrase it another way, I am looking for a way to: > > 1) start "My Recording" at time t+0 > > 2) stop "My Recording" at time+1 because I messed up what I wanted to > > say > > 3) erase "My Recording" at time+2 > > 4) start "My Recording" at time+3 in hopes of expressing my message more > > clearly > > Repeat steps 2-4 as many times as necessary. >=20 > So, you are trying to make this into the control interface for a > voicemail server? Something akin to RTSP??? >=20 > For that I think you would also want control over playback, so you could > hear your recording. >=20 > While I guess siprec could be used as part of the infrastructure for a > VM server, I don't know if it is really ideal for that. And even if so, > I think this functionality is quite a different interface. IMO this is > not in scope for the current effort. >=20 > Thanks, > Paul >=20 > > My goal is to have a single version of "My Recording". It seems that > > instead I would have multiple versions, "My Recording 1", My Recording > > 2", etc., and I would use mechanism outside of the scope of SIPREC to > > perhaps delete and rename the recordings to get the combination I > > wanted. > > Going back to my voicemail example, if I made several attempts at > > leaving a voicemail for someone, I would really be creating multiple > > recordings. Eventually the last recording would get put into the > > voicemail box of the called party, and the other versions would still > > exist but probably get deleted by some other mechanism. > > As I understand it, SIPREC is concerned with facilitating the recording > > of the various voicemail attempts. Ultimately selecting one of these > > versions and erasing the rest is outside of the scope of SIPREC. I think > > I am okay with that, but I wanted to make sure this was the intention of > > the group. > > > > Thanks, > > Charles > > > > > >> -----Original Message----- > >> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > >> Sent: Tuesday, July 19, 2011 2:03 AM > >> To: Charles Eckel (eckelcu); siprec@ietf.org > >> Subject: RE: cancel or restart/redo a recording > >> > >> Charles, > >> > >> Looking at the requirements draft we have: > >> "REQ-017: The mechanism MUST support a means for a recording-aware > >> UA involved in a CS to request during a session that the recording > > of > >> the 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 such requests." > >> The present mechanism proposal addresses this to some extent, but on a > > per medium basis. So the UA can > >> request stopping / starting recording a given medium. There is no > > distinction between pausing and > >> stopping and no distinction between resuming and starting. Stopping an > > entire recording could be done > >> by a UA requesting that recording be stopped for each medium, but that > > assumes the particular UA is > >> aware of (participating in) all the media. So an audio-only UA > > participating in an audio-video > >> conference might not have the ability to request stopping the > > recording of video and therefore might > >> not have the ability to request stopping the entire recording. > >> > >> You specifically said "cancel or restart/redo". Cancel might seem to > > indicate that it be erased from > >> the SRS archives, but I think we said anything to do with retention is > > a policy matter and out of > >> scope. Also "redo" implies going back in time recording from the > > beginning again, which is hard to do > >> (requires buffering at the SRC?). Or maybe you just meant start again > > after previously stopping the > >> recording. > >> > >> So the question is whether the existing mechanism is sufficient. > >> > >> John > >> > >> > >>> -----Original Message----- > >>> From: siprec-bounces@ietf.org > >>> [mailto:siprec-bounces@ietf.org] On Behalf Of Charles Eckel > > (eckelcu) > >>> Sent: 19 July 2011 00:19 > >>> To: siprec@ietf.org > >>> Subject: [siprec] cancel or restart/redo a recording > >>> > >>> Something common with existing recording solutions is > >>> allowing the user > >>> to cancel or restart/redo a recording (i.e. while leaving a voice > >>> messages, cancel the existing message and start recording a new > > one). > >>> I do not see anything in the SIPREC requirements or protocol drafts > > to > >>> support this. This could be considered a special case of playback > > and > >>> therefore lie outside the scope of SIPREC. Does anyone see this as a > >>> problem? > >>> > >>> Thanks, > >>> Charles > >>> _______________________________________________ > >>> siprec mailing list > >>> siprec@ietf.org > >>> https://www.ietf.org/mailman/listinfo/siprec > >>> > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > > >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From Henry.Lum@alcatel-lucent.com Wed Jul 20 14:00: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 9B42521F899F for ; Wed, 20 Jul 2011 14:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.411 X-Spam-Level: X-Spam-Status: No, score=-6.411 tagged_above=-999 required=5 tests=[AWL=0.188, 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 p+pAje-kmaL1 for ; Wed, 20 Jul 2011 14:00:03 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 80FDF21F8681 for ; Wed, 20 Jul 2011 14:00:03 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p6KL0192008187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 20 Jul 2011 16:00:01 -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 p6KKxxhO019460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 20 Jul 2011 16:00:01 -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 p6KKxwId015943; Wed, 20 Jul 2011 13:59:58 -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, 20 Jul 2011 13:59:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Jul 2011 13:59:59 -0700 Message-ID: <059AF07365DC474393A19A3AF187DF74075217F5@NAHALD.us.int.genesyslab.com> In-Reply-To: <4E26EFE9.3050507@alum.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] what to put in the message header to indicatemetadata snapshot request Thread-Index: AcxG7zTfH0+oUCezQp27FNiytk4USAALamKQ References: <059AF07365DC474393A19A3AF187DF74075211C2@NAHALD.us.int.genesyslab.com> <4E26EFE9.3050507@alum.mit.edu> From: "Henry Lum" To: "Paul Kyzivat" , X-OriginalArrivalTime: 20 Jul 2011 20:59:58.0929 (UTC) FILETIME=[FC4BDC10:01CC471F] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: Re: [siprec] what to put in the message header to indicatemetadata snapshot request X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 21:00:07 -0000 Please see inline. -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Wednesday, July 20, 2011 11:11 AM To: siprec@ietf.org Subject: Re: [siprec] what to put in the message header to indicatemetadata snapshot request On 7/18/11 6:41 PM, Charles Eckel (eckelcu) wrote: > I was initially thinking of this from the perspective of wanting to > avoid requiring metadata processing on the behalf of the SRS or SRC in > order to request a snapshot. In this case, a SIP header is appealing. I agree that it would be good to simplify the processing the SRC must do to recognize the request. This could be done using a sip header, but also by using a body with a=20= different content type from that of the metadata. That body might not be xml - it might simply be text with a very simple syntax. [hlum] I agree there should be little processing SRC needs to do to recognize the request and that is my intent in the draft. It is basically a text body and not inheriting any XML from the metadata; to me it's little difference compared to a SIP header with text. The text is basically a status string and the SRC does not even need to care about the content if it does not want to. To clarify, the processing of the content is entirely optional for the SRC; as long as the SRC recognizes that the format type then the SRC knows that the SRS is asking for a snapshot request.=20 > Another option, and the one implied by section 5.5 of the draft, is to > enable generic metadata error handling. If you want to do this, > requesting a snapshot could be a type of error reported by the SRS, and > sending a snapshot could be a recovery mechanism used by the SRC. More > complex error reporting and recovery would probably involve some sort of > metadata sequence number and an indication of the last sequence number > processed properly on the SRS. This would enable the SRC to send updates > based on an intermediate point in the recording. IMO many of the primary use cases for recording are likely to be=20 paranoid about recording as much as possible even in the face of errors. This probably translates into capturing the incoming media from the=20 negotiated RS media streams even if the metadata is missing or=20 malformed. And maybe capturing the metadata even if it is malformed. Another priority is probably to simply SRCs, since they are likely to be grafted onto lots of things. I don't think it is a good idea to expect=20= the SRC to maintain a lot of data to facilitate error recovery. As a result, I don't see complex error recovery mechanisms as helpful.=20= Simple ones are probably all that we should expect an SRC to be able to=20= handle, and are all that would be very useful. I've also been pondering what "full" means for metadata in contrast to=20= "partial". I am coming to the conclusion that to the SRS there is really no difference - "full" metadata is processed exactly the same way as=20 "partial" is. It is just likely to contain data that would be redundant=20= if all had gone well before. From the perspective of the SRC, a request=20= for a snapshot simply means "send everything you currently know about=20 all the media streams you currently are sending to the SRS, and then=20 continue sending updates after that." [hlum] I agree we don't need to get into complex mechanism such as keeping track of sequence numbers and synchronizing states. My thinking this is the former mechanism and not trying to come up with a recovery mechanism. The snapshot request basically just ask the SRC to send everything SRC knows right now (I guess we are calling it "full" metadata?) and resume operation. In the case where the SRS can't really figure out what is going on then the SRS can simply terminate the recording session. Anyways I think we are in agreement but it looks like the wording in section 5.5 is a bit terse to give the impression that it is proposing a synchronization/recovery mechanism. Thanks, Paul > I am thinking the former mechanism is sufficient. The latter mechanism, > though definitely much more efficient in many cases, is more complex. > The cynic/realist in me thinks that with either method, the odds are > high that once an error is encountered any recovery mechanism (e.g. a > snapshot, an intermediate update, etc.) has a high probability of > failing. The important thing is to be able to debug the failure. For > example, it may be that the update resulted in a parsing error on the RS > within some participant element. I see some value in having this in some > SIP or metadata message, but having it enable auto-recovery is not > likely. > As I do not see any error handling within the current metadata > model/format, I am thinking it is best to leave the snapshot request > outside of the context of the metadata. > > Cheers, > Charles > > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Elwell, John >> Sent: Monday, July 18, 2011 12:45 AM >> To: Henry Lum; siprec@ietf.org >> Subject: Re: [siprec] what to put in the message header to > indicatemetadata snapshot request >> >> Henry, >> >> At the last interim it was minuted: >> "Slide 8: Concerning the nature of a snapshot request, Charles thought > this could be just a simple >> request, with no parameters. The discussion seemed to lean towards > something in the header, rather >> than in the body. To be continued on the list." >> I don't recall much discussion on the list, but the proposal in 05 for > a body part seems to go against >> the meeting's general preference for something in the header. >> >> I also don't recall anything in either the metadata draft or in the > protocol draft to help the SRS >> determine whether it has lost a metadata update (and therefore needs > to request a snapshot). Some sort >> of sequence numbering is perhaps required. >> >> John >> >> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org >>> [mailto:siprec-bounces@ietf.org] On Behalf Of Henry Lum >>> Sent: 15 July 2011 16:12 >>> To: siprec@ietf.org >>> Subject: [siprec] what to put in the message header to >>> indicate metadata snapshot request >>> >>> Hi, >>> >>> >>> >>> In the latest protocol draft revision (05) I proposed a >>> mechanism to request for metadata snapshot request. This is >>> outlined in section 5.5. I want to get some comments on >>> whether the proposed mechanism is sufficient. >>> >>> >>> >>> Thanks >>> >>> 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. >>> >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing 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 Jul 20 20:01:45 2011 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 467861F0C36 for ; Wed, 20 Jul 2011 20:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.432 X-Spam-Level: X-Spam-Status: No, score=-6.432 tagged_above=-999 required=5 tests=[AWL=0.167, 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 XcxQ1FRrCxsI for ; Wed, 20 Jul 2011 20:01:44 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB8C1F0C35 for ; Wed, 20 Jul 2011 20:01:44 -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 p6L31fN1024668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 20 Jul 2011 22:01:41 -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 p6L31dkZ002783 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 20 Jul 2011 22:01:41 -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 p6L30RdL020564; Wed, 20 Jul 2011 20:01:38 -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, 20 Jul 2011 20:00:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Jul 2011 20:00:45 -0700 Message-ID: <059AF07365DC474393A19A3AF187DF7407521852@NAHALD.us.int.genesyslab.com> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E30D755D82CA@MCHP058A.global-ad.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Comments on draft-portman-siprec-protocol-05 Thread-Index: AcxFVtDX2/BM3obRTkKA9PPOnZTIuQAB/ouAAHERrIA= References: <35BCE99A477D6A4986FB2216D8CF2CFD07055D71@XMB-BGL-417.cisco.com> <101C6067BEC68246B0C3F6843BCCC1E30D755D82CA@MCHP058A.global-ad.net> From: "Henry Lum" To: "Hutton, Andrew" , "Ram Mohan R (rmohanr)" , "Leon Portman" , X-OriginalArrivalTime: 21 Jul 2011 03:00:46.0074 (UTC) FILETIME=[63000DA0:01CC4752] 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] Comments on draft-portman-siprec-protocol-05 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 03:01:45 -0000 Please see inline. -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf = Of Hutton, Andrew Sent: Monday, July 18, 2011 11:47 AM To: Ram Mohan R (rmohanr); Leon Portman; siprec@ietf.org Subject: Re: [siprec] Comments on draft-portman-siprec-protocol-05 Hi Ram, Sorry I did not see your response before sending my own comments. See some responses below. Reading your comments made me think a more thorough review is needed whic= h I will attempt to do. Regards Andy > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Ram Mohan R (rmohanr) > Sent: 18 July 2011 15:27 > To: Leon Portman; siprec@ietf.org > Subject: [siprec] Comments on draft-portman-siprec-protocol-05 >=20 > Leon et all, >=20 > Over all the draft is coming up good. Here are some of my comments.. >=20 > 1)Section 1 says "The Session Recording Protocol uses SIP as the > protocol for session establishment with special attention to reducing > size of the required SIP messages. " > I am not clear on what is the context of this statement w.r.t SIPREC > solution and how it helps in reducing size of messages. =A0Can you plea= se > clarify ? >=20 I had the same comment I think this statement should be removed. [hlum] I don't think minimizing the size of the SIP message is a design g= oal anymore. Let's remove this. > 2)Section 1 says "In addition, it is designed for future extendibility > and protocol version management to ensure backward compatibility" > Again can you please clarify how this is done ? >=20 I don't think this is relevant to this document probably more applicable = to the metadata. [hlum] Agreed - looks like the protocol draft does not contain anything t= hat requires versioning of the protocol at all. Let's remove it.=20 =20 > 3)I would suggest to have only new definitions on Section 2. In case > you still want to retain them please make them consistent.=A0 I see som= e > mismatch in the definitions of Section 2 to the ones in Requirement > draft. >=20 Personally I think the architecture draft should be the master regarding = definitions as this defines the architecture and therefore the entities i= nvolved. [hlum] I haven't updated this section to sync with the definitions in the= requirements draft. I am okay with referencing either the requirements d= ocument or the architecture document, which one should we use? > 4)In Figure 2, the RS may be setup upon receiving INVITE from UA A. It > need not wait always until A and B are connected. IMO this is a policy > decision. You may want to add a note saying the same. The diagram gives= > an impression that it may be the only way RS may be setup. [hlum] Okay I will add a note to clarify.=20 >=20 > 5)Section 4.3 has this text about delivering metadata > > "In some cases session metadata can be conveyed through non-SIP > =A0=A0 mechanism such as HTTP or JTAPI.=A0 These non-SIP mechanisms are= > =A0=A0 considered out of the scope of the Session Recording Protocol, > =A0=A0 however, it is envisoned that a link with a URI can be provided = in > =A0=A0 the recording session INVITE message so that the SRS can access = the > =A0=A0 session metadata via the URI provided that the SRS supports the = type > =A0=A0 of URI." > > IMO since the current metadata XML schema is not extensible outside SIP= > it is better to not mention this text. >=20 I agree. [hlum] I don't see how the metadata format is currently tied to SIP; the = model and the XML has no direct reference to SIP elements. In fact, REQ-0= 14 says that the metadata format must be agnostic to the transport protoc= ol so we are obliged to make the format work for non-SIP transports. Howe= ver, I would agree to remove this text since this document focuses on SIP= extensions. > 6)Section 5.2 > > "To remove a recorded media stream from the recording session, send a > =A0=A0 reINVITE and set the port to zero in the m=3D line. >=20 > =A0=A0 To add a recorded media stream, send a reINVITE and add a new m=3D= > =A0=A0 line." > > You may want to add a text here that this is applicable only if SRC is > recording each stream independently. [hlum] Each m=3D line represents a separate stream from the SRC so I am n= ot sure what you mean here. > I have a question here. In case the stream sent from SRC to SRS happens= > to be a mixed stream (IOW we have only one m-line), addition /deletion > of participants can be known by looking at metadata xml schema and > looking for all participants who a . Apart from this do= > we need anything else in metadata or in protocol ? [hlum] If it is a mixed stream then the metadata needs to provide the cha= nges to participants; there isn't must the protocol needs to specify. On = the other hand, if the SRC is not mixing the media but multiplexing media= from participants, then I guess the SRS would receive RTP packets from a= nother contributing source; and I don't see a need to send reINVITE to re= -negotiate SDP. >=20 > 7)Section 5.4 > > "As mentioned in the previous section, the SDP of the recording > =A0=A0 session is the metadata for all recorded media streams." > >=20 > You may want to re-word this sentence to make it more clearer. > Something like this: > As mentioned in the previous section, the SDP of the recording=A0 sessi= on > describes the properties of media for all recorded media streams. >=20 I agree the text does not seem to make much sense to me your suggestion i= s better. [hlum] Thanks for catching this.=20 >=20 > 8) Section 5.4 > > For all basic metadata information such as communication session, > =A0=A0 participants, call identifiers and direction, they can be includ= ed > in > =A0=A0 the initial INVITE request sent by the SRC. > > Note that we are not sending direction attribute in =A0basic metadata. = It > was agreed earlier that direction value is not possible to be > determined at all times and hence we may send it as extension data. [hlum] Okay, I will remove direction from the sentence. > what is call identifier here ? [hlum] that would be participant AOR according to the latest metadata dra= ft. >=20 >=20 > 9) Sectoin 5.5 > IMO this needs some more discussion before acceptance. As John > mentioned in another thread, we have not had much discussion on this > either before. >=20 [hlum] There is a thread going on now. I think we are agreeing on a simpl= e mechanism which is the intent of this section. Will need to work on the= wording a little but to clarify the intent. > 10) Section 6.1 > Apart from what is mentioned in last para of this section, I think we > can explicitly add a note that this attribute is NOT intended tell an > SRC to start/stop recording. [hlum] Updating the last sentence: "This attribute is also not used as an indication to negotiate which SRC in the call path will perform recording and is not used as a request to start/stop recording if ther= e are multiple SRCs in the call path." >=20 > 11) Section 6.3 > Any reason why we explicitly need to indicate "nopreference".=A0 Cant t= he > absence of this SDP attribute itself says that a UA has no preference. >=20 [hlum] We did have discussion about this, and it seems like we don't have= strong opinions having or not having this value. I can see that it would= be useful for a recording aware UA to be explicit about having no prefer= ence than no specifying at all. > Regards, > Ram >=20 >=20 >=20 _______________________________________________ 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 rmohanr@cisco.com Wed Jul 20 22:26: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 D0CBD21F867E for ; Wed, 20 Jul 2011 22:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.364 X-Spam-Level: X-Spam-Status: No, score=-10.364 tagged_above=-999 required=5 tests=[AWL=0.235, 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 WaYrjUbfmsCj for ; Wed, 20 Jul 2011 22:26:52 -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 A2CC321F86AE for ; Wed, 20 Jul 2011 22:26:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=948; q=dns/txt; s=iport; t=1311226012; x=1312435612; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=HZRIUNqMw9g6LlDq0JnLhjuM7g1fJrPXd8r4Zw92eFk=; b=ODrdgVELC/qb7piaME+TtGEc2whjZJn3/HMsJRY/evFmcjNGpCznJrc1 jm+K41sF5Vu+A2wJ5qnIu/Be3M1Gwo4hq3UTik8q/35p+9L6vxE2vl6AJ dRGqRlnDW1vGvYy0i9KYWYRyBPjUjlJr65zKUORHpCswOd7W1HxQWaYUU I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EABO4J05Io8US/2dsb2JhbABTp2Z3pl2eJ4VfXwSHU5Ari1U Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-2.cisco.com with ESMTP; 21 Jul 2011 05:26:50 +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 p6L5QoK2026150; Thu, 21 Jul 2011 05:26:50 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Jul 2011 10:56: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: Thu, 21 Jul 2011 10:56:48 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD07163BD8@XMB-BGL-417.cisco.com> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Review of metadata-03 Thread-Index: AcxCBGRNA+vWWzKOQdKee6BfMA3hewBkBI/gAGBJQ4AAA0angACQxDRQ References: From: "Ram Mohan R (rmohanr)" To: "Parthasarathi R (partr)" , "Elwell, John" , X-OriginalArrivalTime: 21 Jul 2011 05:26:50.0298 (UTC) FILETIME=[CAE281A0:01CC4766] Subject: Re: [siprec] Review of metadata-03 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 05:26:56 -0000 Hi John / Partha, > > > > 33. Section 6.3.2: > > > > "CS to have atleast two or more participants" > > > > Are there any corner cases where there might be fewer than two? > > > > > > > We don't know the usecase till now and concluded for two > > > participant. In case you know of any usecase, Please let us know > > > > > [JRE] I am not aware of a use case - I just feel slightly > > uncomfortable. Leave it for now. > > > Let us track this as an open item for IETF-81 and explore the > possibility A comment on this- In the current model Each CS class has atleast two participants. IOW the current model does not allow a CS with less than 2 participants. Is there a need to track this as open item ? As I remember we did agree initially that each CS shall have atleast two participants. Let me know so that I can add this to slide deck as open item if need be. Regards, Ram From partr@cisco.com Wed Jul 20 22:37: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 5FCEA21F8AC3 for ; Wed, 20 Jul 2011 22:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.346 X-Spam-Level: X-Spam-Status: No, score=-10.346 tagged_above=-999 required=5 tests=[AWL=0.253, 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 gitCRFBgQDMB for ; Wed, 20 Jul 2011 22:37:50 -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 A2E7921F8ABD for ; Wed, 20 Jul 2011 22:37:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=1667; q=dns/txt; s=iport; t=1311226670; x=1312436270; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=mJBq4aegeyqz9MqxLnbSvPjsuxKHlokDoYcBYWOKPRo=; b=dSshKg05sTfEFoHy3n1z0sBWAMZTqeQqBB+5Lzla0w1AM9w6jdoHbdgf UKKog8+wmwBPGp6qmCjD/34k6MbtyCKG0YqqY3KJYce1cks70ekpJLc0m 3HtCFTjxlUAOC3SMj98GDEGfDbYGyf14hes042v471JNQDFyoNDrqLvn1 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AukAAGK6J05Io8US/2dsb2JhbABTmBqPTHenCZ4nhV9fBIdTkCuLVQ Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-2.cisco.com with ESMTP; 21 Jul 2011 05:37:48 +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 p6L5aKPT028006; Thu, 21 Jul 2011 05:37:48 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Jul 2011 11:07:31 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Jul 2011 11:07:29 +0530 Message-ID: In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD07163BD8@XMB-BGL-417.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Review of metadata-03 Thread-Index: AcxCBGRNA+vWWzKOQdKee6BfMA3hewBkBI/gAGBJQ4AAA0angACQxDRQAACKHuA= References: <35BCE99A477D6A4986FB2216D8CF2CFD07163BD8@XMB-BGL-417.cisco.com> From: "Parthasarathi R (partr)" To: "Ram Mohan R (rmohanr)" , "Elwell, John" , X-OriginalArrivalTime: 21 Jul 2011 05:37:31.0940 (UTC) FILETIME=[49554E40:01CC4768] Subject: Re: [siprec] Review of metadata-03 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 05:37:51 -0000 Ram, As you mentioned, it was discussed during IETF-80 with different use-case like studio mode recording, voice mail. Then, we agreed to go with minimum 2 participant. I have asked this item to be re-opened because John is slightly uncomfortable and expects more opinion/usecase. IMO, it is better to discuss in IETF-81 and close forever. Thanks Partha=20 > -----Original Message----- > From: Ram Mohan R (rmohanr)=20 > Sent: Thursday, July 21, 2011 10:57 AM > To: Parthasarathi R (partr); Elwell, John; siprec@ietf.org > Subject: RE: [siprec] Review of metadata-03 >=20 > Hi John / Partha, >=20 > > > > > 33. Section 6.3.2: > > > > > "CS to have atleast two or more participants" > > > > > Are there any corner cases where there might be fewer=20 > than two? > > > > > > > > > We don't know the usecase till now and=20 > concluded for two=20 > > > > participant. In case you know of any usecase, Please=20 > let us know=20 > > > > > > > [JRE] I am not aware of a use case - I just feel slightly=20 > > > uncomfortable. Leave it for now. > > > > > Let us track this as an open item for IETF-81 and=20 > explore the=20 > > possibility >=20 >=20 > A comment on this- In the current model Each CS class has=20 > atleast two participants. IOW the current model does not=20 > allow a CS with less than 2 participants. Is there a need to=20 > track this as open item ? As I remember we did agree=20 > initially that each CS shall have atleast two participants. >=20 > Let me know so that I can add this to slide deck as open item=20 > if need be. >=20 > Regards, > Ram >=20 >=20 From rmohanr@cisco.com Wed Jul 20 22:43: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 CDDC021F8AE6 for ; Wed, 20 Jul 2011 22:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.373 X-Spam-Level: X-Spam-Status: No, score=-10.373 tagged_above=-999 required=5 tests=[AWL=0.226, 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 8fH99cRHOt5u for ; Wed, 20 Jul 2011 22:43:51 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 4364221F8AEC for ; Wed, 20 Jul 2011 22:43:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=10414; q=dns/txt; s=iport; t=1311227030; x=1312436630; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=K5CS6g6N+MhmZVvoqqVfZ6aQv8B849qLYTEQ9p/HXag=; b=fQhN+yvq30vZGDQxdZ5lC45TAkOXbSNI1+xn5Z623tsr2XqDqMYqTMK/ O4oMHL6XgztYsowzd3LzpJWhQTqzxCTF+CB0QPt7+cB2a9YipvjXdV59A XM9wd4U09vlaMW+VCDsfYBtqQZcEOXFmR4I8qymS+lQABDCfbjiDEAzC8 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AukAAIa7J05Io8UR/2dsb2JhbABTmBqPTHeIfJ4SniWFX18EhyYtkCuLVQ Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-2.cisco.com with ESMTP; 21 Jul 2011 05:43:47 +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 p6L5hlmS024363; Thu, 21 Jul 2011 05:43:47 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Jul 2011 11:13: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Jul 2011 11:13:45 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD07163BF3@XMB-BGL-417.cisco.com> In-reply-to: <059AF07365DC474393A19A3AF187DF7407521852@NAHALD.us.int.genesyslab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Comments on draft-portman-siprec-protocol-05 Thread-Index: AcxFVtDX2/BM3obRTkKA9PPOnZTIuQAB/ouAAHERrIAAD6K9kA== References: <35BCE99A477D6A4986FB2216D8CF2CFD07055D71@XMB-BGL-417.cisco.com> <101C6067BEC68246B0C3F6843BCCC1E30D755D82CA@MCHP058A.global-ad.net> <059AF07365DC474393A19A3AF187DF7407521852@NAHALD.us.int.genesyslab.com> From: "Ram Mohan R (rmohanr)" To: "Henry Lum" , "Hutton, Andrew" , "Leon Portman" , X-OriginalArrivalTime: 21 Jul 2011 05:43:47.0650 (UTC) FILETIME=[29461A20:01CC4769] Subject: Re: [siprec] Comments on draft-portman-siprec-protocol-05 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 05:43:54 -0000 Hi Henry, Thanks for your responses. Please see inline for [Ram] > -----Original Message----- > From: Henry Lum [mailto:Henry.Lum@alcatel-lucent.com] > Sent: Thursday, July 21, 2011 8:31 AM > To: Hutton, Andrew; Ram Mohan R (rmohanr); Leon Portman; > siprec@ietf.org > Subject: RE: [siprec] Comments on draft-portman-siprec-protocol-05 >=20 > Please see inline. >=20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Hutton, Andrew > Sent: Monday, July 18, 2011 11:47 AM > To: Ram Mohan R (rmohanr); Leon Portman; siprec@ietf.org > Subject: Re: [siprec] Comments on draft-portman-siprec-protocol-05 >=20 > Hi Ram, >=20 > Sorry I did not see your response before sending my own comments. >=20 > See some responses below. >=20 > Reading your comments made me think a more thorough review is needed > which I will attempt to do. >=20 > Regards > Andy >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Ram Mohan R (rmohanr) > > Sent: 18 July 2011 15:27 > > To: Leon Portman; siprec@ietf.org > > Subject: [siprec] Comments on draft-portman-siprec-protocol-05 > > > > Leon et all, > > > > Over all the draft is coming up good. Here are some of my comments.. > > > > 1)Section 1 says "The Session Recording Protocol uses SIP as the > > protocol for session establishment with special attention to = reducing > > size of the required SIP messages. " > > I am not clear on what is the context of this statement w.r.t SIPREC > > solution and how it helps in reducing size of messages. =A0Can you > please > > clarify ? > > >=20 > I had the same comment I think this statement should be removed. >=20 > [hlum] I don't think minimizing the size of the SIP message is a = design > goal anymore. Let's remove this. >=20 > > 2)Section 1 says "In addition, it is designed for future > extendibility > > and protocol version management to ensure backward compatibility" > > Again can you please clarify how this is done ? > > >=20 > I don't think this is relevant to this document probably more > applicable to the metadata. >=20 > [hlum] Agreed - looks like the protocol draft does not contain = anything > that requires versioning of the protocol at all. Let's remove it. >=20 > > 3)I would suggest to have only new definitions on Section 2. In case > > you still want to retain them please make them consistent.=A0 I see > some > > mismatch in the definitions of Section 2 to the ones in Requirement > > draft. > > >=20 > Personally I think the architecture draft should be the master > regarding definitions as this defines the architecture and therefore > the entities involved. >=20 > [hlum] I haven't updated this section to sync with the definitions in > the requirements draft. I am okay with referencing either the > requirements document or the architecture document, which one should = we > use? IMO we can use architecture draft. I see even the draft put up by = Charles does the same. >=20 >=20 > > 4)In Figure 2, the RS may be setup upon receiving INVITE from UA A. > It > > need not wait always until A and B are connected. IMO this is a > policy > > decision. You may want to add a note saying the same. The diagram > gives > > an impression that it may be the only way RS may be setup. >=20 > [hlum] Okay I will add a note to clarify. >=20 > > > > 5)Section 4.3 has this text about delivering metadata > > > > "In some cases session metadata can be conveyed through non-SIP > > =A0=A0 mechanism such as HTTP or JTAPI.=A0 These non-SIP mechanisms = are > > =A0=A0 considered out of the scope of the Session Recording = Protocol, > > =A0=A0 however, it is envisoned that a link with a URI can be = provided in > > =A0=A0 the recording session INVITE message so that the SRS can = access > the > > =A0=A0 session metadata via the URI provided that the SRS supports = the > type > > =A0=A0 of URI." > > > > IMO since the current metadata XML schema is not extensible outside > SIP > > it is better to not mention this text. > > >=20 > I agree. >=20 > [hlum] I don't see how the metadata format is currently tied to SIP; > the model and the XML has no direct reference to SIP elements. In = fact, > REQ-014 says that the metadata format must be agnostic to the = transport > protocol so we are obliged to make the format work for non-SIP > transports. However, I would agree to remove this text since this > document focuses on SIP extensions. [Ram] Please note that the current metadata schema has information like =