Re: [siprec] Adoption of material from draft-ram-siprec-metadata-format-02
"Parthasarathi R (partr)" <partr@cisco.com> Thu, 23 June 2011 08:45 UTC
Return-Path: <partr@cisco.com>
X-Original-To: siprec@ietfa.amsl.com
Delivered-To: siprec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8263511E80B9 for <siprec@ietfa.amsl.com>; Thu, 23 Jun 2011 01:45:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.428
X-Spam-Level:
X-Spam-Status: No, score=-10.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8+UsMU8TXos8 for <siprec@ietfa.amsl.com>; Thu, 23 Jun 2011 01:45:08 -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 0EA8E11E80B5 for <siprec@ietf.org>; Thu, 23 Jun 2011 01:45:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=6699; q=dns/txt; s=iport; t=1308818708; x=1310028308; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=zG3io87tgxaFpHrq1Ne1fuGKlanXqWNPvkH6OoNi0Ng=; b=YJYj8kBGDPiOH/GDEsJ7/w3ejE+w5upLFF2DVEtD0L0tfkASmLHVpn2s XJIw0b/NhME0TjLa9d5dDrUaQC4A3D48+sC8/0dK6e3VYROv6hbWXv3xQ /1XIITr1jBbnLrtl7SZOOUKRRRLS1styrM0hE/GC8TbzCLyKhQVu+/k7k Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ah8BALn7Ak5Io8US/2dsb2JhbABGDZgEjxp3iHOibp4sgyCDDQSHJI88iyg
X-IronPort-AV: E=Sophos;i="4.65,412,1304294400"; d="scan'208";a="37604829"
Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-2.cisco.com with ESMTP; 23 Jun 2011 08:45:06 +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 p5N8j4BX003396; Thu, 23 Jun 2011 08:45:04 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, 23 Jun 2011 14:15:04 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 23 Jun 2011 14:15:06 +0530
Message-ID: <A11921905DA1564D9BCF64A6430A6239059D4F3F@XMB-BGL-411.cisco.com>
In-Reply-To: <A11921905DA1564D9BCF64A6430A6239058F8AFC@XMB-BGL-411.cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [siprec] Adoption of material from draft-ram-siprec-metadata-format-02
Thread-Index: Acwvc9GH9M8y1vuZSxq3cub71esM/gAfP5LgABAu1WAAU0E7gA==
References: <A444A0F8084434499206E78C106220CA08C663758C@MCHP058A.global-ad.net><E1CBF4C7095A3D4CAAAEAD09FBB8E08C0497E061@xmb-sjc-234.amer.cisco.com><4DFF8A82.3000809@cisco.com><07465C1D981ABC41A344374066AE1A2C38AF5C8E38@TLVMBX01.nice.com> <A11921905DA1564D9BCF64A6430A6239058F8AFC@XMB-BGL-411.cisco.com>
From: "Parthasarathi R (partr)" <partr@cisco.com>
To: Leon Portman <Leon.Portman@nice.com>, "Paul Kyzivat (pkyzivat)" <pkyzivat@cisco.com>, siprec@ietf.org, "Charles Eckel (eckelcu)" <eckelcu@cisco.com>, "Elwell, John" <john.elwell@siemens-enterprise.com>
X-OriginalArrivalTime: 23 Jun 2011 08:45:04.0913 (UTC) FILETIME=[D90FB810:01CC3181]
Subject: Re: [siprec] Adoption of material from draft-ram-siprec-metadata-format-02
X-BeenThere: siprec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Recording Working Group Discussion List <siprec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/siprec>, <mailto:siprec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/siprec>
List-Post: <mailto:siprec@ietf.org>
List-Help: <mailto:siprec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/siprec>, <mailto:siprec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jun 2011 08:45:09 -0000
Hi all, I haven't seen any closure for the below mail. In that scenario, it is an (re-)open item in SIPREC architecture. In case lot of folks interested in non-SIP (generic) based metadata passing mechanism, Let us discuss in detail during today's Interim meeting and take an approach to move forward. Also, draft-ram-siprec-metadata-format is designed with the assumption that SIP will be used for passing metadata approach. BTW, there was analyze on using "REST" XML approach for metadata passing which will be more suitable for HTTP based interfaces but it is an overkill for SIP based mechanism. It was highlighted in Slide-11 of draft-ram-siprec-metadata-format presentation in IETF-80 (www.ietf.org/proceedings/80/slides/siprec-1.ppt). Thanks Partha -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Parthasarathi R (partr) Sent: Tuesday, June 21, 2011 10:22 PM To: Leon Portman; Paul Kyzivat (pkyzivat); siprec@ietf.org Subject: Re: [siprec] Adoptionofmaterial fromdraft-ram-siprec-metadata-format-02 Hi all, I have raised non-SIP (HTTP, XMPP) mechanism for metadata as an open item in SIPREC architecture document before IETF-80. The related link is as follows: http://www.ietf.org/mail-archive/web/siprec/current/msg01608.html. The conclusion of IETF-80 SIPREC meeting is to use SIP as a mechanism which is discussed at slide-7 of SIPREC architecture (www.ietf.org/proceedings/80/slides/siprec-2.ppt). I attached the specific slide content and notes of the meeting for your reference. Thanks Partha Note: Slide contents: 01 draft states some examples of how metadata could be delivered to the SRC SIP Headers. SDP. Event Package. INFO Package. Non SIP Means. Proposal - We seem to be converging on using INVITE/UPDATE on the RS Dialog so state this. Keep non SIP means although outside SIPREC scope. Conclusion in IETF-80: Proposal: List INVITE/UPDATE + non-SIP means only for metadata delivery? Hadriel Kaplan: Agrees, but don't mention specific methods (e.g. INVITE/UPDATE) Keith Drage: Clarified that this repeats stuff in the protocol document -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Leon Portman Sent: Tuesday, June 21, 2011 2:32 PM To: Paul Kyzivat (pkyzivat); siprec@ietf.org Subject: Re: [siprec] Adoptionof material fromdraft-ram-siprec-metadata-format-02 Actually we had lot of discussion about this issue (metadata over SIP or over dedicated web service/HTTP) both internally and with partners. Main advantages (what I remember ) for SIP approach are as follows: 1. Simplicity, only one interface to implement, troubleshoot, secure and configure between SRC and SRS 2. RS SIP request is self-contained, it includes all relevant info in order to SRS to decide how to do recording . For example participants identity, location. So no need for SRS to correlate different messages from different interfaces 3. Footprint on SRC. For some implementation it is not feasible to have both SIP and HTTP stacks Leon -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Monday, June 20, 2011 9:00 PM To: siprec@ietf.org Subject: Re: [siprec] Adoption of material fromdraft-ram-siprec-metadata-format-02 Charles, IIRC, the major driving forces were timeliness and synchronicity of metadata with the actual signaling, especially when initially establishing a RS, so that suitable decisions can be made about whether to record a session, etc. AFAIK the avoidance of an HTTP server in the SRS wasn't a concern. (Its assumed in general to be a very capable box, and probably has an HTTP interface for querying, though that is out of our scope for now.) Avoiding an http client in the src might be slightly more significant, but I don't think that was much of a concern either. Could we have skinned this cat with an http approach? Probably. Obviously we had a lot more sip expertise than http expertise in the group. That may have been an influence as well. Thanks, Paul On 6/20/2011 11:40 AM, Charles Eckel (eckelcu) wrote: > Hi John, > > One general comment/question I have received from web application > savvy coworkers with whom I have discussed the contents of this draft > is that the metadata is essentially a document and HTTP already has > well defined mechanisms for document sharing and updating, so why not > exchange an HTTP address for the document and leverage those > mechanisms instead of sending all the metadata within SIP messages. My > assumption is that the requirement is to have a SIP based solutions > that does not require an HTTP server. Is that accurate? > > Thanks, > Charles > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Elwell, John >> Sent: Monday, June 20, 2011 4:02 AM >> To: siprec@ietf.org >> Subject: [siprec] Adoption of material > fromdraft-ram-siprec-metadata-format-02 >> >> Although there are some open issues, to be discussed during >> Thursday's > call, I would like the WG to >> consider whether material in draft-ram-siprec-metadata-format-02 is > ready for adoption into draft- >> ietf-siprec-metadata, i.e., bring it under WG control. In particular, > between now and the call, please >> consider whether: >> - the material is heading roughly in an acceptable direction; >> - there are any issues that really should be closed before adoption; >> - there are any aspects of the draft that should not be adopted at > this time. >> >> If, on the call or shortly afterwards, we can agree on adoption, the > authors of the two drafts would >> be asked to perform a merger and publish a new version of > draft-ietf-siprec-metadata before the cut- >> off for IETF#81 (2011-07-11). >> >> John >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec
- [siprec] Adoption of material from draft-ram-sipr… Elwell, John
- Re: [siprec] Adoption of material fromdraft-ram-s… Charles Eckel (eckelcu)
- Re: [siprec] Adoption of material fromdraft-ram-s… Paul Kyzivat
- Re: [siprec] Adoption of material fromdraft-ram-s… Elwell, John
- Re: [siprec] Adoption of material fromdraft-ram-s… Leon Portman
- Re: [siprec] Adoptionof material fromdraft-ram-si… Parthasarathi R (partr)
- Re: [siprec] Adoption of material from draft-ram-… Parthasarathi R (partr)
- Re: [siprec] Adoption of material from draft-ram-… Elwell, John